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