Комментарии 55
НЛО прилетело и опубликовало эту надпись здесь
С точки зрения Макконнелла, очевидно
Речь не про то, чтобы дать или не дать ответ кандидату, а про то, как для себя лично формулировать цель собеседования. Если формулировать жестко: «я должен принять решение», то это и себе стресс, и в случае, если кандидат «на границе», от субъективности больше зависит. Оценка же в «цифрах» всегда мягче, и упрощает процесс.
Для кандидата все остаётся по прежнему. В крупных компаниях на собеседованиях могут (редко) разобрать ошибки, но почти никогда не говорят итогового «принят» или «не принят».
Про SQL обсудить тоже много чего можно, но я ищу разработчика backend’а, а не DBA. Хотя о том, зачем вообще нужен SQL и современные СУБД и как они упрощают жизнь (и сравнение с NoSQL) я бы поговорил. Акцентируя внимание в том числе на ACID и оптимизаторах запросов. Главное помнить про время :-)
«Идеальный» надо взять в кавычки, правильное тут слово скорее «работающий».
Для кандидата все остаётся по прежнему. В крупных компаниях на собеседованиях могут (редко) разобрать ошибки, но почти никогда не говорят итогового «принят» или «не принят».
Про SQL обсудить тоже много чего можно, но я ищу разработчика backend’а, а не DBA. Хотя о том, зачем вообще нужен SQL и современные СУБД и как они упрощают жизнь (и сравнение с NoSQL) я бы поговорил. Акцентируя внимание в том числе на ACID и оптимизаторах запросов. Главное помнить про время :-)
«Идеальный» надо взять в кавычки, правильное тут слово скорее «работающий».
Да, я тоже, на прошлом месте работы так делал. У меня было несколько стандартных вопросов, которые давали и грубую оценку и повод поговорить.
Я, вообще, собеседуя, предпочитал говорить о том, что человек сам заявил как «знаю».
Я, вообще, собеседуя, предпочитал говорить о том, что человек сам заявил как «знаю».
Собеседую Java программистом одним вопросом — прошу рассказать о режимах сборщика мусора.
Я всегда знал что с джавистами что-то не так
Режим сборщика мусора на случай если таски по джаве закончатся?)
За двенадцать лет коммерческой разработки это знание пригодилось примерно никогда.
НЛО прилетело и опубликовало эту надпись здесь
Может вы имели в виду, как работает сборщик, про всякие эдены и поколения? Точное устройство слишком точное, чтобы ради общего собеседования лезть в сорцы Hotspot, и не очень нужное, если используется коммерческая VM, в которой вообще что угодно может быть, отличное от поколений.
А оно и не может пригодится.Ну раз оно скорее всего не пригодится, то зачем тратить на это время?) Тем более, если не использовать, то рано или поздно забудется.
Вот заняться людям нечем, кроме как учить то, что им не пригодится. Не разумней ли учить то, что реально может быть полезным в работе? Такого итак нескончаемый поток.
Ну столкнется человек раз в году с задачей, по которой нужно глубоко разбираться в теоретической части чего-то. Потратит часов 50 рабочего времени и разберется. Компания разорится на целых 50 часов его обучения. В тоже же время за год он столкнется с 50 задачами, которые он знает как делать и ему, в отличие от других в команде, для их выполнения не придется тратить часов 200 на дополнительное изучение технологий. Компания в итоге окажется в плюсе.
Как будто разработчики сразу должны знать, как любую задачу решить.
Нет, конечно. Все много чего не знают, много чего не помнят и гуглят каждый день.
Если поставить двух сеньоров из разных компаний прособеседовать друг друга, с очень большим процентом вероятности каждый из них посчитает другого джуном, что обычно и происходит. У каждого свои знаний, свой опыт/задачи. Каждый считает, что каждый разработчик должен знать именно «это».
За двенадцать лет коммерческой разработки это знание пригодилось примерно никогда.Вполне хороший ответ, если он не на все вопросы такой)
Имхо, если собеседующий считает такой ответ минусом, то компания доверила собеседовать не тому человеку и несет из-за этого небольшие дополнительные убытки.
Конечно, есть области, где нужно глубоко знать какую-либо технологию. Там подобные вопросы уместны. Но, часто подобное любят спрашивать даже там, где это никогда не использовалось и не будет.
Ну да, а потом мне продают продукт (с поддержкой), который раз в пять минут на минутку фризится, когда ему памяти вместо 16 Гб дали 128. На 16 он ругался на нехватку, а в 128 вдруг фризится.
Как вы думаете — почему? Как ответить на этот вопрос, если не знать про типы и настройки gc?
НЛО прилетело и опубликовало эту надпись здесь
Шипилёв, перелогинься! :p
5 баллов
Последний пункт интригует. Как выглядел этот кандидат, который нашел только 13 ошибок?
Подскажите пожалуйста, а что такое "обычный JOIN"?
Неплохой набор вопросов, а точнее способ из задавать. Главное только этими вопросами не ограничиваться, потому что сама по себе тема неисчерпаемая.
И еще, не заметил чтобы аврор акцентировал на этом внимание — этот способ не формализуем. То есть, мы не можем заранее сформулировать список вопросов предлагаемого автором типа, а потом попросить их задать кого угодно, и проверить ответы. Не получится, так как нет заранее известных точных ответов. Ну и как минимум, чтобы так интервьюировать синьоров, нужно самому быть синьором.
И еще, не заметил чтобы аврор акцентировал на этом внимание — этот способ не формализуем. То есть, мы не можем заранее сформулировать список вопросов предлагаемого автором типа, а потом попросить их задать кого угодно, и проверить ответы. Не получится, так как нет заранее известных точных ответов. Ну и как минимум, чтобы так интервьюировать синьоров, нужно самому быть синьором.
А мне способ задавания вопросов не понравился.
Это если они так и делают как в статье: «Расскажите про хэшмэп!» и дальше молчат и ждут ответа на все свои пункты и бонусы.
Надеюсь я просто неправильно понял как автор предлагает вести такое собеседование.
Это если они так и делают как в статье: «Расскажите про хэшмэп!» и дальше молчат и ждут ответа на все свои пункты и бонусы.
Надеюсь я просто неправильно понял как автор предлагает вести такое собеседование.
Разумеется, если человек для начала ограничивается кратким ответом, то к полному ответу его нужно подводить наводящими вопросами. «А зачем нам HashMap?», «А как понять, хорошая hashCode() или плохая?», «будет ли работать HashMap в многопоточной среде?» и т.п.
нужно подводить наводящими вопросами
"Кто и в каком году её придумал?"
НЛО прилетело и опубликовало эту надпись здесь
Вы, наверное, хотели сказать «99,9% случаев»?
Мне интересен не код хорошей функции, а требования к ней. Не то, как должна быть написана функция, с какими константами и операциями, а почему, исходя из каких требований, она должна быть так написана?
Какие функциональные (контракт) и нефункциональные требования есть к функции hashCode()?
Какие функциональные (контракт) и нефункциональные требования есть к функции hashCode()?
Я подозреваю, что неправильно поняли. Суть метода, как я его понимаю, состоит в том, что вопрос — это только тема для беседы. И то, насколько глубоко собеседуемый может его раскрыть — как раз очень хорошо показывает его уровень. Ну то есть да, наводящие вопросы, как автор ниже уточняет, потому что что за беседа, когда оба молчат?
Этот способ, например, не пропускает людей, которых можно условно назвать «зубрилами». То есть способных выучить те или иные учебники, но не способных при этом полученные знания либо применить, либо глубоко осознать. Потому что в учебнике про хешмапы обычно не пишут, что такое хорошая хеш функция, этим немного в других книгах занимаются. И если человек такой уровень ответа смог раскрыть — значит он не просто учебник зубрил.
Это не идеальный метод, у него свои ограничения есть. Но это именно ограничения, не недостатки.
Этот способ, например, не пропускает людей, которых можно условно назвать «зубрилами». То есть способных выучить те или иные учебники, но не способных при этом полученные знания либо применить, либо глубоко осознать. Потому что в учебнике про хешмапы обычно не пишут, что такое хорошая хеш функция, этим немного в других книгах занимаются. И если человек такой уровень ответа смог раскрыть — значит он не просто учебник зубрил.
Это не идеальный метод, у него свои ограничения есть. Но это именно ограничения, не недостатки.
Правильный ответ будет, разумеется, содержать не просто JOIN, но LEFT JOIN со сравнением значения на NULL.
А в данном случае нельзя использовать EXCEPT?
(select id from groups) except (select group_id from students)?В качестве первого подхода можно, но потом попрошу переделать на JOIN.
попрошу переделать на JOIN
Вы имеете в виду с целью выяснить умение пользоваться JOIN, или в данном случае у него есть преимущества над EXCEPT?
Был у меня как-то такой вопрос на собеседовании. И интервьюер как раз хотел услышать именно такой ответ, как вы и дали.
Пришлось ему объяснять, что
как правило (но не всегда!), проигрывает в производительности
Добавлю к этому очень немаловажный факт, что в разных СУБД и версиях этих СУБД (!), с разным количеством данных в таблицах и разными индексами на таблицах, могут быть разные планы и производительность этих двух запросов.
Вообще, тема anti-semi join довольно холиварная. Но я бы такой запрос, который вы привели как правильный, вежливо попросил бы переделать (откуда и для чего ограничение на подзапросы, если, конечно, речь не о какой-нибудь старенькой Firebird) — он предпочтительнее, чаще производительнее, так как нет тяжелого «left join» и, в конце-то концов, зачем вам тащить «студентов» наверх, если вы их используете только как условие для отбора данных?
Пришлось ему объяснять, что
select count(g.id)
from group g
left join students s on s.group_id = g.id
where s.id is null
как правило (но не всегда!), проигрывает в производительности
select count(g.id)
from group g
where not exists (select null
from students s
where s.group_id = g.id)
Добавлю к этому очень немаловажный факт, что в разных СУБД и версиях этих СУБД (!), с разным количеством данных в таблицах и разными индексами на таблицах, могут быть разные планы и производительность этих двух запросов.
Вообще, тема anti-semi join довольно холиварная. Но я бы такой запрос, который вы привели как правильный, вежливо попросил бы переделать (откуда и для чего ограничение на подзапросы, если, конечно, речь не о какой-нибудь старенькой Firebird) — он предпочтительнее, чаще производительнее, так как нет тяжелого «left join» и, в конце-то концов, зачем вам тащить «студентов» наверх, если вы их используете только как условие для отбора данных?
От себя замечу, что если описана ситуация когда разработчику приходит на PR синтаксически неверный код, я бы очень задумался о процессах в этой компании, о ее зрелости и вообще стоит ли дальше общаться.
Как по-вашему, ребята какого уровня должны решать вопросы со зрелостью процессов в компании и почему бы именно вам этим не заняться? Был-ли у вас подобный опыт в прошлом? Какие цели вы поставите и какие действия будут вами предприняты, чтобы улучшить ситуацию?
Да и требовать глазами найти синтаксические ошибки это из разряда попросить написать рабочий код на доске.
Нигде же не говорится, что эта ситуация реальная. Это модель некоторого рабочего процесса с целью выяснить знания человека. Данная модель нужна для решения задачи проведения собеседования.
Ну а как устроены CI-процессы можно рассказать отдельно.
Ну а как устроены CI-процессы можно рассказать отдельно.
Это мне напоминает, когда C на собеседовании дают выражение, поведение которого не определено даже стандартом. При этом удивляются, когда кандидат увидев это, говорит, вы что это в боевом коде используете? А если нет, зачем спрашиваете? А вам для проверки кругозора, аааа, понятно…
Я не спорю, но по вашим примерам судят о бардаке в компании в общем, и в вашей группе в частности.
Можно, но если у вас все норм, то тогда будет еще больший диссонанс. Зачем меня это спрашивали.
Я не спорю, но по вашим примерам судят о бардаке в компании в общем, и в вашей группе в частности.
Можно, но если у вас все норм, то тогда будет еще больший диссонанс. Зачем меня это спрашивали.
Один совет, который хочется дать всем тем, кому придётся собеседовать будущих коллег.
Оценивайте не знание фамилии изобретателя хэшмепы, а общую адекватность, практические знания и насколько хорошо человек соображает — например нащупать тему, с которой он не работал и попросить поразмышлять на тему "как бы вы сделали вот такое и почему именно так?"
Как сказал великий: «Говорить о программировании — все равно что танцевать об архитектуре». Терпеть ненавижу собеседования вида «а поговорить?». Выявляет только у кого язык гибче и длиннее. Пишите код.
как раз код писать это для code monkey.
Надо проверять сообразительность — например кинуть задачку на сложный случай в распредсистеме с требованием обеспечить консистенси, или какую другую на думание.
И софт скиллс — будет ли этот человек дружить, делиться, создавать позитив, или все у него будут уроды на почве того, что он больше деталей помнит из treemap. Cнобов, манипуляторов, циников — с любыми достижениями — за дверь. Потому что если из за одного человека уйдет два или больше, то он в жизни их не заменит, каким бы гуру он не был.
А на случай непроизводительности — есть тестовый период, за этот срок можно все выяснить спокойно и не путем попытки натянуть сову на глобус и найти идеального кандидиата через 3 или 33 вопроса.
Надо проверять сообразительность — например кинуть задачку на сложный случай в распредсистеме с требованием обеспечить консистенси, или какую другую на думание.
И софт скиллс — будет ли этот человек дружить, делиться, создавать позитив, или все у него будут уроды на почве того, что он больше деталей помнит из treemap. Cнобов, манипуляторов, циников — с любыми достижениями — за дверь. Потому что если из за одного человека уйдет два или больше, то он в жизни их не заменит, каким бы гуру он не был.
А на случай непроизводительности — есть тестовый период, за этот срок можно все выяснить спокойно и не путем попытки натянуть сову на глобус и найти идеального кандидиата через 3 или 33 вопроса.
как HashMap используется в базах данных
И как же?
Мысль посетила, что одним из первых вопросов должен быть: «В чем вы сильны, на вопросы по каким темам вы сейчас готовы ответить на вопросы?» И уже исходя из этого строить дальнейший диалог.
Эх, собеседования. Хочу напомнить одну простейшую вещь. Работает везде, делюсь. Куда вы вкладываете ресурсы, время и деньги, то вы и получите.
Итак, куда же вкладывает ресурсы автор текста?
1. Исторический экскурс в хэшмап. Вы этим деньги планируете зарабатывать, историей кто-когда предложил? Или это собеседование на предмет соответствия хобби интервьюера?
2. Стиль советского экзамена «наизусть». Я вот не смогу сразу сказать, почему индексы не на хешах, будет нужно — посмотрю. Пары дней хватит, чтобы раскурить любые мануалы по любым деревьям. Вы этим деньги планируете зарабатывать, написанием индексов? Нет? Тогда зачем? Куда полезнее будет предложить творческую задачку, базирующуюся на хешмапе, и посмотреть, как человек соберет ее с точки зрения производительности, thread safety и пр.
3. Опять же, SQL задачка — вы прям вот пишете сразу на Oracle и MSSQL, с постгресом и MariaDB на стороне? Что за монстра вы создали? Вы этим планируете зарабатывать деньги?
В общем, автор имплицитно подкладывает нам собеседование не на любого разработчика, а на разработчика, приятного конкретному автору с его персональным багажом.
Вообще судля по профилю автора текста — он занимается какими-то алгоритмами. Да, там все это может быть полезно, но это нишевые навыки. Листовки на полстраницы будет достаточно любому джуну, чтобы знать про хешмап, дальше он будет смело использовать стандартную библиотеку и в 99% случаев этим вы и будете зарабатывать деньги. Прекрасная книга Гоетца решит проблемы с конкарренси, а кратенький Виньяндс — с LEFT JOIN.
Что автор тестирует: насколько человек про себя умеет подчеркнуть ошибки лучше IntelliJ. Вы этим зарабатываете деньги?
Что автор не тестирует:
— умение сочинить сложную модульную систему, которая будет готова к unknown unknowns от бизнеса с дедлайном неделю (воображаю человека, который работает по 17 часов в сутки, получает истерики от бизнеса за неготовость и самоутешается знанием о том, кто когда изобрел хешмап)
— умение писать быстро работающий код. А не такой, который быстро только на юниттесте, а в проде с нагрузкой в миллион раз больше сваливается по таймауту, и тому через полчаса, оставив базу в inconsistent state, чтобы, значит, было чем заняться в консоли бд ручками.
— умение разработчика быстро подтянуть нужную инфу, если он ее не знает.
Нужно помнить, что собеседование — оно вообще-то в обе стороны. Мне лично было бы интересно узнать, рассказывает ли интервьюер ответы после того, как закончил спрашивать. Судя по тому, что он намекнул на 13 ошибок тут, но скрыл детали, на базе текста напрашивается вывод, что не склонен он прошаривать коллег. Каждый сам за себя, времена такие, приходите к нам, в нашу сплоченную организацию, толстая кожа как у мамонта — бонусные очки.
Любой выпускник вуза, который не знает всех этих тонкостей сразу, сможет спокойно разобраться с ними за пару дней, но данного собеседования не пройдет. Оно не соответствует тем вещам, которые нужны в большинстве мест, и проходит по советской системе «помнишь-молодец». Помнить что-то надежно можно, если занимался этим и только этим. Это такой больше академический подход. Есть способы быстро научить людей любым нужным навыкам, так как по сути все программирование — это довольно просто, по сравнению с какой-нибудь космологией или медициной, и выхваляться тут нечем, если конечно вы не пишете на ассемблере работающий код прямо на доске или на худой конец не торгуете с миллисекундными раундтрипами. Все остальные вещи осваиваются за сравнительно краткий промежуток времени. Лично мне ближе принцип — не важно, что ты не знаешь сейчас, важно, сможешь ли ты научиться с нормальной скоростью.
Итак, куда же вкладывает ресурсы автор текста?
1. Исторический экскурс в хэшмап. Вы этим деньги планируете зарабатывать, историей кто-когда предложил? Или это собеседование на предмет соответствия хобби интервьюера?
2. Стиль советского экзамена «наизусть». Я вот не смогу сразу сказать, почему индексы не на хешах, будет нужно — посмотрю. Пары дней хватит, чтобы раскурить любые мануалы по любым деревьям. Вы этим деньги планируете зарабатывать, написанием индексов? Нет? Тогда зачем? Куда полезнее будет предложить творческую задачку, базирующуюся на хешмапе, и посмотреть, как человек соберет ее с точки зрения производительности, thread safety и пр.
3. Опять же, SQL задачка — вы прям вот пишете сразу на Oracle и MSSQL, с постгресом и MariaDB на стороне? Что за монстра вы создали? Вы этим планируете зарабатывать деньги?
В общем, автор имплицитно подкладывает нам собеседование не на любого разработчика, а на разработчика, приятного конкретному автору с его персональным багажом.
Вообще судля по профилю автора текста — он занимается какими-то алгоритмами. Да, там все это может быть полезно, но это нишевые навыки. Листовки на полстраницы будет достаточно любому джуну, чтобы знать про хешмап, дальше он будет смело использовать стандартную библиотеку и в 99% случаев этим вы и будете зарабатывать деньги. Прекрасная книга Гоетца решит проблемы с конкарренси, а кратенький Виньяндс — с LEFT JOIN.
Что автор тестирует: насколько человек про себя умеет подчеркнуть ошибки лучше IntelliJ. Вы этим зарабатываете деньги?
Что автор не тестирует:
— умение сочинить сложную модульную систему, которая будет готова к unknown unknowns от бизнеса с дедлайном неделю (воображаю человека, который работает по 17 часов в сутки, получает истерики от бизнеса за неготовость и самоутешается знанием о том, кто когда изобрел хешмап)
— умение писать быстро работающий код. А не такой, который быстро только на юниттесте, а в проде с нагрузкой в миллион раз больше сваливается по таймауту, и тому через полчаса, оставив базу в inconsistent state, чтобы, значит, было чем заняться в консоли бд ручками.
— умение разработчика быстро подтянуть нужную инфу, если он ее не знает.
Нужно помнить, что собеседование — оно вообще-то в обе стороны. Мне лично было бы интересно узнать, рассказывает ли интервьюер ответы после того, как закончил спрашивать. Судя по тому, что он намекнул на 13 ошибок тут, но скрыл детали, на базе текста напрашивается вывод, что не склонен он прошаривать коллег. Каждый сам за себя, времена такие, приходите к нам, в нашу сплоченную организацию, толстая кожа как у мамонта — бонусные очки.
Любой выпускник вуза, который не знает всех этих тонкостей сразу, сможет спокойно разобраться с ними за пару дней, но данного собеседования не пройдет. Оно не соответствует тем вещам, которые нужны в большинстве мест, и проходит по советской системе «помнишь-молодец». Помнить что-то надежно можно, если занимался этим и только этим. Это такой больше академический подход. Есть способы быстро научить людей любым нужным навыкам, так как по сути все программирование — это довольно просто, по сравнению с какой-нибудь космологией или медициной, и выхваляться тут нечем, если конечно вы не пишете на ассемблере работающий код прямо на доске или на худой конец не торгуете с миллисекундными раундтрипами. Все остальные вещи осваиваются за сравнительно краткий промежуток времени. Лично мне ближе принцип — не важно, что ты не знаешь сейчас, важно, сможешь ли ты научиться с нормальной скоростью.
Согласен с вами. У меня план собеседования такой. Задаю вопрос, отвечая на который можно много чего рассказать, а дальше задаю вопросы по тем темам, которые собеседник сам обозначил. Чем выше уровень специалиста, тем быстрее и дальше продвинется диалог. Когда время подходит к концу, я прикидываю объем того, что человек успел мне рассказать. Чем дальше прошел, тем лучше.
Я после большого числа проведенных собеседований убедился, что лучше всего специалист проявляет себя тогда, когда слышит вопрос, к которому он не готовился. Поэтому свои 3 вопроса я нигде публикую.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Собеседую программистов на Java. Единый набор вопросов для любого уровня