Обновить
52
4.6

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

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

Вы же даже не поняли о чем речь. Какие личные проекты вообще? Речь про людей, которые пишут что-то типа "работал в ООО Рога и Копыта с 2012 по 2019, правил баги, делал фичи" - и все, другой информации нет. На чем писал, чего достиг, какие проблемы порешал?

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

Кому-то просто по кайфу иметь именно такой аксессуар. Вот мне нравятся Seiko Tuna кварцевые - я купил. Человек иногда существо дико нелогичное, так что не стоит тут спрашивать "зачем ..., если ...".

Как-то недальновидно. После таблицы умножения идут вещи пострашнее. Где-то на квадратных уравнениях придется брать кредит для поддержания регулярных выплат.

В джаве в 99.(9)% случаев используют ArrayList. И вообще есть бест практис работать с листами как с интерфейсом List. А обрабатываются они через стримы (т.е. функторами). Обращаться к элементу по индексу - это реально редкость в энетрпрайзе. LinkedList лично я за 8 лет практики использовал только на литкоде, т.к. этот класс также реализует интерфейсы Queue и Stack.

Реальной проблемы в выборе реализации просто не стоИт. Поэтому вообще ноль проблем, если человек не знает разницу или подзабыл. На самом деле джуны+ и далее знают все прекрасно.

В чем именно ваша проблема? Почему вы продолжаете хамить даже не разобравшись в ситуации?

Графы это наверное уже литкод. К реальному коду отношения не имеет. В реальном коде мы ведь за пределы итераторов никогда не вылезаем. Понял, понял.

Реальный код у каждого свой. Если вам какой-то аспект важнее других - я не против, если вы вокруг этого свое интервью будете строить. Просто смиритесь, что у каждого своя ситуация и далеко не каждому нужен выдроченный курс CS.

Главное от неё держаться подальше

Я рад, что искусство диагноза по аватарке все еще живо.

Во-первых, вы еще пойдите найдите кейс, где в современном джава-приложении ArrayList и LinkedList ведут себя драматически по-разному. Типовая обработка коллекций вся давно на функторах - а они разницу не видят. Сценарий, где мы зачем-то берем энный элемент списка и получаем ту самую разницу O(1) vs O(n) - это экзотика, которая встречается скорее на литкоде, а не на практике.

Во-вторых, если человек путается в этих нюансах, то это решается ровно 1 замечанием на код ревью.

В-третьих, LinkedList в джаве - предмет шуток даже для его автора. Why so serious?

Что-то не выходит драмы.

То есть для вас не звоночек что человек не знает структур данных

Не знать структуры данных, конечно, плохо. Но дело в том, что я не считаю, что отличные ответы по структурам на собесе эквиваленты хорошему их знанию на практике. На моей памяти самые четкие ответы на "как устроена хэшмапа" давали джуны - они же со спокойной душой засаживали в код алгоритмы O(n*n). Сеньор или мидл, наоборот, могут продолбаться на этом вопросе, но код их будет лучше.

Весёлого там вообще ничего нет

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

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

Доктор вполне мог иметь аналогичный случай месяцем ранее. И у вас он просто увидел знакомый паттерн. Вы не можете 100% знать, что тут некая "база", а не обычный рабочий опыт.

Точно так же разраб может решить проблему перфоманса БД не потому, что он собаку съел на реляционной алгебре и внутреннем устройстве СУБД, а просто потому, что разбирал похожий кейс на прошлом месте.

Т.е. лень самому придумать вопосы и темы

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

если человек не знает чем отличается связный список от массива это уже звоночек

Для препода с универа может и звоночек, а для меня нет. Я считаю, что можно писать ПО и без этого. А звоночек для меня, это, например, когда сеньор-помидор декларирует знания трех фремворков и двух баз данных, а потом не может объяснить, чем эти продукты друг от друга отличаются, что для каких случаев лучше подходит, и за счет чего одно работает быстрее другого.

Вы пойдете к врачу который не знает "базу" и умеет лечить только то что лечил на прошлом месте?

Ок, берем врача ЛОРа педиатора. Лечит детям уши. Лечит хорошо. И тут мы ему вопрос по анатомии малого таза, а потом пусть все ферменты поджелудочной железы перечислит, а потом пусть вспомнит названия всех слоев мозга на латыни.

кандидату, который не собирался у них работать

Так я бы может и засобирался бы. Но точно не к людям, которые с постными лицами устраивают тебе "ЕГЭ по джаве" по опроснику с первой страницы гугла.

Чаще всего в резюме написано что "работал работу"

Ну если кандидат про все Х лет своего опыта поднатужился и выдавил только "работал работу", то не зовите такого кандидата, не вчитывайтесь и не корректируйте. И в целом я не согласен с "чаще всего". У нас сейчас на HR доске где-то 15 кандидатов висит. Почти в каждом резюме глаз за что-то цепляется.

А в чем собственно проблема вопросов по базе?

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

Если человек действительно эксперт то легко ответит на них за 5 минут и дальше можно перейти к чему то более интересному

К тому, в чем разница между ArrayList и LinkedList? Или чем в спринге синглтон от прототайпа отличается? Было б смешно, если б не было так грустно. Я специально хожу по собесам как кандидат с целью найти интересные вопросы и темы для моих собственных собесов. Вдохновиться, так сказать. Так вот за последние полгода улов нулевой. Мне просто досадно, что я трачу по полтора часа на очередное обсуждение "Top 50 Java questions you should know"

Тема про БАЗУ вытекает из того, что 90% интервьюеров - лентяи. К собесу надо готовиться с обеих сторон. В резюме надо вчитываться и корректировать свой пул вопросов под конкретного человека, продумывать тактику разговора. Но зачем, если можно подрочить в сотый раз устройство хэшмапы и шлифануть литкодингом. Говорю это как интервьюер, если что (надеюсь, что не лентяй).

Работал я с таким Тимом однажды. Кодить ему не хотелось вообще. Но это полбеды. Взыграла у него тяга к педагогике. Дай, говорит, найму целую пачку джунов да буду их менторить на максималках, а сам ничего делать не буду. Сплошное делегирование, доверие, взращивание ответственности и т.д. В итоге нанял трех джунов, позволил им устроить на проекте лютый трэш, а через 5 месяцев ушел в закат со словами "Моя миссия здесь завершена".

Полгода спустя джунов уволили, самый жесткий ущерб от говнокодинга и говноархитектуры пофиксали. До сих пор тепло вспоминаю селект с 14 джойнами, который был написан одним из джунов и одобрен Тимом. После рефакторинга, к слову, 2 джойна осталось.

А от Тима не осталось ни строчки кода, ни статейки в доках, ни даже PDF с "видением". Был сотрудник, не было - не понятно.

Где можно использовать приём "Скрытый построитель"? Если осознанно — то, разве что, для написания "чистого непонятного кода": кода, формально соответствующего критериям "чистого кода" от теоретиков

Ну вообще-то любой "теоретик" чистого кода скажет, что метод Dispose должен именно что диспозить и ничего более. Иначе SRP и LSP идут лесом. А следовательно, здесь имеем некий буллшит, а не попытку в "чистый код". А сам кейс - еще одно подтверждение того, что любые авторитеты (кодеры MS в данном случае) лажают.

Expressions в большинстве случаев сложнее читать, чем императивный стиль

Мне кажется, вы путаете "сложно" и "незнакомо". Без опыта в погромировании сложно читать императивный стиль. Без опыта в ООП сложно читать код на классах. Без опыта в ФП сложно читать код на функциях высшего порядка и монадах. И так далее.

Да и на оплате бюрократической машины под названием HR вы сэкономите бесконечное количество денег

Ой ли? Прям сплошная экономия?
А давайте посчитаем такие статьи расхода:

  • официальное оформление нового сотрудника

  • организация рабочего места и выдача техники

  • выдача лицензий на ПО, например на Intellij IDEA

  • возможно платное расширение лицензий на джиру или ту же идею из-за превышения лимита сотрудников

  • организация доступа до ИТ-ландшафта конторы

  • затраты времени и сил со стороны сеньоров по введению в проект

  • выгорание сеньоров, если выяснится, что наняли фуфела

  • официальное увольнение фуфела

  • осознание того, что все люди выше отработали вхолостую

Возможно, лично ваша ситуация позволяет нанять кого угодно и дать ему "написать утилитку". Но это даже близко не типовой случай. У меня вот писать утилитки не нужно. Единственное, что я могу дать - задачу с доски. Причем, чтобы дать ее новичку, я еще должен брифинг провести минут на 40. Так что я предпочту как-то заранее знать, что человек не бестолковый.

Информация

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

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

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