Комментарии 283
Ну с HashMap это очень простой пример. А вот если приходится вспоминать каждый раз, как разворачивать(зеркально копировать) BS дерево или как сортировать список только с помощью двух стеков, то это выглядит полным бредом. Поскольку на реальных проектах вы никогда не будете заниматься такими вещами.
Задачки на программирование, спору нет. Но как они отражают повседневные задачи? И что значит уметь программировать? Т.е. выучили вы Кнута, окончили универ, но не смогли отсортировать список с двумя стеками за 10 мин, тупо из-за волнения, все вы не программист, вы уборщик, или дворник?
А они априори должны отражать? Откуда у кандидатов уверенность, что собеседование и прочее должно как-то отражать то, что предстоит в еждневной рутине и периодических авралах? )
Я от части согласен с автором, если вы нанимаете бэкенд разработчика, то и дайте ему тест для бэкенда(спросите попутно про HashMap), а если вы нанимаете человека для расширения ядра линукса, вот тогда можно и поговорить за структуры данных и углубленное знание алгоритмов.
А мне нравится позиция "нанимаем мы человека, а не функцию".
А мне нравится позиция "нанимаем мы человека, а не функцию".
Никто собственно и не забывает, что нанимается в первую очередь человек. Будь то тест или задание на доске или просто беседа, этого будет недостаточно для раскрытия потенциала кандидата.
Когда я провожу интервью, то не люблю превращать его в проверку резюме. Априори считаю, что если человек год проработал бэкендером, то бэкенд на уровне джуна на он худо-бедно знает. А моя задача — оценить его способность вырасти в миддла и выше. И вот тут вот алгоритмы и структуры данных хорошо заходят. И не было ни одного случая, чтобы про них человек рассказал нормально, мы его взяли, а оказалось что как джун-бэкендер не может работать: то ли соврал в резюме, то ли работал по факту, но его выгнали за профнепригодность.
Да, вполне осознанно. Нехватки нет, хотя вакансии не быстро закрываем.
Если что то это не только про алгоритмы, может не ответить про алгоритмы, но ответить про что-то другое. В ходе интервью пытаемся выяснить насколько широк ИТ-кругозор за пределами основных обязанностей что ли.
Закрыть вакансию не проблема, особенно если к примеру вы FAANG (ну или около). С другой стороны куча маленьких и средних компаний. Готов ли я потрать пару месяцев на подготовку к интервью в Гугл как обезьянка переворачивая деревья на каком нибудь leetcode? Да, пожалуй. Готов ли я потрать пару месяцев подготовки для "Рога & Копыта", сомневаюсь. А вот мой знакомый готов, только для него единственная мотивация — деньги, а для меня сам продукт. Кого вы возьмете? Моего знакомого который прочитал пару-тройку книг "кряканья на интервью".
Но как они отражают повседневные задачи?
Да очень просто, на самом деле. Более конкретные повседневные задачи вида «распарсить входную строку, выделив из неё нужные данные», «реализовать операцию Undo для формы», «отображать список из N последних документов, с которыми работал пользователь» и тому подобные — все они решаются с помощью тех же скиллов и участка мозга, которыми вы будете сортировать список на собеседовании. И вы скорее всего не найдёте по ним готовых сниппетов на SO конкретно для вашего приложения.
Т.е. выучили вы Кнута, окончили универ, но не смогли отсортировать список с двумя стеками за 10 мин, тупо из-за волнения, все вы не программист, вы уборщик, или дворник?
А как другие профессии справляются? Водителю: «давайте проедемся по городу, хочу посмотреть на вашу манеру вождения» — «Ой, нет, я волнуюсь, могу из-за этого в аварию попасть». Причём речь не про то, что он там должен именно за 10 минут под психологическим давлением, можно и сказать, что дескать, щас я сосредоточусь, а то начинаю волноваться, когда пишу под наблюдением. Это абсолютно нормально. И если программисту так страшно на собеседовании, что он логично думать перестаёт, ну пусть валерианку пьёт, что ли, или к психологу сходит. Как-то надо же учиться выживать в этом мире, где иногда приходится разговаривать с живыми людьми.
И откуда уверенность, что водитель в той же ситуации экзамена «давайте проедемся по городу, хочу посмотреть на вашу манеру вождения» не волнуется?
Потому что те, кто волнуется не пьют валерьянку и не ходят к психологу. Мне вот и в голову не могло прийти что это может помочь. )) Перестал волноваться на собесах, изменив своё отношение к ним. Хотя иногда даёт сбои. Например, дали простенькую задачу, дали макбук (без мыши!) и оставили одного. Наверное, хотели как лучше, как раз чтобы не волновался, а там, блин, ctrl+c/v не работает и на тачпаде нет правой кнопки мыши — самое позорное моё собеседование за почти 30 лет. Вот купил себе макбук про М1 чтобы больше в таких ситуациях не волноваться, пишу с него ))
Работодатель не наймёт психически неустойчивого человека
Ну вы уж не путайте волнение с психической неустойчивостью. Дайте угадать, сами вы никогда не волнуетесь, ни при каких обстоятельствах, вы же психически здоровы нет? А ваше окружение, вы уверены, что они все как и вы психически устойчивы? Может есть среди них психопаты, которые волнуются перед экзаменом в школе или перед докладом на работе.
А где я говорил про "волнение"? Разве так распереживаться, что забыть свою повседневную работу, это "волнение"? Мы все волнуемся, и я в том числе, и перед экзаменом, и на собеседовании. Но мы же как то их сдаём :)
Разве так распереживаться, что забыть свою повседневную работу, это "волнение"?
А как повседневная работа связанна с реализацией water trapping алгоритма, на коленке за 20 мин? Я то говорю именно что про волнение, а не про паническую атаку, которая сама по себе, кстати не является чем то негативным или психически нестабильным.
Упавший прод и бизнес, кричащий про потери денег и репутации вроде более волнующий )
Упавший прод ...
Как много воспоминаний это нам навеивает, эх. Позвольте поделиться с вами одним из них. У нас был в конторе Дайта Сайентист, мозгище, так сказать, он когда меня собеседовал, завалил буквально задачками типа как найти два пропущенных числа в неотсортированной последовательности чисел, за один проход без сортировки и желательно за память O(1) (я про формулу то знал, но с применением напутал) так что сговорились на O(n) по всем фронтам.
Так вот я когда работать начал я просто обалдел от этого чела. Он в прадакшен завинчивал юпитер лаб, запускал и там же на данных запускал ноутбуки, на ночь. Ну продакшен иногда падал. Про код я молчу.
- в повседневной работе надо логически рассуждать так же как и при реализации алгоритма
- повседневную работу можно разбить на участки по 20 минут
повседневную работу можно разбить на участки по 20 минут
Каждые 20 мин в течение рабочего дня вы стоите перед доской и на вас пристально смотрят несколько человек оценивая каждый ваш вздох?
Я лишь за то что бы эти 20 мин упражнений максимально соответствовали реальным задачам, над которыми работают потенциальные коллеги.
Каждые 20 мин в течение рабочего дня вы стоите перед доской и на вас пристально смотрят несколько человек оценивая каждый ваш вздох?
Нет. И что? Вопрос был "как связана" а не "чем отличается". Разумеется собеседование отличается от работы.
Я лишь за то что бы эти 20 мин упражнений максимально соответствовали реальным задачам, над которыми работают потенциальные коллеги.
Если надо чтобы они максимально соотвествовали, то надо принимать на работу, вводить в курс дела, давать реальные задачи. Но, к сожалению, это дорого, особенно если хочется выбрать из нескольких доступных кандидатов.
Поэтому приходится делать чтобы они не максимально соответствовали, а максимально показывали те же способности. С учетом ограничений по стоимости.
Разумеется, как и любой способ измерения он не точный и дает ложноположительные и ложноотрицательные результаты.
все они решаются с помощью тех же скиллов и участка мозга,
Я ничего не слышал про отдельные участки мозга ответственные за отображения элементов списков. Если смотреть как функционирует мозг в своей целостности, на собеседовании и в повседневной рабочей среде, то можно увидеть огромную разницу(процессы будут совершенно разные).
Водителю: «давайте проедемся по городу, хочу посмотреть на вашу манеру вождения» — «Ой, нет, я волнуюсь, могу из-за этого в аварию попасть».
В том то и дело, если олдскульный подход переводить в плоскость вождения, то вас каждый раз просят заехать на автодром, и управлять тс под углом в ~55,578 градусов, переключаясь между 1 и 2 передачами локтем правой руки и между 2 и 3 передачами левой рукой, выруливая исключительно подбородком. Все это для того что бы понять как вы будете водить в городских условиях. Обожаю этот термин, Problem Solving Skills.
Я ничего не слышал про отдельные участки мозга ответственные за отображения элементов списков
А за логическое мышление — слышали? Вот это оно самое. Зубрить и соображать, это разные области мозга.
В том то и дело, если олдскульный подход переводить в плоскость вождения, то вас каждый раз просят заехать на автодром, и управлять тс под углом в ~55,578 градусов, переключаясь между 1 и 2 передачами локтем правой руки и между 2 и 3 передачами левой рукой, выруливая исключительно подбородком
Ой, всё. Вас послушать, так можно подумать, отсортировать несчастный список — это не детская задачка на элементарную логику, а высший пилотаж, доступный только вундеркиндерам с докторской степенью. А если к этому прибавить ещё «вдруг мальчик занервничал и потерял способность писать код», то вообще страшно становится представить, кого вы там нанимать собрались с таким подходом :)
А за логическое мышление — слышали? Вот это оно самое. Зубрить и соображать, это разные области мозга.
Я про то что работу мозга нужно рассматривать только в своей целостности, а не по зонам. Кстати с логическим мышлением не все так тривиально.
Ой, всё. Вас послушать, так можно подумать, отсортировать несчастный список — это не детская задачка
Когда вы попадаете под снежный завал, небольшой, метр с кепкой, что может быть проще, выбраться из него. Снег рыхлый, сверху убрали и вы на свободе, это же тривиально, это даже не к бабке ходить, список сортировать. А нет, многие так под снегом и остаются, копают вниз или в бок(куда лицо смотрит), вместо того что бы копать вверх, с логикой конечно у них никак, нужно было им к психологу ходить и пустырник пить. Тут метод дедовский есть, нужно лицо освободить и плюнуть, для определения верха и низа и потом копать. Я про то, что для многих собеседование это стресс(давайте, смейтесь, показывайте пальцем, как мы это умеем, ха мднь волнуется перед собеседованием). В стрессовых ситуациях ваше логическое мышление работает не так как вы этого хотите.
Я про то, что для многих собеседование это стресс
Ну стресс, ну ок. Вопрос в другом — ради чего на собеседовании избегать каких-либо вопросов/задач по существу для собеседуемого? Стресс — это вообще ни разу не повод. Собеседование как раз для того и существует, чтобы работодатель выяснил скиллы кандидата, кандидат выяснил условия работы. Если кандидат в таком стрессе, что не в состоянии показать свои скиллы (и бьюсь об заклад, что в таком состоянии он тем более не сможет задать крайне важные вопросы уже работодателю со своей стороны), кто ему виноват, кроме него самого? Пусть решает эту проблему, это в его личных интересах.
Собеседование как раз для того и существует, чтобы работодатель выяснил скиллы кандидата, кандидат выяснил условия работы.
И автор, и я считаем (видимо) что упражнения/тестовые задания(я в принципе не против оных) на собеседованиях, ни коим образом не помогают выяснить скиллы кандидата, а уж тем более кандидату выяснить условия работы. Только и всего.
А потом на работу приходишь и алгоритмические задачи никому не нужны, а больше нужно умение написать «чистый код», продумать архитектуру, разбираться в куче софта(docker, очереди, бд и т.п.)
Я думаю чуть посложнее, например над чем я не справился, реализовать структуру односвязный список(Python) и развернуть её. На словах кажется просто, на деле и бумаге у меня не вышло.
Ну блин, даже не знаю, что вам сказать. Или будьте спокойнее, или качайте соображалку. Развернуть односвязный список — задача ещё проще, чем отсортировать.
Почему например не задачки по высшей математике, по мат. логике например?
Потому что задачи на алгоритмы не требуют никаких специальных знаний, кроме знания своего же языка программирования, и умения логически подумать.
А потом на работу приходишь и алгоритмические задачи никому не нужны, а больше нужно…
Мне в 99% процентах случаев они тоже не нужны. Но если бы я не умел составлять алгоритмы в 1% случаев, многим моим проектам была бы крышка.
Вы именно про вождение или про теорию? Фактор языка и другой страны накладывается, тем более что теория не тестами идет как в России.
С другой стороны, когда поймешь систему, всё легко: на мотоцикле я потом город сдал вообще без проблем, переживал только за площадку (ну, там вполне объяснимо, полностью новая деятельность).
Водителю: «давайте проедемся по городу, хочу посмотреть на вашу манеру вождения» — «Ой, нет, я волнуюсь, могу из-за этого в аварию попасть».А это не совсем корректное сравнение. Для вождения нужен навык, для решения алгоритмических задач, которые ранее никогда не встречались (а такие и стремятся ведь давать), нужен интеллект. IQ очень сильно подвержен стрессу и падает соответственно. Если вы делаете на это поправку в лив кодинге, то в принципе всё нормально) Если не делаете или делаете слишком небольшую, то вы дополнительно выбираете личности с определённым складом характера, «толстокожие» так сказать. Или опытных в собеседованиях)
Любое собеседование будет отбирать по чему-то дополнительному. Если не хочется отбирать, то надо рандомно приглашать на работу всех жителей Земли и проверять их.
Я был и с другой стороны баррикад, когда я проводил интервью. Я вам скажу прямо — до определенной степени скидка на волнение всегда есть, но если реально совсем совсем ничего сказать не может, то никогда никто не даст положительного отзыва и отдельный подход никто искать не будет. Дефицит дефицитом, но не настолько-же!
Это собственно и есть процесс найма. Если вы уж так волнуетесь, что вообще все забывате, то наверно надо куда-то в другую облать двигаться (фриланс или свой проект или opensource) или как-то решать эту проблему чтоб не вылетало из головы.
Если вы ожидаете, что IQ не падает на собеседовании, то вы либо отбираете кандидатов с подготовкой и большим опытом в прохождении собеседований, для которых это нормальный режим функционирования, либо специфичных «толстокожих» людей, которым это собеседование «по барабану».
Все зависит от того, как интерпретируется ответ. Меня, скажем, волнует не то, знает ли человек ответ на вопрос, а то, как он рассуждает. Конечно, лучше задавать более оригинальные вопросы, чтобы исключить случаи "помнит ответ", поскольку единственная цель таких вопросов — выяснить, умеет ли кандидат думать.
Я один раз понял — когда в прошлом веке на первом курсе писал реализацию хэша на Паскале и с тех пор благополучно забыл, потому что в языках, с которыми сталкиваюсь сейчас, хэши уже есть.
Тут дело не в" понять", понять можно все что угодно, ну если мозги еще остались. Работодатель действительно иногда выглядит так, что его самого хочется "отсобеседовать". Какого "фаллоса" я должен помнить про "пузерьковую сортировку", если она гуглится за 1минуту, а последним проектом у меня была задача по созданию биллинга для виртуальных сред?
public int hashCode() {
return 9;
}
Следующий уровень злодейства:
public int hashCode() {
return (new Random()).nextInt(1000);
}Ваш ход.
Это ещё очень синтетически. А как вам мутабельный объект в качестве ключа?
Разве так можно?
Нет, нельзя, потому что при изменении получится неконсистентное состояние. Но если язык это не выражает, а человек не понимает устройство хэштаблицы, а заучивает его перед собеседованинм(см начало ветки), то это всё может очень печально кончиться.
Ух :) я уже за сердце схватился, на питоне такие фокусы точно не прокатят, а вот за Java не был уверен, вопрос-ловушка.
Но ничего вам не мешает сделать или унаследовать мутабельный объект, добавить ему метод __hash__ и запихнуть в качестве ключа в словарь.
Притом пару раз сталкивался с людьми, которые реально пытались что-то очень странное построить на хэшировании мутабельных объектов.
Вот интересный вопрос на stackoverflow на эту тему:
ru.stackoverflow.com/questions/930894/Кастомные-ключи-в-словаре
следующий ход:
-XX:hashCode=2
Вы бы сначала определились, на каком языке программирования этот код (если это вообще код, мало ли), прежде чем о проблемах спрашивать. В такой постановке вопроса — проблема однозначно в вас.
Думаете, это однозначно? Этот код компилируется С компилятором:
#define public long
public int hashCode() {
return 9;
}Если ожидается исходный вопрос с подвохом, то еще и не такие варианты можно придумать. Вы все еще уверены, что по такому коду можно догадаться, какой вы там язык подразумеваете?:)
Этот код компилируется С компилятором:
Нет, код из сообщения выше не компилируется в С. Вы #define-хак используете переименовав слово public в long.
Если приглашают на позицию java разработчика, то логично, что не про с++ будут спрашивать…
В том и дело, что в вашем комментарии с кодом не было ничего про ява и ява-разработчика, просто предложен код — который я успешно скомпилировал как С код, добавив простой дефайн. Значит, это валидный С код, не так ли. В свое время были популярны подобные головоломки, вот вам и вариант того, что не так в вашем коде — дефайна не хватало. А можно и не только на С ваш код запустить:)
Погуглил про метод hashCode() и его отличие от equals()
Моя версия ответа: проблем не будет, будет некоторое падение производительности метода equals() в данном объекте. Если объект активно не сравнивается, то падение производительности может быть ниже статистической погрешности измерений.
Верный ответ? :)
Это же Java?
да
Погуглил про метод hashCode() и его отличие от equals()
я прекрасно знаю как работает equals и hashCode
то падение производительности может быть ниже статистической погрешности измерений.
до тех пора пока вы его не положите в HashSet, Hash* etc… а если у вас миллионы таких объектов, то это оч сильно повлияет на производительность, что для той же хешмапы увеличит стоимость get с O(1) до O(log(N))
Верный ответ? :)
если не хотите закончить как Parler (я о количестве железа), то нет
стоимость get с O(1) до O(N)
Вообще, если не брать совсем уж устаревшие версии Java то c O(1) до O(log(N)), потому что для таких случаев довольно быстро будет строиться бинарное дерево.
Если хэш одинаков, а ключи несравнимы, то на основе чего дерево строить?
На основе System.identityHashCode (это hashCode по умолчанию), то есть банально в качестве хешкода будет использоваться указатель на объект в памяти.
P.S. Вообще-то, код HashMap'ы и т.п. классов легко можно увидеть в той же IDEA, если вам любопытно как все там устроенно. И код там относительно простой.
Да, согласен поспешил с ответом
и немного неуместным на фоне ошибки оценки сложности.я уже признал выше что мне нужно было более точно расписать.
П.с (если упарыватся) В теории возможна ситуация когда у вас много маленьких (в которых не много объектов) хешмап в которых миллионы объектов и тогда у каждой сложность O(N)
Когда я последний раз смотрел код джавовой хэшмапы, там дерево строилось только для Comparable и String. В остальных случаях был связный список.
я прекрасно знаю как работает equals и hashCode
Наверное потому, что вы Java dev/были им недавно или просто для себя пишете на Java? :)
А я узнал о наличии функции hashCode в процессе гугления.
до тех пора пока вы его не положите в HashSet, Hash* etc… а если у вас миллионы таких объектов, то это оч сильно повлияет на производительность, что для той же хешмапы увеличит стоимость get с O(1) до O(log(N))
Вам изнутри Java мира, конечно, виднее, но...:
1. Миллионы объектов в сортированной мапе — это уже далеко не уровень Java junior и для такого подхода должны быть какие-то свои очень специфические причины
2. Класть сложные объекты (да, знаю, что в Java всё объект, включая String) в мапу, которая будет их сортировать (ок, раскладывать по хэшам, но от этого не легче) — уже плохой признак.
3. Осознанно ломать сортировку в объекте, который потом будешь сортировать… ну это уже очевидный выстрел себе в ногу.
В результате вот на такие грабли может наступить только тот, кто осознанно выпрыгнет в жерло действующего вулкана из самолёта без парашюта и для гарантии попробует в полёте застрелиться.
А нормальные люди сначала погуглят (или покопаются в памяти) и вдумчиво выберут тип списка.
Если у вас много объектов и по ним поиск (.Get(obj)) не требуется, то выберут какой-нибудь LinkedList, если нужен доступ по понятному ключу, то это будет какой-нибудь HashMap<int,Obj> или HashMap<string,Obj>
Как итог (и моё Imho человека не из мира Java) — даже если разработчик сходу не может дать ответ, то вариант «хз, дайте пару минут погуглить по функции hashCode() » может быть вполне адекватным.
выберут какой-нибудь LinkedList,
В это-то и проблема. LinkedList настолько плохая структура, что её лучше не использовать почти никогда.
«хз, дайте пару минут погуглить по функции hashCode() » может быть вполне адекватным.
Из мира Java это примерно как профессиональный водитель будет гуглить правило проезда равнозначного перекрестка, так как на правильном использовании hashCode и equals построенно практически все в языке.
Плохому танцору…
LinkedList настолько плохая структура, что половина коллекций в Java использует его в той или иной степени.плохо что вы не видите в этом проблемы
половина коллекций в Java
Сможете перечислить эту самую половину коллекций?
На самом деле, сейчас проверил нашел только одну такую коллекцию — LinkedHashMap. Ну и LinkedHashSet как простая обертка над LinkedHashMap. LinkedHashMap использует аналог LinkedList исторически, так как появилась в 4 версии Java до того как поняли что производительность LinkedList не очень, потом просто не стали вводить какой-нибудь ArrayHashMap, чтобы не усложнять язык.
Плохому танцору…
Это не мое мнение, а официальное Oracle.
But you pay a big price in performance. Positional access requires linear-time in a LinkedList and constant-time in an ArrayList. Furthermore, the constant factor for LinkedList is much worse. If you think you want to use a LinkedList, measure the performance of your application with both LinkedList and ArrayList before making your choice; ArrayList is usually faster.
В целом вполне четко сказано, лучше всегда используйте ArrayList, если все-таки решите использовать LinkedList, померьте сначала производительность, почти гарантировано реализация с ArrayList будет быстрее.
P.S. В стороних библиотеках коллекций, есть лучше реализацию списка с частыми вставками, например TreeList от apache commons.
P.P.S. Подробнее о коллекциях я писал тут.
Сможете перечислить эту самую половину коллекций?
Linked*
HashMap(Ок, там не совсем он, но очень похож, ну и в Java 8 добавлен авто переключатель на дерево).
Плюс все, что реализует очереди, стаки и тд…
Плюс любой функционал туда-сюда, типа истории действий, тоже так или иначе будет основан на Linked List
Linked*
В пакете java.util; их ровно 3, те что я перечислил сам LinkedList, LinkedHashSet и LinkedHashMap.
HashMap(Ок, там не совсем он, но очень похож, ну и в Java 8 добавлен авто переключатель на дерево).
Там совсем не он и дерево и двухнаправленный список это две большие разницы. Вот совсем.
Плюс все, что реализует очереди, стаки и тд…
Как же вы плохо знаете коллекции.
Открываем интерфейс Queue и видим реализации:
— ArrayBlockingQueue, ArrayDeque — на основе массива
— PriorityQueue, PriorityBlockingQueue, DelayQueue — на основе кучи (по сути тоже массива),
— LinkedList, LinkedBlockingQueue — на основе двухсвязного списка, причем практически все это просто многопоточные реализации LinkedList.
То есть не все и даже не половина.
P.S. По сути, двуноправленный список используется только в LinkedList и всех его многопоточных реализациях, LinkedHashMap (и его обертке LinkedHashSet), а так же во множестве устаревших коллекций, которые давно объявленны deprecated (именно из-за производительности).
Бинарная куча — это массив? Ну здрасте.
Вы можете получить доступ к крайним элементам ветки в кучи по индексу?
Вы можете получить доступ к любому элементу куче без необходимости пройти от корня?
Какой это массив? Это и есть в некотором смысле связные списки, только со ссылкой не на один следующий элемент, а на два.
Бинарная куча — это массив? Ну здрасте.
Если откроете PriorityQueue, то обнаружите там массив в качестве хранения и ArrayDeque внутри для организации очереди. Ничего похожего на LinkedList там нет.
Нет, если натягивать, то ArrayList это тот же LinkedList только ноды хранятся в одном месте, но это уже совсем сову на глобус получится.
В целом вполне четко сказано, лучше всегда используйте ArrayList
В приведённом Вами отрывке этого не сказано (отрывок вполне разумный).
И как без практического теста нанимать в условиях тотальной удалёнки? Т.е. как отличать человека, который умеет писать код и синтезировать простенький алгоритм в голове от того, который просто хорошо подготовился к собеседованию и имеет рядом собой бумажки или вкладки браузера с ответами на типовые вопросы?
Можно попросить человека поделится ссылками на код который он писал в рамках каких то опенсорс проектов. Если человек не участвовал в написании опенсорс проектов то в моих глазах это вцелом минус, но если очень надо можно попросить его выполнить несложное тестовое задание. Как вы сами сказали человек знает про SOLID и у него есть опыт работы, т.е. крайне маловероятно что он не может написать FizzBuzz или посмотреть на подсказки в IDE — это может даже джун. Но при этом весьма вероятно что человек волнуется и изза этого не может решить даже простейшие задачи. Зато в спокойной обстановке легко с этим справится
Могли бы вы более детально раскрыть свою мысль про опенсорс проекты? Из моего опыта:
1) Опенсорс проекты как правило имеют лучшее качество кода. Соответственно человек который в них участвовал как правило имеет более высокие навыки чем человек который писал закрытый код
2) Участие в опенсорс проектах предполагает следование определенному принятому флоу разработки как правило включая в себя техническое общение и процесс код ревью.
3) Моральный аспект — участие в опенсорс проектах показывает что человек стремится развиваться и в том числе развивать экосистему разработки.
Понятно что не каждый разработчик много часов в день уделяет вкладу в опенсорс (если это не входит в его должностные обязанности). Но очень часто бывает необходимость починить какой то баг в открытой библиотеке или добавить какой то несложный функционал который нужен на текущем проекте.
Мое ИМХО что как раз участие в опенсорс является отличным (хотя и не единственным) критерием зрелости специалиста
Открыл соответствующий МР. Из моих выводов:
1) Вы принимали участие в достаточно сложных проектах. Это говорит о том что вы можете разбираться в большой кодовой базе и вносить в нее изменения.
2) Данный реквест по максимуму сохраняет обратную совместимость. Тоже плюс вам
3) Реквест был на ревью длительно время (около 6 месяцев вроде). Это говорит о вашем терпении и способности вести нудные технические дискуссии с индусами на англ. языке.
Из того что мне не понравилось сходу:
1) Реквест очень большой по обьему. Посмотрел что там большая часть диффа это изменения xml тестов. Я бы обязательно спросил почему нельзя было сделать его меньше и вмерджить частями.
2) В реквесте много комитов "Merge from master" и как минимум один фикс комит после ошибочного мерджа. Тут я бы спросил почему сделано именно так. Либо вы не умеете пользоваться git rebase и тогда это серьезный минус в моих глазах. Либо же это может быть политикой конкретного репозитория.
Я очень давно писал на C# и поэтому не берусь судить качество кода, но возможно предложил бы обсудить почему отдельные моменты сделаны именно так.
Вцелом даже такой комит в моих глазах является очень большим плюсом Вас как кандидата и если бы я нанимал C# разработчиков то думаю минут 20 мы могли бы его обсуждать
Ну я пока не настолько заинтересован Вас нанимать, чтобы вчитываться в детали :) тем более я давно не пишу на обоих этих языках.
1) пожалуй, да.
2) так быстро вы это проверить не можете. Скорее всего судите по комментариям, а это не показатель того, что совместимость действительно сохранилась.
3) Индус там был один, и никаких долгих и нудных дискуссии. Вся переписка могла бы быть сделана только с помощью переводчика.
Итого из всего PR вы по сути смогли однозначно определить лишь 1 пункт.
Возможно, если бы вы прошлись по коду, то нашли бы ещё что-то интересное. Но у меня есть обоснованные сомнения, что вы бы по этому коду смогли понять, насколько хорошо я программирую вообще, или конкретно на C++/C#. Впрочем этого мы не узнаем.
Одно дело, когда мы берём публичного в опенсорсе человека за которым следили, или человека с которым общались, возможно работали над каким-то проектом.
Другое, когда мы берём какого-то рандомного человека, который делал непонятно что, непонятно сам ли он это делал, и какой ценой он это сделал.
Для вас, как для соискателя, да полезно иметь опенсорс портфолио. Так же как и полезно ходить на тусовки и выступать на конференциях. Но для работодателя в общем случае наличие какого-то опенсорса у соискателя мало о чем говорит.
Ещё раз, вам, как соискателю это помогает, это я не оспариваю. И даже мой пример можно подать в хороше свете. Я говорю о том, что опенсорс должен рассматриваться чуть достовернее тестового задания на дом (я против тестовых заданий).
Особенно если профиль давнишний и не с эпизодическими коммитами.
Знаете, мне недавно карма за ответ на SO прилетела. Так вот, я его не понимаю. Я не понимаю свой ответ на SO, которым писал сам, и который мне лайкают… А по нему можно тоже предположить, что я знаком с темой.
Открытый код — отличный повод обсудить его. Но программирования в реальном времени он не заменяет
В итоге, чтобы адекватно оценить опыт участия кандидата — надо изучить эти опенсорс-проекты, и вычленить его вклад туда, и опять же оценить этот вклад.
Конечно нужно, в этом же и смысл. Вы можете легко открыть комиты этого человека и посмотреть что именно он делал. Посмотреть качество именно его реквестов. Если опенсорс проект состоит из дикости и костылей, и человек только увеличивал количество дикости и костылей, конечно такой разработчик вам не нужен.
Гораздо проще и экономнее по времени это выяснить на собеседовании, задав нужные вопросы.
Спорный вопрос, собеседования надо назначать выделить для этого удобное всем время. Бегло глянуть несколько комитов от кандидата как правило не занимает много времени, а уже позволяет составить первое впечатление. В дальнейшем на собеседовании можно дополнительно задать вопросы по тем или иным вещам и например обсудить спорные моменты. Из моего опыта это очень хорошо в моральном плане т.к. вы не пытаетесь задавить кандидата своими знаниями или вопросами по незнакомой ему теме, а наоборот общаетесь на тему которую он знает и это помогает ему лучше показать его реальный уровень.
С другой стороны, если это состоявшийся специалист, с большой долей вероятности он в опенсорсах не участвует по одной простой причине — ему за это не платят.
Тут думаю у каждого свой собственный опыт. Мне например нравятся мои текущие/прошлые места работы именно потому что там в рамках рабочего времени можно вносить вклад в том числе в опенсорс. Т.е. у нас либо часть проекта имеет открытый код (в последнем проекте 90% кода открыто) либо же можно тратить время на улучшения опенсорсных библиотек используемых на проекте
Если опенсорс проект состоит из дикости и костылей, и человек только увеличивал количество дикости и костылей, конечно такой разработчик вам не нужен.Вот это не факт. Это может быть умением писать достаточно хороший код. Если ты в каком-то проекте разово реализовываешь нужную тебе фичу, едва ли ты будешь причёсывать им весь код и делать какие-то глобальные изменения архитектуры.
А вариант "В опенсорсе всё устраивает, не возникало необходимости контрибьютить"?
В итоге, чтобы адекватно оценить опыт участия кандидата — надо изучить эти опенсорс-проекты, и вычленить его вклад туда, и опять же оценить этот вклад. Гораздо проще и экономнее по времени это выяснить на собеседовании, задав нужные вопросы.а в чем проблема посмотреть его коммиты/пул реквесты? Ведь проект то открытый. Это с рабочим кодом в 99,99% ответ будет — у нас NDA ничего не могу показать
Если тред не читали, то и вам предлагаю поупражняться: https://habr.com/ru/company/skillfactory/blog/538240/#comment_22568182
Я jsник с примерно 10ю годами опыта в проектах совершенно разного масштаба. То есть вроде не совсем зеленый. Но любовь опенсорса некотоырми работодателями по прежнему вызывает у меня непонимание.
И вот почему:
1. Тезис «опенсорс имеет лучшее качество кода» кажется мне крайне сомнительным, если прямо не сказать ложным. Может быть в вашей экосистеме это не так, но в js громадное количество опенсорса из грязи и палок. В котором грязи больше чем палок :)
Да, если кто-то хочет открыть код своего проекта, он обычно его причесывает. Но также полно примеров того как какой-то эксперимент на коленке становится почему-то популярным.
Да, есть много примеров опенсорс библиотек с хорошим качеством, но самые лучшие образцы кода мне попадались именно в энтерпрайзе.
2). Со вторым вашим тезисом я также не согласен. Кажется Вы выбираете лучшие опенсорс проекты а не типичные опенсорс проекты. В хороших закрытых проектах с техническим общением и код ревью тоже все в порядке.
3). С этим я согласен.
Но есть некоторая проблема — некоторые соискатели прохавали это и пытаются хакнуть этот показатель. С виду крутой гитхаб, а как посмотришь повнимательнее — коммиты в популярные пакеты состоят из исправления опечаток в документации.
В целом мне приходилось работать с разными коллегами, в том числе теми кто могут показать крутой опенсорс. И вот так уж сложилось, что лучшие из них — не могут показать опенсорс и близко. А человек у которого есть довольно популярный проект (несколько тысяч звезд на гитхабе) оказался посредственным разработчиком, просто очень общительным и активным в комьюнити.
То есть исключительно на моей выборке коллег фактор опенсорса оказался бы совершенно не показателен. Может это исключительно призма моего опыта
Тезис «опенсорс имеет лучшее качество кода» кажется мне крайне сомнительным
Да возможно я излишне оптимистичен насчет качества кода. Из моего опыта я сталкивался с качественными проектами, но понятно что бывают варианты и хуже.
В хороших закрытых проектах с техническим общением и код ревью тоже все в порядке.
Возможно, но вы об этом не узнаете пока не спросите. В опенсорсных проектах это сразу видно глазами.
Моя основная идея не в том что участие в опенсорс проектах гарантирует высокое качество кандидата. А в том что вы можете своими глазами посмотреть на код который пишет кандидат и оценить его. Это намного лучше чем предлагать синтетические задачки и ждать что найдется кандидат который угадает что именно вы хотите услышать от него.
Да такой подход предполагает больший расход времени и усилий со стороны нанимающей компании т.к. надо потратить время и разобраться в том коде который собственно прислал кандидат. Зато он позволяет примерно оценить какой именно код кандидат будет писать в случае найма. Т.к. уже приводили примеры случаев когда кандидаты зазубривали все стандартные вопросы и успешно проходили собеседование, а на испытательном сроке выяснялось что они собственно не умеют программировать.
Это — неоспоримое преимущество опенсорса как для нанимателя так и для нормального соискателя. Уровень легче оценить.
Оценка кандидата когда нет возможности посмотреть его реальный код — сложнее. И ее также можно сделать более или менее качественно с соответствующими затратами времени и усилий.
Требования опенсорса рождают проблему для нанимателя. Эта проблема — bias в сторону тех кому есть что показать. То есть мы скорее наймем среднего кандидата коммитящего в опенсорс и не наймем отличного не делающего этого.
Если это делается осознанно и вписывается в стратегию найма компании — отлично. Но к сожалению это не всегда так.
Нередки случаи когда bias в сторону опенсорса рождается из за недостаточных коммуникативных компетенций ответственного за найм. Ну то есть поручили найм инженеру который не хочет во все эти ваши софтскилз. В результате человека нанять не могут очень долго.
В моем случае это не требование, а скорее дополнительный плюс. Понятно что мы не откажем человеку просто потому что у него нет хороших примеров опенсорс кода. Просто в таком случае на собеседовании прийдется обсуждать уже задачу предложенную нами. А это может вводить кандидатов в стресс и они могут показывать худший уровень чем могли бы. Т.е. у меня обычно подход такой:
1) Найти пример из прошлого опыта кандидата который бы показывал релевантные мне навыки и опыт. Обсудить этот пример кода для того чтобы понять почему были приняты те или иные решения и насколько глубоко канидат разбирается в смежных темах. Основная идея в том что разговор на знакомую кандидату тему позволяет ему расслабится и вспомнить реально интересные вещи из его опыта.
2) Если такого примера сходу найти не удается то предложить какую нибудь другую задачу. Задачу из нашего практического опыта либо более синтетическую но затрагивающую интересные мне темы
Просто многим компаниям свойственно заимстовать ту или иную практику оценки кандидата и превращать в карго культ, забывая об условиях ее применимости. Этот путь например прошли круглые люки и непотребства с бинарными деревьями на доске. У меня есть легкое ощущение, что в моей js экосистеме, где опенсорса ну очень много, — это один из самых популярных текущих карго культов найма. И упоминание «хотим опенсорс» в вакансии — оно нередко вызывает легкий негатив. Те у кого есть — сами все покажут :)
В моем случае это не требование, а скорее дополнительный плюс.
Это разумно
А это может вводить кандидатов в стресс и они могут показывать худший уровень чем могли бы.
Такое тоже может быть, но я рассуждаю так: если из пришедших на собеседование кандидатов я выберу того, кто и умеет писать код, и не падает на задницу, приходя на собеседование, и упущу кого-то, кто умеет писать код, но в стрессовых ситуациях не умеет, то я на самом деле выберу лучшего кандидата.
то я на самом деле выберу лучшего кандидата.
Такой подход хорошо работает в больших компаниях когда у вас есть возможность держать открытую вакансию несколько месяцев. А также у вас есть достаточное количество кандидатов. В небольших компаниях это может быть несколько расточительно. Мне надо делать проекты вот прямо сейчас, и вобщем-то без разницы если человек например заикается, но при этом может писать нормальный код
Мне вот абсолютно нечего показывть поскольку мне явно контрактом запрещено прграммировать на себя (ну на самом деле надо разрешение на open source contribution брать, но это все равно что запрет). А вот программировать на бумажке совсем не обломно — я всегда уболтаю интервьювера что синтаксис не важен, а параметры «вот примерно такие, но точно не помню». Если настаивают, ну что-ж, это значит контора весьма низкого уровня. Но такого еще не было. Было что требовали гораздо сильнее математику чем я могу, но это нормально.
ответ будет «не помню» или «дурак был»
Честный ответ это уже весьма неплохо, но обычно стараемся выбрать более свежую тему а не код 10-ти летней давности.
Мой подход не догма, основная его идея в том что обсуждение задачки уровня FizzBuzz может быть неплохо для джуна, но для разработчика с опытом эта задача слабо полезна чтобы понять его уровень и знания.
Наилучшим подходом я считаю обсуждение реальных решенных задач и реального кода который написал кандидат. Программирование на бумажке на мой взгляд не может дать того же представления потому что для решения например сложной задачи надо потратить только пару часов для обдумывания подходящей структуры данных или например удачных абстракций. Такие задачи можно предлагать как тестовое задание (но многие не захотят его делать) или попросить кандидата показать какие либо примеры его кода.
А вот программировать на бумажке совсем не обломно — я всегда уболтаю интервьювера что синтаксис не важен, а параметры «вот примерно такие, но точно не помню».
А могли бы вы привести типичный пример задачи которую вам не обломно запрограммировать на бумажке?
Обсуждение реальных задач тоже работает до определенного уровня. Если до уровня кода — то я например окажусь обсуждать ибо под NDA. А выше уровнем, ну так все та-же проблема отделить болтунов.
Я обычно на две части делю интервью. Быстрый тест чтобы совсем деревянных отсеять. Это вообще не программисты. Это те, кто тот-же fizzbuzz написать не могут. И вторая часть разговор по теме. там тоже есть код, но ни синтаксис ни даже ошибки в алгоритме не особо влияют если человек может объяснить что он собственно хотел. Ну и вопросы потом от кандидата, но это стандарт.
Вот навскидку: представьте что у вас не два условия а два миллиарда.
Ну если честно ваш пример усложнения выглядит немного высосанным из пальца...
Вопрос который мне реально нравится и который тоже можно долго обсуждать это например "что происходит когда вы вбиваете в адресную строку https://google.com"
И вот тут уже можно оценить большой пласт знаний кандидата по целой куче направлений
Помню как-то начал отвечать на такой вопрос с чего-то вроде "нажатие клавиши H замыкает пересечение двух линий"
- Тезис «опенсорс имеет лучшее качество кода» кажется мне крайне сомнительным, если прямо не сказать ложным.
Значит ли это, что весь ваш код лучше кода PostgreSQL, SQLite, Haproxy, etc? И djb ни в какое сравнение с вами не идет? Покажите же свой код, чтобы развеять все сомнения.
А вот коммиты в средней руки опенсорс — вообще ничего не гарантируют.
Так в том и дело, что вы можете посмотреть коммиты и оценить или эти коммиты, или сами проекты. Есть множество высококлассных открытых проектов, которые «на слуху» — и в большинство из них шлют коммиты тысячи разработчиков, просто потому, что так удобнее, чем поддерживать свой форк.
Ок, давайте на примерах. Разработчик на дебиан/убунту через год-другой обзаводится своим репозиторием пакетов, поскольку то бэкпорт нужен, а то и вообще нужного пакета нет. К имеющимся пакетам периодически приходится слать патчи, ибо то эскулайт криво соберут (примерно так с 2005 по 2015 в дебиане все пакеты эскулайт точно были собраны через одно место), то веб-сервер вообще не работающий окажется (аол сервер годами в пакетах был поломан, потому что мантейнер не знал, как его вообще проверить). И да, обычно это обсуждается в рассылке соответствующих проектов, прежде чем мантейнеру дебиана изменения предлагать и/или свой пакет делать.
На маке — да все то же самое, только пакеты Homebrew.
Далее, для питонистов бывает нужно портировать себе пакеты Анаконда, а они собираются древним GCC (8м, если правильно помню) и, соответственно, OpenMP и OpenMPI требуют собранные тем же древним GCC и их нужно собрать и без конфликтов к нормальным системным установить… правильно, и тут нужен свой репозиторий пакетов.
И это мы еще программировать не начали — только подготовили среду для работы:) Начинаем данные готовить, для прототипа эскулайт идеальная база, закидываем туда — а оно на четырех гигабайтах данных в одном сценарии падает (реально падало, правда давно, там пачка багов была, но они мало кому мешали), а на сотне гигабайт там индексы тормозят (тоже реальный случай, пришлось сжатие индексов добавлять и долго убеждать апстрим, что им это тоже надо). Ладно, данные готовы, поставим какой-нибудь веб-сервер и Haproxy — ой, а в нем нужной директивы нет, надо патч автору послать.
В общем, к моменту написания хоть открытого, хоть закрытого кода, у разработчика уже есть свои репозитории пакетов, обсуждения в нескольких рассылках, пачка разосланных патчей в разные проекты. Имхо все проекты, рассчитанные на порядка 10 лет продакшена, примерно так начинаются — иначе нереально все это годами на множестве серверов поддерживать потом. Ну пусть у вас будут докер-пакеты вместо дебиановских пакетов, суть не меняется.
Среди коммитов и комментариев на текущей работе (у нас, например, всякие унылые SDK, API и доки все в паблике) и среди прочих Contribution activity (не вижу там никаких фильтров).Я примерно так смотрю профили Github и Gitlab, ну иногда получается что-то увидеть и вычленить что-то говорящее о разработчике, в своём собственном — не очень. Кстати, у многих разработчиков профиль полон ещё чем-то вроде «X commits to a private repository». Предыдущие годы смотреть, разумеется, вовсе не проще.
Профиль в Github тяжело анализировать, в общем, много бесполезного мусора, а удобную фильтрацию не завезли. Только если кандидата заранее просить показать свои выдающиеся коммиты.
Могу и вам предложить мой коммит https://habr.com/ru/company/skillfactory/blog/538240/#comment_22568182
Если вы, конечно, тред тот не прочитали.
Из моего опыта:
А вот из моего опыта: десять программистов в нашей небольшой компании. Отличные парни и как профессионалы, и просто как люди. Все разные, у кого-то семья, кто-то музыкант, кто-то учит китайский и т.д. У девяти из них нет ни одного вклада в опенсурсные проекты.
ИМХО, условие участия в опенсурсных проектах круто сужает ваш поиск специалистов до относительно небольшой группы преимущественно одиноких гиков, у которых хобби совпадает с профессией. Зачем?
Ответил на такой же вопрос в другой ветке — https://habr.com/ru/company/skillfactory/blog/538240/#comment_22568614
1) или у человека навык писать код необходимого для проекта качества, а где по факту выше в закрытом или открытом у него было, никто не знает кроме имеющих доступ к закрытому
3) или чисто практический аспект: используемая на работе либа содержала багу, сделал фикс, чтобы не ждать, отправил в апстрим чтобы не мучаться с поддержкой своего форка.
Могли бы вы более детально раскрыть свою мысль про опенсорс проекты? Из моего опыта...
Из моего опыта их не было ни у одного из трех десятков людей, которых я собеседовал. Даже ссылки на гитхаб в резюме, просто чтобы посмотреть примеры кода, были от силы у каждого третьего.
Почему же отсутствие опенсорс-кода минус? Я встречал очень талантливых разработчиков, которые не написали ни строчки опенсорс-кода. Не всем близка эта идеология, есть те, кто просто хочет за работу получать деньги.
А для кого-то это минус. Сейчас он подгтовился, было время, а когда прилетит критикал баг на проде времени готовиться не будет )
При этом я особенно не понимаю некоторые из фаанговых компаний, которые отдельно перед собеседованием рассылают материалы для подготовки, где написано, условно, какие алгоритмы надо знать (из очень ограниченного множества). Что это проверяет? Кратковременную память?
Это снимает с вас стресс. На собеседовании стараются оценить все ваши знания. Какие-то из них могут быть в долговременной памяти и на работе у вас будет время их достать, а на собесе — нет. Как отличить знания, которые вы не успели вспомнить, от тех, где вы просто плаваете? Чтоб не тратить время ни ваше, ни собеседывающего, вам предлагают освежить их в памяти.
Что это проверяет? Кратковременную память?
Умение понять и применить алгоритм?
Ваши же разработчики-программисты не работают в пещерах без связи с мировым пространством информации?
P.S. Можете ещё почерпнуть каких то идей по собеседованию на примерах каких то задач на rosettacode.org и возможно протестировать владение мультиязыковостью у претендента на ваши «галеры». :)
Если уже речь зашла о Java, то надо требовать ентерпрайз решение, а не эту детскую поделку.
А ещё можно вот так решать, хоть это и недостаточно энтерпрайзно.
Или другой вариант — дать кусок кода и попросить рассказать, что каждая строчка в нем делает. Если кандидат не программист, то прочитать код он не сможет. А если может прочитать код, то и написать код он тоже сможет.
И ладно бы просили решить упражнение из учебника по языку программирования для 1 курса, на 10 строчек кода.
(Если нанимают мальчика-кодировщика, это еше куда ни шло).
Но ведь есть любители подсунуть под видом тестового задания вполне рабочий законченный проектик, трудоемкостью в несколько человеко-дней. (Типа, вот сделайте, тогда и поговорим. Вдруг найдется дурачок, который согласится побыть бесплатной рабочей силой?).
И еще хорошо, если потом позвонят и сообщат что вы им не подошли.
А иногда сразу видно, что тестовое задание — это не более чем чей-то курсовой проект для ленивого студента.
Об этом собственно и речь в статье. Подобный подход очень хорошо отсекает недостаточно квалифицированных кандидатов, но одновременно с этим он с большой вероятностью отсечет и квалифицированных ребят которые по какой то причине не смогли сходу предложить решение вашей задачи. Простой пример — толковый человек может не написать сходу сортировку двухсвязного списка и потратит много времени чтобы сделать более-менее толковое решение. Исходя из этого вы эту задачу оцените условно на 3 из 5. При этом время уже будет потрачено и вы не сможете пообщаться на более сложные темы и не узнаете что человек например хорошо разбирается в работе ядра линукс или еще каких то сложных и глубоких темах которые вам возможно актуальны на текущей работе. Т.е. если вам надо чтобы на работе человек решал олимпиадные задачки — спрашивайте на собеседовании олимпиадные задачки, а если надо чтобы человек писал драйвера — спрашивайте про драйвера
Вот да.
И второй поинт – написанный код можно обсудить. Например, как он изменится при изменении каких-то условий. На этом этапе как раз и отсеются те, кто заучил стандартные вопросы.
ЗЫ: imho разумное количество кода – такое, чтобы его можно было написать на листочке.
Только до первой задачи может месяц пройти.
1) Многие люди в первый месяц работают продуктивнее. Но не все, чтоб это было так уж легко учитывать
2) Прям суперсложные задачи вы всё равно не дадите, а на легких только джунов отсеете.
3) В Больших корпорациях есть 1000 и 1 возможность иммитировать бурную деятельность.
Так что, бывают случаи, когда и 3х месяцев недостаточно.
Никогда, никогда, никогда не нанимайте людей, не проверив их умение писать код! Я видел миллион примеров, когда человек очень круто всё говорит, но на деле не может решить даже простейшую задачу. Если вы нанимаете человека программировать и не проверяете, как он программирует — может, что-то не так?
Тут может быть дискуссия на тему сложности задач, но они должны быть обязательны, пусть даже тривиальные. Например, вывести наиболее часто встречающийся символ в строке. Даже по этому, казалось бы, простому заданию можно многое узнать о кандидате.
Если за 3 месяца не могут оценить кандидата, то это чертовски странно. Возможно, стоит что-то поменять.
Нет, я говорю, что никаких выводов без тестового задания делать нельзя. То есть это минимум. Дальше уже сильно зависит от позиции, компании итп.
Бэкграунд вообще ни о чем не говорит, к сожалению — я проверял и даже писал про это в статье :)
Смысл заданий типа FizzBuzz — отсеять тех, кто точно не умеет нормально код писать. Таких людей на роль программистов нанимать большого смысла нету. Что там при этом написано в бэкграунде — не особо важно.
Через цикл и if-else решенная задача FizzBuzz — это нормально или нет? (Потому что выше человек пишет про always true, значит там как минимум не так было написано)
Чтобы это хотя бы был псевдокод, который работает. Через цикл и if-else конечно нормально, особенно если в условиях ничего не напутано :)
Условно, если бы это был код на питоне, то я бы на старте смотрел на такое:
как минимум, результат должен совпадать с требуемым
что синтаксис в принципе адекватный
цикл присутствует (хорошее место, чтобы потом спросить про генераторы и xrange/range в 2 питоне, и что делает range в 3)
что кандидат понимает концепцию деления с остатком
что в случае значения 15 будет написано и fizz, и buzz
Я понимаю, что это звучит довольно тупо, но часть кандидатов валится на таком задании! То "забыл" как в питоне функции оформляются, то в условиях намудрил, то остаток от деления проверяет, что он не равен нулю, вместо проверки на равенство. Ход рассуждений тоже важно видеть: кто сначала чуть подумал, какие варианты могут быть; кто проверил свой код, после того, как его написал.
/**
* FizzBuzz тест
*
* @param i число, которое нужно обработать
* @return строка:
* <li>если параметр <b>не</b> делится (нацело) на 3 или на 5 - значение парамера в строковом виде</li>
* <li>если параметр делится (нацело) на 3 - строка "Fizz"</li>
* <li>если параметр делится (нацело)на 5 - строка "Buzz"</li>
* <li>если параметр делится (нацело) и на 3 и на 5 - строка "FizzBuzz"</li>
*/
static String fizzBuzz(int i) {
return "";
}
Если тест зелёный, а код страшненький (тот же FizzBuzz с тремя вложенными if-ами, в каждом из которых куча всего наверчена), то это повод поговорить о рефакторинге — считает ли соискатель такой код хорошим, и как бы он его поменял.
Заодно становится видно, владеет ли он меню Refactoring и клавиатурными сочетаниями в своей IDE (для Java IDEA практически уже стандарт отрасли)
В Германии типичный испытательный срок равен аж 6 месяцам. И я многократно слышал истории когда человека увольняли буквально за день до последнего дня когда ещё можно уволить :) К примеру к моего коллегу так сократили в корону на его предыдущей работе.
Мне бы например было бы приятней и менее стресово написать с нуля микросервис, чем вспоминать что там как нужно выводить символ в строке. Причем минут за 10 можно прилично набросать уже. Потом понять что сказал не самый эффективный способ по подсчёту символов в строке, или использовал не тот метод который хотел интервьюэр, и опять нервничать :)
Мне кажется я в своё время попал в небольшой пузырь, с одними и теми же рекрутёрами, компаниями и ИТ-тусовочкой.
ПыСы — несколько собесов успешно прошёл xD
Только взяв человека в команду и плотно поработав с ним, можно делать далеко идущие выводы, пригоден ли он в конкретном проекте или желательно его заменить на другого специалиста.
Я из тех людей, кто просит решить простую задачку на собеседовании (требуется буквально 3 строчки кода, но обычно пишут десяток). Эту задачу я с каждым кандидатом обсуждаю, предлагаю улучшения и смотрю как кандидат реагирует, знает ли о чем идёт речь, понимает ли вообще что я говорю. Таким образом, как мне кажется, я довольно точно могу поделить соискателей на три категории:
1. Вообще не знает программирования.
2. Знает общие подходы, умеет решать задачи.
3. Понимает, почему задачи решаются именно так и как это устроено.
На моей практике был реальный опыт, когда соискатель очень убедительно рассказывал о том какой он специалист, какие классные штуки умеет делать, какие паттерны применяет итд. На деле же он вообще не смог написать решение простейшей задачи.
Так же на моей практике был опыт, когда вполне достойный программист не дожидаясь окончания испытательного срока начал просто филонить и фактически саботировать работу включая нарушение трудовой дисциплины и должностной инструкции. Выявить такие недостатки на собеседовании не получится никак, к сожалению.
PS: Увидел в комментариях отзывы вида «учу hashmap перед собеседованием чтобы забыть». Мне непонятен такой подход: я знаю приблизительно как он устроен (в реальном коде — тонна оптимизаций, которые не всегда нужно помнить) и когда я его использую — я принимаю некоторые допущения, которые учитываю при разработке кода. Без понимания внутреннего устройства — программист вынужден принимать решения случайным образом, что плохо сказывается на качестве кода. Это влияет не только на производительность, но и на правильную обработку граничных случаев.
Интересно, что за задачка в три строчки. Можете привести условия? Если не хотите палить, можно в личку. Просто сгораю от любопытства, что можно уместить в три строки, и при этом, в основном, все пишут десяток.
Есть например задачка найти два максимальных элемента массива. Которая легко растягивается на десяток строк.
$arr = [1,2,4,5,4,76,7,8,9,90,0,10];
if(count($arr) < 2){
throw new RuntimeException('Array must contain at least two elements');
}
$max1 = PHP_INT_MIN;
$max2 = PHP_INT_MIN;
foreach($arr as $v){
if($max1 < $v){
$max2 = max($max1, $max2);
$max1 = $v;
continue;
}
$max2 = max($max2, $v);
}
И получить сложность O(n log n), хотя можно за линию.
Тогда на последнем шаге при мерже двух подпоследовательностей с предпоследнего шага вы потребляете k₁ элементов первой подпоследовательности и k₂ из второй, при этом k₁ + k₂ ≤ k, и ровно столько сравнений вы сделаетеЯ может что-то не так понимаю, но на последнем шаге до мержа двух оставшихся подпоследовательностей вы уже сделали «nlog(n) — n» операций. Я думаю, что merge sort совсем неприменим, если у нас задача сделать итератор по списку как отсортированному (я так понимаю, такая задача эквивалентна ленивым спискам).
Ну может этот более наркоманский алгоритм деления и меняет всё дело. Всё же известное мне нахождение k-ого наибольшего элемента за линейное время — в какой-то мере quick sort. Просто мне не удалось быстро прикинуть, как с ним сделать лог-линейную сортировку, было любопытно, если это вообще возможно.
function two_max(array $arr) {
rsort($arr);
return [$arr[0]??null, $arr[1]??null];
}
три строки в данном случае утрирование, конечно. Но бывают кандидаты, код которых в два-три раза больше вашего
Вот ещё одни, прям так и пишут, что натаскают вас на интервью: https://habr.com/ru/post/538244/
Всегда забавно слушать вопросы из разряда «чем отличается абстрактный класс от интерфейса» на позицию Senior в тот момент когда ты в данный момент работаешь на аналогичной позиции и собеседующий об этом знает.
Это забавно ровно до того момента, пока вам на собесе не попадется синьор-помидор, который в ответ спросит «а что такое интерфейс». Утрирую, конечно, но тем не менее.
Иногда на людей у которых мало опыта собеседований прямо реально ступор нападает и они не могут решить простейшие задачи или ответить на вопросы которые знают.
А вообще обычно все могут решить эту задачу но при этом основное внимание идет к деталям, таким как проверка границ цикла, оптимальность порядка проверок и прочие мелочи. Это как раз та причина почему я не особо люблю такие задачки, потому что для меня нормально вначале накидать решение кое-как лишь бы проверить работу идеи, а потом уже сделать несколько итераций рефакторинга чтобы довести реализацию до приемлимого уровня.
Это как раз та причина почему я не особо люблю такие задачки, потому что для меня нормально вначале накидать решение кое-как лишь бы проверить работу идеи, а потом уже сделать несколько итераций рефакторинга чтобы довести реализацию до приемлимого уровня.Вам кто-то на собесе говорил, что это плохо?
На своей должности мне очень редко приходиться писать код своими руками. За прошлый год например я этим занимался в лучшем случае несколько часов. Основное время уходит на постановку задач, код ревью и митинги… Поэтому иногда даже при решении простейших задач бывают проблемы типа "забыл как написать цикл на языке Х". Понятно что если мне надо писать код я могу это быстро подглядеть в мануале.
Но на собеседовании по времени не укладываюсь, и в итоге остается наполовину рабочее решение… Это и мне неприятно и думаю производит не лучшее впечатление на собеседующих. Поэтому я вцелом горячо поддерживаю идею не заниматься программированием на собеседовании.
Зачем на собеседовании писать на языке, на котором вы забыли как писать цикл?
И почему перед собеседованием не вспомнить как писать хотя бы на одном каком-то языке?
И почему перед собеседованием не вспомнить как писать хотя бы на одном каком-то языке?
Если в общем то готовиться к собеседованиям я не вижу смысла. Потому что я работаю работу и меня нанимают для того чтобы работать работу. Скилл ее работать и так растет по ходу дела. Если я буду готовиться к собеседованиям то у меня будет расти скилл "проходить собеседования". Это вцелом тоже полезный скилл и я знаю много людей которые построили с ним успешную карьеру, но мне такой вариант не нравится.
Готовиться можно по-разному. Можно зубрить как человек из первого комментария, а можно просто освежить в памяти те навыки, которые требуются на предполагаемой должности, но которые в работе вы используете не часто.
Согласен. Но иногда даже описание должности вводит в тупик. Видел на днях должность с названием "Principal Backend Engineer" описание обязанностей не содержит ни слова про программирование своими руками (на таком уровне это вцелом уже просто глупо) и вцелом 1-в-1 соответствует тому что я делал последние пару лет. Но внезапно выяснилось что эти ребята тоже расчитывают что кандидат будет писать им код в редакторе на интервью. Пришлось просто отказаться от собеседования чтобы не тратить время.
Вам кто-то на собесе говорил, что это плохо?
Ну и самое важное из того что тут мало обсуждается:
Собеседование это взаимный процесс, а не экзамен школьника перед преподавателем.
Если у меня будет на руках 2 оффера, на 1-м я провел условно пару часов в непринужденной атмосфере обсуждая какие нибудь интересные задачи из жизни.
На 2-м мне пришлось чувствовать себя идиотом решая идиотскую задачку в блокнотике под молчаливыми взглядами интервьювера который может решить эту задачку с завязанными глазами (потому что задает ее 5 лет подряд). Как вы думаете какой оффер я буду более склонен принять?
Вам кто-то на собесе говорил, что это плохо?
На собесе обычно не говорят такое, но не дают порефакторить (
Даже при таком поведении, это проблема не интервьверов, а того, кому нужен новый программист, а отправил он такого интервьювера. В некоторых компаниях, бывает, отправляют проводить разработчиков интервью чуть ли не под угрозой жирного минуса на очередном пересмотре зп/позиции.
А когда собес проводит лид/CTO или кто там ещё, потому что ему нужен человек, который решит его проблемы, то в инете он тупит только в одном случае: уже понял, что кандидат не решит его проблемы, но по какиим-то причинам сказать "спасибо, но вы нам не подходите" не может себе позволить через 5 минут после начала собеса. Кстати, предложить в такой момент решить задачку на листочке — может оказаться хорошим способом спровоцировать кандидата самому прервать собес )
Вы придумали тестовые задания :)
Простите, но FizzBuzz — это задачка такого уровня, что любой адекватный программист чуть опытнее джуна должен написать практически в бессознанке. Джуну надо будет слегка подумать.
Если переложить на вождение автомобиля, как тут уже предлагали — это как начать ехать на автомобиле (ну или велосипеде, для разнообразия). Вы же правда не будете брать в велокурьеры человека, который при попытке поехать на велике будет рассказывать, что он слегка подзабыл, как правильно крутить руль, и что вообще-то нормальные люди сначала смотрят ролик на ютубе, а не запоминают ненужную информацию?
Давайте про историю. Открываем википедию, читаем:
Fizz buzz (often spelled FizzBuzz in this context) has been used as an interview screening device for computer programmers.[3][4] Writing a program to output the first 100 FizzBuzz numbers is a trivial problem for any would-be computer programmer, so interviewers can easily filter out those with insufficient programming ability.[citation needed]
Открываем ссылку по сноске 3:
Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes.
Want to know something scary? – the majority of comp sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.
I’m not saying these people can’t write good code, but to do so they’ll take a lot longer to ship it. And in a business environment that’s exactly what you don’t want.
This sort of question won’t identify great programmers, but it will identify the weak ones. And that’s definitely a step in the right direction.
Это ровно то, что я написал в своём комментарии чуть выше. Это тест профнепригодность, чтобы отсеять неспособных (или не умеющих) программировать, не более. К сожалению, я имею опыт собеседований, когда кандидат действительно с большим трудом пишет решение задачи, сравнимой по сложности с fizzbuzz. А вы предлагаете подобного уровня задачи давать на дом заранее.
Если же более сложные давать — то это уже будет какое-то тестовое задание, и (имхо) чем выше уровень разработчика, тем меньше шансов, что он станет его делать. В принципе, чтобы пообсуждать код — можно уже и прямо на собеседовании дать, вместе сначала прочитать, потом обсудить. Либо прямо на собеседовании всё же не fizzbuzz, а что-то более нормальное писать, тогда можно и посмотреть, как кандидат код пишет, как к решению задачи подходит и т.д.
Мне, например, нравится давать кандидатам написать простейший LRU-кэш. Если кандидат не знает, как он должен работать (алгоритмически) — то я, конечно, рассказываю. Есть простор для обсуждения API (в случае С++, к примеру — как обрабатывать отсутствие элемента), эффективность реализации, когда такой кэш будет плохо работать и т.д.
Во-первых задача это и есть тот самый повод поговорить. Если кандидат молча нахерачил решение за три минуты — это не значит что он клёвый, это значит что эту задачу он знает, или просто сразу повезло сообразить как решается, и нужно дать другую задачу. В среднем случае к концу секции вы должны доехать до какого-то промежуточного решения — ещё не самого оптимального, но уже не «в лоб». И более того, даже если кандидат не решил задачу полностью, но написал нормальный код для имевшихся идей и круто рассуждал — это отличный сигнал и вообще hire.
Во-вторых я бы не требовал даже компилируемого кода. Порядок аргументов в библиотечной функции, как именно называется контейнер, точное название модуля где это счастье лежит — да какая разница! Смотреть стоит на то, как человек организует код, знает ли основные фичи языка, на котором вызвался писать, как он это тестировать собирается. Все детали реализации, которые «счас не помню, но за пять минут можно нагуглить» вообще можно игнорировать.
И в последних, если вы собеседующий — ну объясните вы самому кандидату что вам не столько интересно решение, сколько ход его мыслей и то, как он пишет код. Он и сам может догадаться, что решение вам не очень интересно, вы и так уже знаете пачку решений для своей-то задачи, а человеку меньше нервничать.
Все так, только автор не описал ситуацию, где программист на собеседовании не справляется с задачей. Очевидно, что ответ он не зазубрил, а ещё видно, что написать свое решение он тоже не может. А это уже важная информация о кандидате.
В иной ситуации, если задачу он решит, то в худшем случае, с точки зрения аналитики способностей кандидата, мы не узнаем о нем ничего нового.
a а давать другие задачи (более реальные и подxодящие к Вашей компании) не пробовали?
и списывать не получится, я наблюдаю в реальном времени как и что он делает
Описание вакансии может показаться работой мечты. Подумаешь: второго шанса не будет и согласишься на тестовое,
Много раз собеседовал с программированием (удалённо). Техническое собеседование длится 60-90 минут. Вначале идут вводные вопросы «расскажите о себе и том, как пришли в программирование» (свободное сочинение на несколько минут). Потом серия вопросов по основному языку, на который нанимается кандидат.
После этого идёт кодирование в каком-нибудь код-шаре, с подсветкой синтаксиса. Буквально 5-10 минут, зависит от того, насколько успешно и комфортно кандидату такое упражнение. Дедлайн для себя устанавливаю в 15 минут. Если за 15 минут задача не решена до конца — прошу кандидата своими словами рассказать чего ещё не хватает.
Потом на несколько минут устраивается обсуждение результатов, прошу человека рассказать о сильных и слабых сторонах получившегося куска кода.
Всё делается в ненапряжной манере, без острой критики — в стиле парного программирования.
Зачем?
Я задаю задачи не в расчёте на проверку знания паттернов / особенностей языка / фреймворка / платформы. Более того — сразу говорю — если не помните точного наименования и / или сигнатуры нужных методов — придумайте свои, только расскажите что они должны делать.
Если конкретно по задачам — больше всего нравится предложение написать метод, подсчитывающий размер всех файлов в папке. При этом уточняю, что метод должен быть написан в расчёте на периодический возврат текущего прогресса, дабы избежать однострочных решений типа «вытащить средствами фреймворка полный рекурсивный список файлов и просуммировать их размер».
Сам механизм возврата прогресса писать не прошу, но при желании — не останавливаю. Просто указываю, что теоретическая возможность должна быть предусмотрена.
Такая задача — просто кладезь нюансов и позволяет достаточно глубоко оценить опыт и способность кодить. Рекурсивные / нерекурсивные вызовы, способы обхода дерева файлов, способы возврата результатов и многое другое.
Повидал многое. 90% кандидатов догадываются о необходимости поиска файлов в подпапках. 70-80% более-менее знают как правильно написать рекурсию. Очень редко попадаются кандидаты, пишущие нерекурсивные алгоритмы с очередями. Правильно вернуть результат сходу могут буквально единицы.
Если написан рекурсивный вариант — спрашиваю какие подводные камни у этого подхода. Вопрос не академический — на практике приходилось ловить в релизном варианте StackOverflow когда Windows формирует файловую систему с софтлинками и вложенная папка ссылается на родительскую. Спрашиваю как можно было бы этого избежать.
Параллельно могу задавать дополнительные вопросы на затронутые методы.
Это очень гибкий способ, позволяющий оценить кандидата практически любого уровня — от совсем зелёного до подкованного профи. Для каждого уровня найдутся вопросы.
Но никогда не превращаю собеседование в сплошную писанину, особенно если на бумажке. Писать код на бумажке — это издевательство над человеком, такого я избегаю. Хотя в детстве (начало и середина 90-х) сам писал код в тетрадке (дома компа не было), а потом шёл в компьютерный класс и там перепечатывал.
После практической задачи начинается следующая фаза, несколько серий вопросов на более узкие знания по фреймворкам, базе данных и т.д.
После этого небольшая серия вопросов по скраму.
В конце остаётся 5-10 минут на вопросы кандидата ко мне. Это один из самых важных этапов, так как в этот момент человек раскрывается и часто высказывает наиболее волнующие его опасения, выкладывает реальные причины прихода на собеседование (например — он просто тренируется и не занимается активным поиском нового места), и т.п.
Когда-то давно, практически в другой вселенной, ещё в прошлом веке, участвовал в найме разработчика на php. Ну с навыками администрирования, не без этого. Самой большой находкой считаю до сих пор то, что начали давать кандидатам консоль к боевому серверу с просьбой рассказать что там зачем и почему и как бы он это улучшил.
Да, кандидаты реально ходили и по коду, и по настройкам сервера. Вменяемых было на удивление мало, несмотря на заявленный опыт работы, квалификация определялась на раз. Как бы было понятно что если кандидат всерьёз обсуждает конфиги апача и mysql, да ещё и по коду может сделать разумные замечания — то он "наш человек".
К сожалению, с тех пор всё очень сильно изменилось и/или усложнилось, да и к консоли допускать стало сложней — слишком много нужно знать про внутреннее устройство в организации, чего кандидат, понятно, в принципе знать не может
З.Ы. реальный вопрос на собеседовании в одном отдельно взятом областном центре в конце 90-ых.
-А ты вот такого Ивана Петрова знаешь? (известный в том областном центре программист)
- Да. знаю
- А вот как ты себя позиционируешь в сравнени с ним? Ты круче программист чем он?
Одно дело когда вы в реальном проекте пользуетесь IDE и ищите решение на SoF, это помогает ускорить процесс и проверить себя. Другое когда без этих инструментов ничего не можете написать. Наверное в идеальном собеседовании должны быть затронуты разные аспекты и дать задачу на кодирование что бы посмотреть как человек над ней работает это вполне разумно. Вопрос какая конкретно задача и что вы этой задачей проверяете.
Проблема в описанная статье объясняется очень просто или же руководство не доверяет в полной мере тем кто собеседует и по этому пытается стандартизировать собеседование или собеседующему наплевать и он просто не хочет напрягаться — а что может быть проще выбрать задачу в сети прочитать её решение и расслабиться пока кандидат напрягается.)
Поэтому в своей процесс собеседования его может и необязательно внедрять, но и жаловаться на чужие со стороны кандидата не вижу смысла.
Опять много красивых слов, но нет конкретики, как отобрать 5-10 человек из 500 по-другому?
"Почему вы никогда не должны соглашаться на собеседования с программированием" = "Почему вы никогда не должны соглашаться работать в гугле или фейсбуке". И я таки не понял, почему я не должен.
напоминает старую шутку:
Задача по физике: как с помощью настольной лампы и очков узнать показатель преломления стекла?
Ответ: включить лампу, надеть очки и посмотреть в справочнике.Физику, математику и инженеру дали задание — найти объём красного резинового мячика.
Физик погрузил мяч в стакан с водой и вычислил объём вытесненной жидкости.
Математик измерил диаметр мяча и рассчитал тройной интеграл.
Инженер достал из стола свою «Таблицу объёмов красных резиновых мячей» и нашёл нужное значение.Как построить дерево для примера 10+5-4*2+3 ?
или Кто-то встречал SSE asc2Hex to integer ?
P.S. В принципе нормальная рабочая ситуация но почему интервьюируемые её могут не знать, а собеседующие про неё даже, вероятно, не спрашивали?
Свою последнюю позицию инженера-разработчика я получил, блестяще сделав тестовое задание. Оно было несложным, а я люблю писать код, поэтому вложил в него весь свой опыт: сделал в виде модуля, отформатировал и откомментировал код, покрыл тестами, написал документацию. Получил оффер через два часа, и первое, что услышал от новых коллег: "чувак, классное тестовое задание", то есть ещё и заработал небольшой стартовый авторитет.
Ещё два оффера на руководящие позиции я также получил после тестовых архитектурных заданий. Код писать было не надо, а надо было придумать архитектуру для гипотетических, но понятных сервисов, интерактивно, на бумаге или доске. Оба раза интервьюеры сказали, что именно эта секция выделила меня среди других кандидатов.
К сожалению, хорошее CV и толковый разговор о технологиях говорят только о навыках составления CV и умении разговаривать.
Ребята, весь этот кодинг в режиме реального времени - херня. Я собеседовал и нанимал многих чуваков, которые хорошо писали и говорили. А по факту оказывались не самостоятельными. Они не могли распутать клубок требований. Найти и дожать нужных людей, ответственных за ту или иную часть системы. Вытянуть из них инфу и наконец таки решить проблему.
Эта херня с кодингом может быть полезна только для джунов или мидлов. Но ни как для тру сениоров или дев лидов.
Из моего опыта как собеседующего могу сказать что все ровно наоборот. Ни все об инженере можно понять по резюме и про то как он говорит про свой опыт и отвечает на вопросы. Часто это впечатление обманчиво.
В большинстве случаев когда человек очень хорошо отвечает на вопросы и резюме хорошее, он был очень плох в написании кода и в понимании того что написано. Поэтому я трачу 70% времени на написание кода.
Что тут можно обсуждать так это что просить написать.
Я пришел к небольшим заданиям когда нужно спроектировать и написать небольшой класс связанный с инфраструктурой или логикой. Попутно можно получить очень много информации как человек уточняет требования, пишет код. Спрашиваю ещё что нужно будет сделать до выкатки этого на прод, как тестировать, если проблемы с производительностью, как с потокобезопасностью и так далее. В процессе очень хорошо можно узнать кандидата.
Почему вы никогда не должны соглашаться на собеседования с программированием