Обновить
52
4.7

Пользователь

Отправить сообщение

Вы сами придумали что "литкодить на скорость" == "писать боевой код" и теперь размахиваете этим тезисом с великим восторгом. Заявление уровня "не служил - не мужик", короче. А для меня это не абсолютная истина, а так, частный случай. Можно хорошо литкодить и плохо писать боевой код. А можно плохо литкодить и хорошо писать боевой код. И остальные 2 комбинации тоже бывают. Так что выдохните уже.

Как-будто, если бы они не проверяли всех алгоритмами, то код был бы идеально вылизан.

Скажем там, если бы давали хоть что-то, кроме алгоритмов, то результат мог быть другой. Недавняя история с 6 задачками на 3 собесах в Небиус (экс-Яндекс) это же чисто буффонада.

Но к ним нет смысла приступать, если кандидат не способен написать кода из трёх строк

Ну а другой скажет, что нет смысла приступать, если теория event loop от зубов не отскакивает. Чем ваше кунг-фу лучше вот этого кунг-фу? Тем, что самомнение пухлее?

Вы пытаетесь оценить комплексное качество - скилл - простым измерением. Это типа как линейкой мерить и длину, и температуру, и давление. Я, к слову, не против кодинга на собесах. На наших собесах и кодинг, и ревью, и теория, и систем дизайн. И я смотрю на человека в комплексе и раньше времени желтую звезду ему на грудь не вешаю.

Если кандидат не в состоянии написать бинарный поиск или сортировку пузырьком, стоит ли от него ждать способности решить реальную бизнес-проблему?

Свидетели святого литкодинга забывают такой нюанс, что никто не решает реальные бизнес-проблемы под стрессом перед незнакомыми типами в незнакомом редакторе и на время. Вы сравниваете несравнимое.

И кстати все эти люди успешно прошли собесы и рассказали о сложности функций и всем таком

Что как бы говорит, что если ты ни разу не решал проблемы перфоманса на проде, но прорешал весь литод, то ты все равно ни разу не решал проблемы перфоманса на проде.

Minh Nguyen

Я с прошлого ноября прособесил 12 вьетнамцев на джаву. Взяли всего одну девушку толковую. У остальных интервьюеров выхлоп такой же или вообще по нулям. Это прям очень специфичная публика. У нас в СНГ как-то по дефолту считается, что инженер должен шарить и понимать, что под капотом. А этим ребятам вообще все параллельно. Могут что-то там нашлёпать - и так сойдет. Типичный диалог с сеньором-помидором с 8 годами опыта:

Я: Зачем вообще нужен HashSet? В каком кейсе его применить можно?

Сеньор: ... бла бла, понятия не имею...

Я: Хорошо, а почему у него вообще приставка Hash?

Сеньор: Потому что у объектов есть методы hashCode и equals.

(Пояснение. HashSet так называется, т.к. имеет в основе функционал хэш-таблиц, которые в свою очередь используют хэш-функции. То, что у классов можно определить эти самые хэш-функции вообще никак не объясняет название хэшсета и его свойств)

Короче, спрашиваешь какие-то реал-лайф кейсы - не знают. Переходишь на более приземленные вещи - не знают. Когда уже спрашиваешь "что такое Х" - начинают отвечать по учебнику. А вот "зачем нужен Х" - такой вопрос уже не тянут.

А еще мастерский скилл в области "для меня большая честь быть на этом интервью" и прочий корп-булшит. Так что удачи Амазону.

зачем вам миграция

Java 21 начинает приносить game changing фичи после почти 10 лет проходных релизов. Открываются возможности по качественному бусту перфоманса и снижению потребления ресурсов. Меньше платить за ресурсы облака в перспективе - достаточно хорошее обоснование для бизнеса?

зачем коллектив собирается потратить деньги бизнеса

Сервисы в докерах вообще-то. Миграция будет выглядеть как собственно замена циферок версий в сборщике, замена базового образа и прогон автотестов. О каких именно невероятных "деньгах бизнеса" речь? Мы иногда на разбор жалоб от саппорта времени и сил больше тратим, чем на эти миграции.

Хотя про мир Java плохо знаю, может там если релиз, то уж прям огого и ошибок у них никогда не бывает

Я знаю ровно 1 человека, который с пруфами находил минорную проблему в JDK 17 на релизе. Людей, которые своими руками засаживали критические баги в прод, я знаю на порядок больше.

Если бы у меня в конторе стояла задача 100% покрытия дата-классов, то я бы написал плагин и джобу для Gradle/Maven (пишем на JVM) для генерации этих тестов по классам в заданной директории или по маске имени файла. Потом бы вся контора этим пользовалась. А потом бы еще на гитхаб выложил, чтобы на собесах козырять.

Понимаете, вне зависимости от примитивности задачи, ее можно решать по-сеньорски или по-джуновски. Вот у вас на пару с Чятиком получилось прям махрово по-джуновски. Потратить время на промпты и родить одноразовое решение - это вот вообще ни разу не "ChatGPT помогает разгрузить Middle разработчика". В сухом остатке Чятик вам никак не помог. Он, например, не заметил, что его просят сделать какой-то бред и не подсказал обобщенное решение. Произошел типичный garbage in garbage out. Вы тоже не стали скилловее, т.к. на заметили, что здесь просится обобщенное решение и, соответственно, не написали его. На успех Чятика в реальных типичных миддловских задачах вообще рассчитывать не приходится.

Что я понял после двух с половиной заходов на тимлидство - нет повести печальнее на свете, чем тимлид, приходящий со стороны в готовую команду, в которой как бы ничего не нужно менять, а просто грамотно управлять. Ну это в принципе в любом руководстве так. Если оффер руководителя не предполагает карт-бланш вообще на всё, то такое заманчивое карьерное предложение не стоит бумаги, на которой оно написано.

просто написанием тулзовины, которая бы это делала, никто не заморачивался

На гитхабе есть https://github.com/search?q=php dto testing&type=repositories.

На мой взгляд, задачка для студентов и интернов на изучение рефлексии в языке.

Класс DTO, который надо покрыть unit тестами

И нам тут прям никак без одной из самых замороченных систем на свете стоимостью в миллиарды баксов.

Это же тупо через рефлексию и метапрограммирование решается. Самым обычным посконным алгоритмическим кодингом. Причем решается со 100% точностью раз и навсегда и потом тиражируется на все другие DTO в пару кликов.

Не всем так везёт что работодатель готов оплачивать такие переписывания ради того чтобы переписывающие поддерживали себя восстребованными на рынке труда.

Вас спросить забыли, на что деньги тратить. Работодатель оплатил прежде всего себе более надежную и масшатбируемую систему. Потому что запарился с прежним поделием. Еще на сдачу от смузи автотестами все в три слоя обмазал. Благотворительность в пользу красивого резюме русских аутсорсеров - это исключительно ваша больная фантазия.

Проекту лет 12. Но 5-6 лет назад пришла текущая команда и стала переписывать с ноды на джавовый стек.

Не понимаю, на чем вы меня пытаетесь подловить. Нет такого физического закона, который препятствовал бы содержанию кодовой базы в порядке и чистоте. От людей зависит. Кто-то вкладывается в это, а кто-то на попе ровно сидит. Оба подхода легитимны, но в команды второго типа я лично не хожу.

Телеком. Просто фокус в том, что в свое время собралась сеньорская команда и аккуратно по DDD начала разделять ландшафт на сервисы в контейнерах. Помимо всего прочего, это облегчило и инкрементальный апргейд компонентов. Ну и вообще я считаю, что какая бы система ни была сложной в плане моделей и интеграции - возможность апргейда должна быть ортогональна этому всему. Особенно для вещей типа JDK с 99% обратной совместимостью. Иначе как раз и получаем "кровавый" энтерпрайз, где повсюду Гордиевы узлы.

Не узнав ни про опыт менторинга, ни про опыт проектирования систем, не обсудив с кандидатом ни архитектурные вопросы, ни какие-либо еще, которые отличали бы мидла от синьор

У меня был прикол с Тиньком. Тоже проходил их стремные интервью с кодингом. Прошел, но эйчар пропал на месяц, а потом заявил, что я максимум миддл и могу претендовать на сущие гроши. А я успел уже выйти на новое место к тому времени. Ну да и в баню их.

НО. Месяц назад пишет их эйчар, извиняется за тот инцидент 2х летней давности. Мол, тому плохому эйчару сделали атата, дико извиняемся, давайте снова к нам. Я говорю: собесы ваши - херня. Приседать целый месяц чтобы услышать что я едва мидл - мне зачем это надо? Она говорит "Какой такой мидл? Вас на сеньора оценили!". Говорю "Тогда давайте оффер сеньорский". На том разговор и закончился.

Так что вы не горюйте. Потом выяснится, что вы вообще на CTO проходили.

За последние полгода рекрутеры наверное уже раз 30-40 написали мне про этот Яндобиус. Сразу же чекнул, откуда у конторы ноги растут, и контактировать не стал. Видно, и не зря. Конторе нужны вращатели деревьев - значит я пас, я таким на работе не занимаюсь.

Единственная ваша претензия к этому человеку, прозвучавшая изначально — это отсутствие опыта работы с новыми версиями джавы.

Это факт, а не претензия. Мы его прогнали через нашу обычную секцию теории и этап код-ревью. Человек про всякие ресты-rpc не в курсе. Джава кор версии 8+ - не в курсе. Постгрес-индексы-транзакции - не в курсе. Рэббиты-кафки-очереди-асинхронность - не в курсе. Код-ревью тоже завалил. Не, я понимаю, что он там "работал". Но зачем нам, смузихлебам, человек с навыками джуна по цене CTO?

Ага, пригласили даже видя "нерелевантный" опыт, а потом отказали потому что опыт "нерелевантный"

Не зовешь - плохо. Зовешь - тоже плохо.

вы их уже заранее записали в плохих программистов

Не заранее, а после собеса. Это если вы о том человек с Java Swing. Мы же его все-таки пригласили, даже видя нерелевантный опыт. В общем-то рядовая ситуация произошла: человек не подходит под наш фронт работ. Нанять мидла за втрое меньшую сумму тупо выгоднее со всех точек зрения. Когда отшиваешь джуна - всем норм, когда отшиваешь сеньора - почему-то начинаются байки про неработающих смузихлебов.

Вы отвечаете на какие-то свои мысли, а не на мой изначальный тезис. А тезис в том, что не пройти один собес - бывает. Не пройти N собесов кряду - это уже звоночек и повод прям серьезно что-то пересмотреть. То есть если бы вам на каждом собесе предлагали распарсить этот лог - а вы бы каждый раз заваливали задание, то тут уже не в собесах дело.

Информация

В рейтинге
909-й
Зарегистрирован
Активность

Специализация

Бэкенд разработчик
Старший
Java
Kotlin