Comments 36
UFO just landed and posted this here
А как одно мешает другому?
Главное, чтобы потом в продакшн-коде сочинителя не появлялось что-то похожее на вторую задачку.
Как раз подобный вопрос мы и обсуждали на конференции с участниками квеста: главные цели подобных задач — запутать, проверить внимательность, заставить сомневаться. Некоторые торопятся и дают неправильный ответ, некоторые не вчитываются в условие, некоторые ошибаются в подсчетах. Если бы здесь было меньше лишнего, некрасивого или трудно читаемого кода, скорее всего почти все отвечали бы правильно, из-за чего квест наскучил бы очень быстро :) Да и просто здорово, когда человек приносит неправильный ответ, говорит «как неправильно??», потом замечает ошибку и радуется, что теперь все правильно — это очень приятные чувства :)
Повышайте значимость вопросов на собеседовании для бизнеса, проверяйте образ технического мышления и инженерного подхода к решению проблемы. Когда ответ на вопрос, который не получил правильного ответа на собеседовании находится за 2 минуты после него — это сомнительная задача для собеседования.
Иногда складывается впечатление, что программистами рекрутеры признают только гиков… Поймите меня правильно.
На самом деле, исходя из тех заданий, которые мне давали на собеседованиях, нельзя сказать, что рекрутеры так уж категоричны. Много кто пытается подготовить общий набор вопросов (которые, кстати, покрываются тем же Рихтером + Тепляковым почти целиком) и иногда несколько заданий, проверяющих мышление. Программисты бывают с разным опытом, и вполне нормально, что кто-то не способен решить те несколько «особых» заданий. Иногда тебе везет, иногда знаешь ответ, иногда открывается «третий глаз», и ты просто вычисляешь правильный ответ. Собеседования — это вообще скорее лотерея, чем проверка на гика :)
UFO just landed and posted this here
Везде завалил арифметику. Давайте уж и шестнадцатеричное представление ответов, а то выглядит дискриминацией.
На самом деле, ответы в двоичном представлении принесло человек 20 :)
Идея с двоичным представлением была рождена, когда думали на ноуты слать запароленные архивы с задачками, а паролем к ним — конкатенацию ответов на все предыдущие задания, чтобы и пароль был непростым для подбирания, и решение всех предыдущих задач требовалось для открытия каждого из архивов. Потом решили, что нехорошо завязываться на технику, и сделали карточки, но двоичное представление оставили :)
Идея с двоичным представлением была рождена, когда думали на ноуты слать запароленные архивы с задачками, а паролем к ним — конкатенацию ответов на все предыдущие задания, чтобы и пароль был непростым для подбирания, и решение всех предыдущих задач требовалось для открытия каждого из архивов. Потом решили, что нехорошо завязываться на технику, и сделали карточки, но двоичное представление оставили :)
Сложность функции — это что вообще?
Вот навскидку статья на хабре
Сложность алгоритма — функция от объема входных данных (и еще некоторых параметров)
Сложность функции — эммм…?
Скорее задача должна звучать как — расположите данные функции по эммм… ну я даже не знаю, по скорости роста на больших N…
Слабенько, на самом деле для задач, которые должны что-то показать на собеседовании.
Для tricky задач — слишком прямолинейны, для вопросов на искусство программирования — не то.
Итого — подойдет чтобы отсеять слабых джуниоров и найти джуниоров посерьезнее. Для практикующих программистов, увы, не репрезентативно.
Сложность функции — эммм…?
Скорее задача должна звучать как — расположите данные функции по эммм… ну я даже не знаю, по скорости роста на больших N…
Слабенько, на самом деле для задач, которые должны что-то показать на собеседовании.
Для tricky задач — слишком прямолинейны, для вопросов на искусство программирования — не то.
Итого — подойдет чтобы отсеять слабых джуниоров и найти джуниоров посерьезнее. Для практикующих программистов, увы, не репрезентативно.
Что такое сложность алгоритма я представляю, но в условии задачи 4 про алгоритмы ни слова. И да, если не читать предисловие и комментарий к задаче, то далеко не очевидно, что же там имеется в виду.
А зачем спрашивать про вывод на консоль? Запустил — посмотрел.
Решил только 4 и 5, первые три вообще не понял набора букв — это что, такое современное программирование?
Никогда мне не стать программистом. Выпью. Тоже не стану.
Никогда мне не стать программистом. Выпью. Тоже не стану.
И так, человек пришел на собеседование. На собеседованиях логично спрашивать задачи, которыми занимается компания. Ну т.е. пришел человек в геймдев, ему сразу там задачки на векторную алгебру там, пересечения плоскостей векторов в 3D и тд. Пришел человек в dev банка, ему сразу там вопросы про безопасность, транзакции и тд.
Пришел человек на собеседование и видит вот ЭТО. Да еще и написано уберужасным стилем ( реально увидев такое в продакшене я бы уволил). Реакция нормального человека сказать — досвидания, я пошел.
Пришел человек на собеседование и видит вот ЭТО. Да еще и написано уберужасным стилем ( реально увидев такое в продакшене я бы уволил). Реакция нормального человека сказать — досвидания, я пошел.
Расслабьтесь. Поищите здесь статью про неспособность "программистов" написать реализацию алгоритма пузырьковой сортировки. Там очень смешные комментарии. Как только "программисты" не отмазывались, каких только нелепостей не придумывали для оправдания своей неспособности написать три строчки кода. И даже когда им дали эти три строчки они продолжали настаивать, что "настоящие программисты" вовсе не обязаны уметь написать трёхстрочную реализацию по формальному описанию простейшего алгоритма, поскольку это задача офигенной сложности. Они действительно считают себя программистами и сеньорами и прочими крутыми словами. И они в реальности приходят на собеседования. И их процентов 95. Или 96. Поэтому я абсолютно спокойно отношусь к таким заданиям. С пониманием. А все эти хлопанья дверями, "я бы за такой код уволил", — ну, этим вв покажите свою неадекватность, не более. А я напишу эту пузырьковую стртировку или бинарный поиск за пару минут и перейду к обсуждению более интересных вещей.
Да я стараюсь в принципе не напрягаться ))). Насчет баблсорта другой вопрос (хотя тоже спорный), все-таки это алгоритм, вы просите человека написать свое видение этого алгоритма. В обобщенном виде можно даже назвать это тестовым заданием. Здесь же человек просит соискателя поработать компилятором/рантаймом для ужасного, корявого кода. Уходить надо спокойно, без хлопаний дверьми, просто — спасибо, до свидания, я все понял. Показаться кому-то неадекватным — абсолютно не страшно, большинство людей, которые чего-то в этой жизни добились, казались кому-то неадекватными.
Насчет баблсорта другой вопрос (хотя тоже спорный),
Да ладно, чего там спорного. Если человек не может написать трёх строк кода, то можно выставлять его за дверь.
Здесь же человек просит соискателя поработать компилятором/рантаймом
Если у вас работа — не быдлокодинг прямолинейного кода по отображению страничек, то вы периодически работаете и компилятором и рантаймом. При отладке. А при разработке многопоточного кода ещё и немного процессором и контроллером кэш-памяти :). По-моему, нормально.
для ужасного, корявого кода
Ну, это вообще офигенная возможность обсудить ужасность и корявость кода.
Уходить надо спокойно, без хлопаний дверьми, просто — спасибо, до свидания, я все понял.
Но ваша воля не пользоваться такой прекрасной возможностью ;)
большинство людей, которые чего-то в этой жизни добились, казались кому-то неадекватными.
Да, мы все знаем этих трёх человек. Остальные неадекваты так неадекватами и остались и имя им — легион.
С такой логикой, будет сложно найти сотрудника. Получается, начал работать в банке — всё, теперь только банки. Связался с 1С.., ладно про 1С неудачный пример. Если серьёзно, мне не принципиально, чем занимался разработчик. Если он хорошо знает свой инструмент (язык) и хорошо соображает — значит сможет освоить и нашу область. Как оценить знания соискателя кажый выбирает по своему — кто-то такие вот задачки даёт. Впринципе, и по ним можно оценить, например, даже если человек ошибся, но смог объяснить где и почему — значит разбирается. Хотя, мы делаем проще — спрашиваем прямо, что-то вроде: «как работает LINQ», или «как работает yield return» (если не джуниор, конечно).
С такой логикой, будет сложно найти сотрудника.
Ну как бы так в жизни и бывает, человек начал работать в бэк-энде банка, вряд ли он придет на геймдева куда-то еще, а если и придет, то только с понижением в ЗП пока до всего не дойдет. Ваш подход подходит для подбора человека «на вырост». Этим приходится заниматься, когда не нашел того, кого нужно сразу, и понимаешь что человечка нужно будет растить =).
Хотя, мы делаем проще — спрашиваем прямо, что-то вроде: «как работает LINQ», или «как работает yield return» (если не джуниор, конечно).
Вам когда ремонт в квартире надо сделать, вы рабочих тоже спрашиваете — как шуруповёрт работает?
Понятно, что нужно знать где применять и во что это обойдется, но вопрос «как» — странный, вы еще может и на бумажке просите написать IL код, в который компилируется например yield?
Сугубо имхо — подобные задачи в непрофильной отрасли (не связанной напрямую с постоянной работой над математическими алгоритмами) — это пережиток институтского воспитания. Этакий экзамен, где тебе запрещено пользоваться всем, и ты обязан все помнить (закрыли учебники, убрали мобильники, решайте; здесь — убрали IDE, вот вам бумажка, решайте). В нормальной разработке я за свои 6 с лишним лет работы ни разу не встречал ситуации, когда бы мне пригодилось «крайне полезное» умение прогнать задачу на бумажке, не имея под рукой IDE (потому что она у меня всегда под рукой, я же на работе, а не в поле, в конце концов). Правильное собеседование (имхо) — это правильные теоретические вопросы, имеющие прямое приложение в практике данной компании, а также предложение тестового задания, чтобы оценить практические умения. Компания (нормальная компания) нанимает сотрудника, чтобы он решил ее практические задачи, а не прогонял задачи на бумажках. У вас же получаются «вопросы ради вопросов». Я бы не ответил ни на один. Хотя пишу достаточно тяжелые и мощные приложения вроде банковского ПО, биржевого ПО и так далее. Вот верите-нет — ни разу подобные задачи не пригодились. Зато практических сложностей — хоть отбавляй, и у любого специалиста так, я уверен. На «бумажке» умеют решать максимум заточенные на это выпускники ВУЗов. Настоящий специалист, как правильно писали выше, увидев такое, просто развернется и уйдет, поняв, что в компании с такими принципами отбора сотрудников делать явно нечего. Еще раз, математические и алгоритмические задачи нужны там и только там, где они напрямую используются постоянно, — аналитика, геймдев, физические движки, криптография, сжатие данных, и тому подобные области. Если же вы этого не касаетесь — то «программист должен иметь математическую базу» — это один из худших подходов к оценке способностей специалиста, коих я повидал немало.
Кстати, да, за второй код — убил бы. И моя реакция на такой код была бы «разобраться, как оно работает, затем настучать по рукам тому, кто это написал, и провести рефакторинг». И, естественно, не на бумажке, а в IDE, с отладкой и вдумчивым изучением ситуации. Надуманные задачи, не имеющие ничего общего с практикой, находят лишь специалистов, готовых решать только теорию, без практической явной пользы. За редкими исключениями.
Согласен. С таким же успехом можно генерировать задачи с помощью какого-нибудь csmith (ну и обфусцировать ещё для надёжности) и просить рассказать, что оно там будет делать. Множество всех программ бесконечно, зачем же давать адекватные? Нагенерил тысячу строк, которые компилятор едва собрал — отдавай кандидату.
Про epam вообще много на ebanoe.it.
Если честно от таких задач блевать тянет. В упор не понятно какие навыки выявляют подобные задачи и кого вы ищете на собеседованиях?
Если уж собеседование на C# то спросите про кругозор и глубину знаний. Какие задачи решались с применением C#, почему было выбрано именно такое решение.
Такое чувство, что рекрутеры программисты-неудачники и пытаются обыграть в наперстки обычных людей, реализовав свои комплексы превосходства.
Пожалуй возьму такую контору «на карандаш», чтобы обходить ее стороной.
Если уж собеседование на C# то спросите про кругозор и глубину знаний. Какие задачи решались с применением C#, почему было выбрано именно такое решение.
Такое чувство, что рекрутеры программисты-неудачники и пытаются обыграть в наперстки обычных людей, реализовав свои комплексы превосходства.
Пожалуй возьму такую контору «на карандаш», чтобы обходить ее стороной.
UFO just landed and posted this here
Код, который приведен в первых двух постах, должен напроч отсуствовать в проде, либо быть переписанным в рамках следующей задачи которая его коснется.
За весь опыт разработки ПО, основная сложность найти адекватного человека. Такие вопросы на собеседовании ни разу не помогают его выявить. Эти задачи показывают лишь что человек как-то знает инструмент, а потом выясняется, что пользоваться им не умеет.
Я бы понял, если бы были задачи еще переписать код на более понятный.
За весь опыт разработки ПО, основная сложность найти адекватного человека. Такие вопросы на собеседовании ни разу не помогают его выявить. Эти задачи показывают лишь что человек как-то знает инструмент, а потом выясняется, что пользоваться им не умеет.
Я бы понял, если бы были задачи еще переписать код на более понятный.
Первые две задачи полезны тем, что заставляют обратить внимание на особенности языка, о которых обычно не задумываешься.
Кстати, а есть ли аналог книги «Java puzzlers» Джошуа Блоха, но про C#?
Кстати, а есть ли аналог книги «Java puzzlers» Джошуа Блоха, но про C#?
А по пятой задаче, «Последовательность вычисляется как» — откуда следует это утверждение?
Не совсем понятно откуда формула взялась
Не совсем понятно откуда формула взялась
Мне вот интересно, в первой задаче зачем этот кусок кода
var y = numbers.GroupBy(x => x).Select(x =>
{
result += x.Key;
return x.Key;
});
20 лет в индустрии, ни разу не сталкивался в жизни с задачами которые были на собеседовании
Sign up to leave a comment.
Квест от ЕРАМ: пять задач с собеседований по .NET