Comments 70
Мне интересно, какие вопросы он задаст.
Главный и единственный вопрос: нафига мне этот церебральный коитус? Я лучше пойду к тем, кто не будет мне мозг выдуманными под веществами задачами сношать.
А почему нет? Это частая ситуация когда человек не понял аналитику и бросился делать и хорошо если он возникающие вопросы потом задаст в ходе реализации, а не спустя неделю выкатит свой вариант "как он понял".
Честно говоря такое собеседование кажется целесообразным, не перекачивают задачками алгоритмическими, практические задачи, какие то поведенческие вещи тоже проверяются.
Церебральный коитус? Почему?
Потому что для уважающего себя человека решение подобных задач оправдано только если он в Гугл на позицию ведущего разработчика собеседуется.
Почему я должен каждому барану доказать что я не мошенник? У меня есть профильный диплом и стаж работы. Что вам ещё надо? Почему токарь на заводе просто показывает диплом, почему бухгалтер просто показывает диплом и опыт работы, почему буквально везде достаточно диплома для доказательства своей компетенции?
В ИТ уже снова пришли "нужна какая-то система сертификации что человек не дебил" так вам дурачкам давно дали такую сертификацию. Называется диплом об образование высшем или среднее-техническое.
Я недавно перед школьниками выступал и думал на тему диплома и ИТ. И вот что накумекал:
Я универ заканчивал, когда язык Go публичным стал.
React выпустился первый раз, когда я уже работу работал.
Так что если вы ко мне придете и скажете что у вас диплом и стаж большой, а у нас стек современный и вы сказали, что его трогали, то вот простая задача. Предельно простая, но не проще.
Условному куберу 10 лет нет. В легаси проектах используется не он. Так что позвольте вас опросить, чтобы потом никто не пожалел.
Но и альтернативу рассматривать, полагаю стоит. Типа если чувак имеет релевантный гитхаб (редко) или диплом специфический под задачу...
То есть я продолжаю гнуть свою линию, что надо плясать от вакансии и желаемого кандидата.
А причём тут технологии? Меня в институте учили как работает компьютер, архитектура ЭВМ, матанализ, ТФКП, вычислитеная математика, дискретная, теорвер, теория множеств, теория кодирования, сетевые технологии, схемотехника, алгоритмика(не алгоритмы), алгоритмы и структуры данных(это вообще первый семестр).
Я вообще не изучал в вузе никаких языков и технологий. Зато учил такие вещи что мне теперь все ваши докеры, куберы, Го, Расты и 100 ЖС фреймворков это буквально "мы изобрели велосипед". Мне достаточно просто устного описания любой "новой технологии" чтобы сказать вам в учебнике за 60го или 70го года она описана.
У вас представление о вышке как-будто там курсы для войти, но там вообще не учат ни языки, ни фреймворки. Там учат людей которые могут написать язык или фреймворк, а также освоить любой из них за неделю до уровня джун+ и за месяц полностью.
Если вы не имеете практического опыта с курьером, то решить задачу на требуемом уровне у вас не получится, не хватит практического опыта. Соответственно, нет смысла вас нанимать на определенные задачи и надеяться на то, что вы сможете настроить кластер с необходимыми характеристиками. Учить, вероятно, вас может быть некому, а тренироваться на крупном проекте вам никто не позволит.
Из этого и складывается ограничение.
Мы про джунов и интернов говорим или че? Если человек с 5+ годами стажа не может за 2 дня разобраться в такой просто вещи как докер или кубер, то он имбицил.
Я не понимаю какие такие волшебные навыки я должен иметь? Знать и уметь все на свете нереально. Для проверки практических навыков достаточно простого вопроса "вы работали с [CENSORED]?" Эти вопросы может задать и [CENSORED] по телефону
Снимите пальто, пожалуйста. Вы заходите в сообщество, называете людей, цитирую, "баранами", а про себя говорите так, будто знаете все технологии в мире
Если так, вам ничего не мешает пройти техническое собеседование в любую компанию, кроме гордыни
Но почему-то мне кажется, что на собеседовании выяснится что "этивашигорасты" - не единственное, что ожидают от кандидата и без умения в вежливое общение и уважение к другим участникам беседы, даже самые исключительные инженерные навыки блекнут
Почему токарь на заводе просто показывает диплом,
Потому что не просто показывает
В Омске на агрегатном заводе, который делает много чего серьезного и промышленного, после базового изучения анкетки (весьма дурацкой, кстати) и чтения дипломов, кандидата подводят к станку и просят выточить деталь по не очень сложному чертежу. Станок обычно хороший, но ручной, без ЧПУ и автоматики
Если токарь не справляется с условной втулочкой или не может нормально прочитать чертеж, с ним вежливо прощаются, несмотря на его разряды, заслуги и дипломы
Пожалуйста, напишите, как вы предлагаете проводящим собеседования отсеивать кандидатов с красивым резюме, приписанным или фейковым опытом работы, но не имеющих реальных, практических знаний, умений и требуемого опыта.
Поговорить с ними? Если вы сам специалист высокого уровня, то вам достаточно просто беседы чтобы понять что человек вам врёт. Коли вы так не можете значит вам рано проводить собеседования по причине недостаточной компетенции.
Думаете если задачи на код заменить субъективной оценкой интервьювера «мне показалось» то жизнь кандидатов станет легче? Даже если предположить, что это так, останется вопрос - что делать с людьми, у которых по каким-то причинам никакого интересного опыта нет. В текущей парадигме у них хотя бы есть возможность блеснуть в кодировании.
это зависит от проверяемых умений. задача на удаление троек показательна в плане реализации алгоритмов и написания простой бизнес логики, позволяет сразу опознать определенный контингент.
про другие навыки и умелки будем рассуждать в следующих выпусках.
"Все" посты одна сплошная ошибка выжившего, все пишут о тех кого наняли, я вот хотел бы почитать о тех кого не наняли.
Кучу людей, которые не способны продемонстировать логику, навыки указанные в резюме и хоть какую-то проактивность.
Как написано в статье, "Дьявол в деталях."
Не так важно какой вопрос и ответ были заданы. Важны детали - как человек отвечал, как он подходил к ответу. Чтобы понять процесс мышления и оценить насколько он адекватен.
Насколько проста коммуникация с человеком - если ты ему задаешь один вопрос, а он отвечает на совсем другой, и даже после уточнения говорит в другую сторону - такой человек не подходит. Он будет постоянно лажать с задачами (предполагаем, что интервьювером отправляют адекватного человека ;)
Либо человек гик с синдромом самозванца, интроверт и просто не может сосредоточиться на собеседовании. Про этот вариант большинство просто забывает. А потом оказывается что в компании все активные и общительные, но по нетривиальным задачам работает 1-2 человека, случайным образом попавшие в компанию, а у остальных лапки.
В целом согласен с вами, коллега. Но все же считаю, что вопрос и ответ важны. Но только, если вопрос релевантный. Потому и предлагаю спрашивать что-то максимально приближенное, чтобы сам ответ тоже имел смысл.
Я полагаю, что на своем основном языке из коллекции элементы пофильтровать - это что-то абсолютно базовое. Тут нет алгоритма над которым надо думать или решать задачи оптимизации.
Вы бы хотели работать с человеком, который не может этого сделать?
Собственно если мы делаем более сложную, но релеватнтную (!) задачу, это помогает получить человека с релевантными навыками в моменте.
Если же цель нанять человека на вырост, то и проверять я бы предложил его умение вырастать.
Подскажите пожалуйста, что вы подразумеваете под "почитать о тех кого не наняли"? Может я бы смог удовлетворить ваш интерес.
У меня есть несколько простых задач.
Как он выстроит коммуникацию?
Кто-то предупреждает, что задача выглядит такой простой что «давайте я напишу, а вы потом скажете, правильно ли я понял».
Плюс: что предупредил о намерении.
Минус: что не смог сформулировать план реализации – в реальной жизни тоже пойдет писать как можно быстрее.
На мой взгляд, если сделать ещё одну итерацию в развитии вашего подхода, то можно и не давать человеку искусственные задачи, даже простые, и не гадать: "Ага! Он не уточнил постановку задачи, пошел сразу удалять все тройки, не уточнил сроки реализации и важность каждого из требований. А что если мне нужно удалять только каждую четную по счету тройку, а нечетные оставлять? Что если удаление троек - это основная фича и её точно нужно реализовать, а вывод в консоль - второстепенная фича и её можно сделать во вторую очередь? Ну, всё, раз не задал эти вопросы даже на такой простой задаче, то что от него можно ждать на более сложных?"
Я немного утрирую, но если вас интересует как человек выстраивает коммуникацию, работает с требованиями, умеет ли декомпозировать, приоритезировать, планировать задачи, то можно тупо спросить его об этом! Как он всё это делал на прошлых проектах. Для этого даже не нужны никакие задачи, не нужно проводить какой-то сложный анализ поведения соискателя, анализировать его мотивы. Если человека спросить какими интересными проектами он занимался, какие задачи и каким образом решал, то (сюрприз!!!) он в большинстве случаев об этом сам расскажет.
А не думаете - «на словах я Лев Толстой, а на деле…»?
А на деле Михаил.
Это видно уже после первых ответов на конкретные вопросы. Всегда можно провалиться в детали. Сначала спросить чем человек в принципе занимался, что это был за проект, кто им пользовался. Спросить чем конкретно занимался именно он - только бэком или иногда и фронтом. Занимался ли базой данных. Какие сущности были в схеме данных. Какие были сервисы, модули, классы. Можно задать много вопросов по процессу разработки, сколько человек было на проекте, как он с ними взаимодействовал. Бывало ли что в постановке задачи ошибка или постановка в принципе нереализуемая. Бывало ли что задача оказывалась сложнее, чем её изначально оценили. В зависимости от ответов можно проваливаться всё глубже и глубже. Или наоборот задавать вопросы всё шире и шире, чтобы понять на сколько целостное представление у него о процессе разработки вообще.
С одной стороны, такое интервью очень мягкое, потому что это просто беседа, к которой не нужно специально готовиться. Человек сам волен направить её в любую сторону, говорить о том, что ему ближе и интереснее. С другой стороны, это капец какое сложное интервью, потому что к нему невозможно подготовиться на курсах или решив сотню задач на литкоде. Представьте, что соискатель - это тот же Лев Толстой или человек с очень развитыми коммуникативными навыками, наверное самый мемный пример - это Mike Ross из Suits
https://www.youtube.com/watch?v=tcx3zwhEIOw
или бабушка вашего соседа по этажу - кто угодно, и они полгода прокачивались в прохождении интервью на разработчика. Неужели вы не отличите человека, который реально что-то разрабатывал от человека, который просто красиво об этом рассказывает? Да, встречаются люди, которые на интервью не умолкают и очень складно говорят, но, блин, реальный опыт человека или если нет опыта, то его способности, мотивация видны, я не представляю как это можно скрыть. Конечно есть в некотором роде талантливые люди типа Элизабет Холмс, но она менеджер, и в разработке такое сложно представить. В конце концов, на испытательном сроке будет видно работает человек или нет.
На мой взгляд такое интервью проверяет реальный опыт человека. Или если опыта нет/мало, то позволяет понять чем он в принципе интересуется, как впишется в проект. В отличие от алгоритмических секций, которые проверяют одну единственную вещь - решал человек аналогичные задачки или нет. Если решал - это клёво, и наверное он не будет реализовывать алгоритмы с кубической сложностью там где достаточно линейной, возможно ему будет легче дебажить сложный код и т.д. Но сможет ли он писать понятный код - уже хз, хотя с этим проблемы бывают гораздо чаще чем с алгоритмами. Сможет ли в целом поддерживать качество кодовой базы, а не умножать хаос. Сможет ли он самостоятельно декомпозировать сложные задачи. Сможет ли нормально работать с аналитиками, другими разработчиками, тестировщиками. Меня лично это интересует в профессиональных навыках человека куда больше чем умение решать алгоритмические задачки.
Минус такой беседы - не про всё на прошлых проектах человек имеет право рассказывать, и никогда заранее не догадаешься, насколько глубоко такая беседа может зайти.
Мне сложно придумать такой пример. Если это только что-то связанное с гостайной, какими-то ноу-хау или чем-то не очень законным. Я ни разу не встречал таких людей. В любом случае я думаю, что нет никакого секрета в том как на проекте был организован процесс разработки, были ли аналитики, тестировщики, как велась работа с ветками в Git, как декомпозировались задачи, на сколько сложным было приложение (сколько сущностей в схеме данных, сервисов, модулей и т.д.), как была реализована аутентификация, авторизация и куча других технически вопросов, на которые вполне можно ответить, не раскрывая секретов. Или просто отказаться отвечать, это вообще не проблема.
Все так!!
вот поэтому:
1 - я в статье предлагаю не давать алгоритмических задач, если это не критический навык для позиции
2 - увы времени не так много и если не обсуждать дотошно одну единственную мелкую тему, то очень легко не успеть докопаться, а потом узнать что человек ничего сам из того, о чем поет, не делал.
Я прям видел такое сам, один раз попался сам, и у знакомых примеры есть. А часами трындычать сложно - у кандидата есть жизнь и работа, а ты чаще всего не Гугл чтобы тебя терпели с таким подходом - там у кандидата офферов пачка обычно.
Иногда некоторые предприятия нанимают сварщика и предлагают ему сварить вместе две простые детали. Но я ещё не слышал, чтобы кандидату на должность сварщика предложили рассказать, как он будет варить шов.
А много ли сварщиков могут зарефакторить свой шов через пару недель, если деталь в продакшен ушла?
Работа на производстве несколько отличается от тапанья по клавишам и возможности откатить изменения в любой момент.
И не нужно спрашивать как он будет варить шов. Можно спросить как он варил швы раньше, как готовил поверхность, какие электроды использовал, какое оборудование, что если был нужен широкий или длинный шов (он варил их в один проход или в несколько), просто вел электродом по прямой или зигзагом, какая была техника безопасности, варил ли он швы в каких-то сложных условиях (на трубе под большим давлением, на большой высоте, в замкнутом помещении, в угольной шахте, ... - если такое требуется на объекте), как проверял качество шва, бывало ли такое что он сварил шов, а потом всё развалилось нафиг. Причём на эти вопросы нет правильного и неправильного ответа. Они просто показывают на сколько человек погружен в эту тему или хочет в неё погружаться.
Практические задачи - это наверное тоже хорошо. Но, блин, всё-таки между ИТ и сваркой есть разница. Сварщик на работе будет реально варить швы и если он не смог сварить тестовый шов, наверное не сможет сварить и реальный - возможно они не сильно отличаются.
А в ИТ тестовые и реальные задачи обычно не имеют вообще ничего общего. Алгоритмические задачи просто проверяют как человек готовился к интервью. Если не готовился, то он его не пройдет, каким бы гением разработки он ни был. А если готовился, то скорее всего пройдёт независимо от того на сколько отстойный он разработчик. И вопрос нафига такое интервью вообще, что оно проверяет? Знание алгоритмов - это безусловно бонус, возможно более полезный чем знание английского на уровне upper-intermediate, умение вышивать крестиком, водительские права категории Б и т.д. И я считаю, что разработчикам очень полезно прокачиваться в алгоритмах. Но это никак не основной скилл разработчика.
И не нужно спрашивать как он будет варить шов. Можно спросить как он варил швы раньше
Это, кстати, два разных вопроса и опытные интервьюеры их различают и, в зависимости от сигнала, который ищут, задают либо один, либо другой.
в ИТ тестовые и реальные задачи обычно не имеют вообще ничего общего.
Мне показалось, что статья как раз пытается разобраться с этой проблемой. В каком виде для вас лайвкодинг был бы приемлемым, как этап найма?
Лично я думаю, что лайвкодинг используется в следующих ситуациях:
Если в компании очень большой поток кандидатов и нужно максимально просто и эффективно их отсеивать. Если отсеяли хорошего кандидата, ну, ничего страшного, завтра будет ещё десяток.
Если у самого интервьюера небольшой опыт или вообще нет опыта и он не может оценить кандидата, просто беседуя с ним.
Если собеседование на джуниорскую позицию без опыта.
Если нет времени, сил, желания запариваться с интервью, то гораздо проще дать очередному кандидату очередную задачку, чем думать, напрягаться, задавать какие-то вопросы.
Если хочется сделать интервью максимально объективным. Решил задачу за полчаса - ставим плюсик. Успел оптимизировать алгоритм - ставим два плюсика. Не сделал задачу - ставим минусик. В итоге суммируем оценки и превращаем кандидата в число. Сортируем этот массив, получаем N лучших кандидатов, делаем им оффер. Хотя у меня есть смутное ощущение, что при этом упускается что-то важное. У каждого кандидата свой уникальный опыт, свои уникальные качества, которые в итоговую сумму не попали, потому что мы даже не спрашивали соискателя о его проектах, интересах.
Вообще я наверное не против лайвкодинга и сам время от времени решаю какие-то задачки, что-то изучаю. И алгоритмическая секция наверное не сильно оскорбила бы мои чувства :) Но на текущем проекте я вообще не вижу никакого смысла давать людям алгоритмические задачи, для меня важнее на сколько человек может работать самостоятельно, декомпозировать сложные задачи, соотносить важность фичи и сложность её реализации, писать понятный код, который потом не нужно переписывать, что-то обсуждать, если задачу непонятно как делать или есть много вариантов решения.
С каждым вашим комментарием, все глубже понимаю, что вы хотите сказать и с большей частью соглашаюсь.
Моя позиция такая - чаще всего алгоритмы не нужны, но базовый навык программирования и владения своим инструментом важен.
Его и проверю.
Сеньор удалит тройки за 5 минут, тест бахнет еще за 5-10. На этом с кодом все, поехали обсуждать остальное, что я бы хотел про него узнать, у нас еще минут 40 будет минимум.
Моя позиция такая - чаще всего алгоритмы не нужны, но базовый навык программирования и владения своим инструментом важен.
Так вы делаете распространенную ошибку, связанную с подменой понятий. То, что подразумевают под "задачами на алгоритмы" - это _и есть_ задачи вроде вашей, на поиск троек. Т.е. проверка базовых навыков программирования.
Проблема в том, что уровень кандидатов настолько низок, что они даже этого не могут и потом рассказывают, как их завалили "задачей на алгоритмы". Реальные задачи на алгоритмы (то, что подразумеваете под ними вы или другой человек, который _умеет программировать_) на собеседованиях практически ни когда и ни кто не дает.
Т.е. на самом деле в данном случае обсуждается проблема, которой не существует в реальности. Она выдумана.
Абсолютно с вами согласен. В этой статье я предлагал обсудить именно лайвкодинг и обсуждение навыков кодирования.
Если человек ничего не спросил и просто сделал, это не значит что я не готов с ним работать, но это факт, который тоже стоит пометить.
Точно так же пометить, как он отреагирует если сказать ему, что задачу можно было понять по разному.
Но разумеется финальный вывод про работу с требованиями я делаю не на задачах а на отдельных для этого вопросах.
Продолжаю повторять - нужно проверять, то, что ты хочешь получить.
В данном случае кажется мне не стоило упоминать про коммуникацию вообще - вы меня поняли не так как я рассчитывал. :) Спасибо, за комментарий, иначе я бы этого не узнал.
import java.util.List;
import java.util.Map;
public class C5_Parser {
private static final String dn = "CN=Ivanov Ivan Ivanovich,ADDR=Russia, Tatarstan rep., Kazan city, Some str.,bld. 404,OU=Development,DC=some-org,DC=ru";
public static void main(String[] args) {
List<Map.Entry<String, String>> parsed = parse(dn);
System.out.println(parsed);
}
private static List<Map.Entry<String, String>> parse(String dn) {
return null;
}
}Делюсь задачкой для собеса - распарсить кривую DN строку, в которой внутри значений могут попадаться неэкранированные запятые. Задачка основана на реальных событиях, и в реальности решилась минут за 10. Если у кого есть похожие простые задачки, тоже делитесь.
Лучик света просто )
Ещё одна статья про "алгоритмы не нужны" или демонстрация эффекта даннинга-крюгера. Подобное стремительное снижение стандартов скоро приведет к неспособности выдержать конкуренцию у индусов, которые делают то же, но просто демпингуют цены. Читать документацию они умеют не хуже нас, а в большинстве даже лучше, потому что английский язык для них официальный государственный. Соответственно, они первыми и быстрее хавают первоисточники. Но даже если предположить, что нет, то в чем наше преимущество? До сих пор это было советское наследие в виде мощного математического аппарата. Если копнуть во все успешные российские проекты - везде олимпиадники у корней. Тот же ВК - 2кратный чемпион мира по программированию. Но нет же, весь хабр испещрен статьями о ненужности алгоритмов. За последнюю неделю это четвертая статья. Сплошные фреймворковые программисты.
Так в большинстве своем и нужны «фреймворковые программисты». Статья предлагает спрашивать на собеседовании лишь то, что релевантно тому чем придется заниматься. Нужны алгоритмы или ещё какие-то специальные знания - спрашивайте.
Обидно когда на собеседовании спрашивают и про алгоритмы и про проектирование масштабируемых систем держащих сотни тысяч запросов в секунду, а на практике надо перекладывать сообщения из очереди в очередь с частотой десять сообщений в секунду.
Ровно наоборот. Мы (все те кто проживает на участке суши от восточной европы до дальнего востока по долготе и от полярного круга до средней азии по широте) берем не математикой, а прикладной сферой. А еще тем что можем пояснить как эта математика живет с другим инженерным багажом. Не все правда. И чем дальше тем больше не все, потому что селекция в индустрии направлена на рекрутинг "индусов" именно по вашим заблуждениям. Которые выдают полное непонимание и самой индустрии и людей которые там работают.
Вы видели хоть когда-нибудь код этих "индусов"? Типовой индус настроен на гугл-лайк собес, и не тренирует ничего кроме этого навыка. Алгоритмы, структуры данных, паттерны проектирования, языковые конструкции. Всё на пятерку. На практике же - хранение пересоздаваемого контекста в синглтоне и "я не понимаю что не так".
Я с большим умилением слушаю как собеседуемый привязывает принципы солид к своему опыту, приводя конкретные примеры из реализованных проектов, даже если мне приходится подсказывать что там за очередной буквой. Это показывает что он их осмыслил, а не зазубрил. И мне вообще неинтересно как он переложит жейсон, или байтики в задачке которая формализована до уровня применения алгоритмов. По факту у меня нет таких задач. И у него не будет. Собственно это я и вижу в статье - ищите человека по тем критериям которые нужны для его вакансии. Спрашивайте его о том что ему придется делать. Это единственно правильный подход. Я и сам именно так веду собеседования и когда их прохожу то стараюсь не слить и переживаю именно за те которые прошли не по методичкам для олимпиадников. Потому что с людьми которые подходят к собесам столь формально я банально не сработаюсь.
Реальность же индустрии такова, что написав куб вы не навредите проекту так как навредите ему не продумав апи своего очередного модуля. Или выстроите взаимодействие слоев так что заложите бомбу под дальнейшее сопровождение. Если уж вас так волнует будет ли человек писать кубы и квадраты - пусть он вам расскажет что это такое. А потом спросите ейчара понятно ли ему. Заодно проверите навык донесения технической мысли до будущего ПО у которого понимания той самой технической мысли примерно столько же сколько у HR, а планировать надо опираясь на разного уровня невнятности бормотание разработчика.
Касаемо вк и прочих спешал олимпикс - погуглите "чат активити" телеги. Этот мем в дроид-разработке давно стал классикой.
Почти хорошо. Будет проблема с некоторыми людьми вроде меня. Я не включая мозг за минуту бахну однострочник на стримах и буду глупо смотреть на вас с вопросом: А что на самом деле делать-то надо? Потом уже постараюсь договориться и выяснить а что имелось в виду на самом деле. Вероятнее всего начну говорить про проблемы сайд эффектов внутри стримов. Мол падают, оборачивать правильно надо, обрабатывать что вернулось и все такое. Уточнять что-то когда написать занимает реально минуту можно и не сообразить.
Потом подключение тестов. Я попробовал подключить junit в чистую идею. Ну в целом за один запрос в Гугл и минут 5-10 оно заработало. С нервами будет посложнее и подольше. Люди в среднем подключают тестовые библиотеки примерно никогда. Стоит намекнуть что это стоит сделать заранее.
Остальное все просто хорошо.
Вы бахнете однострочник на стримах. Я буду в восторге. Я даже буду на вводной к задаче предупреждать вас, что задача "ровно на столько простая", просто напишите. Затем мы напишем с вами тестик другой. И пойдем уже погружаться в детали или иные навыки которые мне от вас нужны, которые тоже надо как-то глянуть.
За 5 минут я узнаю что имплементация кода с коллекциями по инструкции не представляет для вас трудности и вы вообще в жизни писали тесты.
Прошу прощения, но, как мне кажется, задача про "удаление троек" это такая же литкод-задача, как и надоевшие всем задачи на деревья/палиндромы/скобки (моя первая ассоциация, которая мне пришла после прочтения условия - замысловатая поза йога).
У меня есть несколько простых задач. Часть специфична для языков, библиотек и кейсов (ну и опыта кандидата).
А можно пример с одной из таких задач, специфичной по кейсу, для джун+/миддл (просто любопытно)?
Да вроде бы нет, т.к. я так понял интервьюер тут не ждет оптимального решения по памяти или cpu. Тупо как угодно проверил элементы, умножил и т.д. - вернул новую коллекцию. Даже мозг особо включать не нужно.
Литкодом это было бы, если бы было требование не создавать новую коллекцию, а использовать исходную, при этом без пропусков на месте троек.
Я бы тоже тесты в main написал, т.к. это намного проще и не надо вспоминать как там пользоваться JUnit (на последнем месте работы не писали тесты).
TL;DR - замените ваш литкод мидиум на литкод изи, нажимайте на софт скилы во время кодинг интервью
В сухом остатке - софт скилы норм не поняли и кодинг не потестили как надо.
Что-то зачастили посты про задачки и собеседования.
У меня для противников задачек такой вопрос. Эти задачки (в том числе та, что в этом посте) - они уровня задачей из ЕГЭ по информатике, ну или после первого курса программирования в институте/колледже такие задают. Т.е. они правда про самые базовые знания и понимание того, как работают самые базовые типы того языка, на котором, по заявлению кандидата, он постоянно пишет код. Ровно как базовые упражнения на площадке для водителей, типа параллельной парковки, или сварить 2 пластины для сварщика. Вы считаете, что спрашивать такие базовые навыки, которыми обладает студент, если не школьник, у человека, который заявляет, что он профессионал, некорректно?
Я частично понимаю заявления про "я же пишу код в IDE, а тут меня на бумажке заставляют писать". Но вы же код-ревью не в IDE, делаете, правда? А там вы как понимаете, что ваш коллега аргументы функции не перепутал? Наверное, самые популярные то вы запоминаете, да?
Ну и это один из самых объективных и прозрачных видов интервью. В "разговоре по душам" или в рассказе про прошлый опыт возможно огромное количество человеческих ошибок, как на стороне кандидата, так и на стороне интервьюера, а код - вот он, перед всеми. Как пластины у сварщика.
Забавно, человек из Ozon рассказывает про плохие собесы, в то время как на собесах Ozon, HR по телефону задаёт вопросы с листочка, про сложность алгоритмов List в C#, и это на должность веб-разработчика в логистику.
задаёт вопросы с листочка, про сложность алгоритмов List в C#,
Пока тред в faang не сменится и там не скажут что "лучше спрашивать про конкретную работу/проект" вряд ли что-то поменяется. У меня спрашивали какой алгоритм внутри сборщика мусора в го, я мб чего-то не понимаю, но хз зачем это знать, т.к. я явно не буду в исходниках компилятора пытаться исправить что-то
ну моя статья не в корп блоге Озона, это мои личный опыт и мнение - за шарповые вакансии в логистике я вам не поясню (
Вот я одного не понимаю. Для программирования берут программиста. Почему для интервью берут не интервьюера, а снова программиста? То есть берут человека, без опыта, без знаний и заставляют работать. Каков результат? Чаще всего плохой. Вы же не скажете интервьюера за питон проверять ошибки в коде. Потому и дичь творится на собеседованиях, что никто не знает, что происходит. Ни кандидат, ни представитель компании.
начинает, мыча, for-циклы крутить.
А что не так с for-циклами?
Я не из мира java, но предположу, что при работе с коллекцией там есть встроенные механизмы, которые могут хорошо параллелиться, что даст выигрыш на реально больших коллекциях.
У меня это простая задача на области видимости, на понимание отличия локальных и глобальных переменных в языке. Не решают 80%.
Прочитал задачу и сразу стали интересны запятые. Все тройки - это все цифры "3" или тройки чисел? Почему спрашиваю. Далее идёт фраза "для всех нечётных". Это странно. Тройка нечетна изначально.
Вызывает печать. В какой момент? В момент удаления или когда-то потом.
Удаляет семёрки. Тут понятно.
Умножает все на 2. Ок. Разве что оверфлоу может быть. Мало ли какая там коллекция. Что напишем в этом случае?
Интересно
Признаюсь, если даже предлагают что-то там начать писать на звонке, то я отказываюсь. Для этого всего у меня есть GitHub, который скидываю всегда заранее.
Правда я и варюсь в этом всем почти 15 лет
Если ваш гитхаб большой и релевантный, то это большой плюс и для позиций где надо прям имплементить логику это тоже инструмент знакомства с вами.
Хотя лично я попросил бы тройки удалить все равно - в вашем сетапе и с имеющимся навыком вы бы сделали это оч быстро.
Так я как раз про то и пишу, что я бы просто отказался.
Лично я не могу переключать голову из режима говорения в режим написания моментально, а также собеседование - мягко говоря не самая приятная штука. Человека первый раз вижу вообще и тд
У кого-то общительного, может, это происходит без проблем, но у многих - нет. Это вызывает только раздражение и отторжение.
А то получается как-то странно, вот куча кода разного в репозиториях, а никто даже не захотел посмотреть и просит сделать что-то, стоя над душой. Выглядит часто больше как попытка самоутвердиться и поднять чувство значимости.
Сразу ощущение, что как-то не по пути нам и тд. А то тут часть волос уже седых проскакивает, а тут снова как 15-20 лет назад на экзамене. Хотя нет, на экзаменах-то вопросы заранее известны и можно подготовиться - кажется, что это не просто так))
К счастью работ море вокруг с нормальными ЗП и людьми.
Да и есть альтернативы написанию - это вместе посмотреть на кусок плохого кода и обсудить как его исправить. Собственно я так и делаю иногда, когда сам провожу - это воспринимается абсолютно нормально людьми.
Особенно бывает интересно, когда уже начинаю я в ответ спрашивать человека, который собеседует меня, и внезапно оказывается, что он сам-то ничего не может ровным счетом сказать и написать. И, как деликатно и интеллигентно выше выразились, сам начинает "мычать".
Уж извините, но когда человек про других людей говорит, что они "мычат" - сразу как-то все понятно становится
Проходил недавно собеседование с отрицательным результатом. Много думал. hh и Мамба это одно и тоже. Собеседование и продажи это одно и тоже. А я в продажах не работал. Скачал книгу 49 законов продаж. Узнал то, что сам бы никогда не додумал. По итогу на сайте своего проекта выкинул страницу где я "рисовал чаек за клиента" (Правило № 18). В общем извлек значимую пользу из отрицательного результата.
Я бизнес-аналитик, немного знаю Python и это мой первый комментарий, поэтому:
# удаляет из коллекции все тройки, для всех нечетных чисел вызывает побочный метод печати в консоль, удаляет все семёрки и возвращает коллекцию-результат
def ozon_interview(a):
a = [i for i in a if i != 3]
print(*[i for i in a if i%2])
return [i*2 for i in a if i != 7]
# пусть на вход подается список целых чисел через пробел:
print(ozon_interview([*map(int, input().split())])):-)
Очередной взгляд на собеседования. Часть 1