Сейчас я ищу новую работу в качестве разработчика. Есть две вещи, которые обычно требуют компании, которые меня очень беспокоят: длинные задания по программированию и проверка рекомендаций. На этом сайте много вопросов об обоих вещах.
Есть и другие вещи, которые беспокоят меня еще больше: после выполнения такого процесса я обнаруживаю, что код или система, с которой я собираюсь работать, — это катастрофа, или сама компания.
Итак, я начал безуспешно (и неудивительно) пытаться просить компании взамен:
Одна из компаний заявила, что то, что я прошу (контактные данные 2-3 человек, просили 6), является необоснованным. Это? Я признаю, что они имеют право делать все, что считают необходимым, чтобы привлечь лучших людей на борт. Разве я не могу сделать то же самое?
Я спросил: «Не могли бы вы в течение нескольких минут рассказать мне о вашем лучшем и худшем коде?» последние два раза я искал работу, обычно в конце, когда люди спрашивают: «У вас есть вопросы к нам?» До сих пор это повсеместно воспринималось как положительное. Не все компании могут быть готовы/способны это сделать — многое зависит от корпоративной культуры, размера, отрасли и т. д.
Причина, по которой я запрашиваю лучший и худший код, заключается в том, что я могу получить смутное представление о том, что они считают «хорошим кодом», а также получить смутное представление о том, что они считают проблемами в своей кодовой базе. Обратите внимание, что это не обзор кода, а скорее начало обсуждения состояния их кода, будущих планов по улучшению кодовой базы и, что наиболее важно, их общего подхода к разработке программного обеспечения. Даже если они не могут/не хотят показывать вам код, это все равно может стать хорошим началом разговора; например, они могут устно описать, почему они считают свой хороший код хорошим или плохой код плохим.
Некоторые организации имеют на этот счет удивительно забавные идеи. Чтобы привести пример, одна организация показала мне то, что было явно огромной мешаниной из спагетти, и самые большие проблемы, которые они указали с этим, были « часто не добавлялись ключевые слова» и «имена переменных не всегда были описательными» public. privateХотя это обоснованные опасения, они были далеко не самыми насущными проблемами с этим кодом. Они явно не понимали, что делают. Я действительно работал там, так как там работала моя подруга, и я доверял ей, но это оказалось большой ошибкой и неприятным опытом для обеих сторон.
Приложение : ОП вернулся и написал в комментариях следующее:
Хотя я нашел это хорошей идеей и пробовал ее несколько раз, результаты были довольно плохими: крупные компании не могут этого сделать, так как им нужен процесс, который они не внедрили, но это нормально, потому что крупные компании обычно этого не делают. Я не даю тебе домашние задания. Другие компании, в том числе и те, которые дают вам домашние задания, отказываются с лучшими или худшими извинениями, обещают сделать это, а затем никогда не отправляют или не понимают, почему/чего вы хотите. Пара из них прислала мне целые репозитории с несколькими тысячами строк кода, что, по крайней мере, было честно в том смысле, что я знал, чего ожидать. - антонро
Таким образом, похоже, что ваш пробег может варьироваться; Я могу говорить только из своего ограниченного личного опыта. Я брал интервью почти исключительно в небольших «некорпоративных» компаниях, и, возможно, это также немного зависит от вашего местонахождения (я в Европе). Важно подчеркнуть, что я никогда никого не просил присылать мне что-либо, а просто немного походил с ними по коду во время интервью в течение нескольких минут. Просто отправка кода кажется мне довольно бесполезной, потому что разговора нет: ценность в основном в разговоре, а не обязательно в коде как таковом, который в этом контексте в основном является MacGuffin .
Что касается запроса контактной информации сотрудника, то мне это кажется довольно странным. Я понимаю, откуда вы исходите, но помимо проблем с конфиденциальностью, это также может поставить рядовых сотрудников в довольно сложное положение.
Вместо этого используйте такие сайты, как Glassdoor, где нынешние и бывшие сотрудники могут оставлять отзывы, если захотят. Для средних и крупных компаний это должно дать вам разумное указание, хотя я настоятельно рекомендую прочитать некоторые обзоры , а не слепо доверять рейтингу 4,4 (или чему-то еще).
Я являюсь работодателем нескольких разработчиков.
Отборочные тесты: мы просим кандидатов ответить на 20-30-минутный тест с множественным выбором, который пытается отсеять кандидатов, которые никогда не преуспеют на собеседовании по программированию. Это в интересах кандидата, а также работодателя, поскольку это сокращает время, затрачиваемое всеми сторонами.
Если ваш потенциальный работодатель просит вас несколько часов программировать, прежде чем даже поговорить с вами, он НЕ эффективен и не уважает ваше время, и это большой предупреждающий знак . Тем не менее, правильный ответ — вежливо отказаться и уйти (если вы в состоянии сделать это), а не просить работодателя потратить на вас много времени, прежде чем они даже узнают, компетентны ли вы.
Интервью по кодированию: вы должны понимать, что найм — это тоже не забавный процесс для работодателя. Вы должны пробираться через множество кандидатов, которые подали заявку на работу, которую они не в состоянии выполнить. Вот почему интервью по программированию так полезны.
Я прошу потенциальных сотрудников кодировать на собеседованиях, чтобы увидеть:
Справедливо ли просить показать часть нашей кодовой базы? Да, и я бы рассмотрел этот вопрос, если бы уже был уверен в способности будущего сотрудника программировать, и если бы у потенциального сотрудника было достаточно опыта, чтобы понять, на что он смотрит.
Обратные проверки ссылок: я вообще не провожу проверки ссылок. Я думаю, что это бессмысленно, так как лично я давал положительные отзывы бывшим сотрудникам, которых я больше не нанял бы. Почему? Потому что я могу найти правдивые положительные вещи, чтобы сказать обо всех своих сотрудниках, и у меня нет шкуры на кону. Есть только один бывший сотрудник, для которого я бы не стал этого делать, и для этого человека я бы сказал, что проверка рекомендаций противоречит политике компании.
Однако, если бы меня попросили на собеседовании дать контактные данные нескольких бывших сотрудников, я бы ответил: «Спасибо за уделенное время. К сожалению, вы явно не подходите для этой роли».
С другой стороны, если бы я уже вел переговоры о найме сотрудника, которого я действительно очень хотел, да , я бы спросил бывших сотрудников, не захотят ли они дать нам справку.
Здесь уже есть несколько хороших ответов, но я добавлю свою мысль. Вам не приходило в голову, что их оценка вас — это ваша возможность оценить их?
Позвольте мне привести вам два разных примера, основанных на моем реальном опыте:
Угадайте, в какой компании я хотел работать?
Во время интервью ОЧЕНЬ важно произвести впечатление на интервьюеров, но ищите подсказки. Прислушайтесь к их отзывам об этих задачах, если это совместная работа и у вас дружеская беседа, то именно так работает их компания. Если это «недостаточно хорошо», то вы, вероятно, не вписываетесь в их шаблон.
Они ХОТЯТ, чтобы ты был кандидатом (поверь мне, они уже насмотрелись на плохих кандидатов). Но компании часто забывают, что вы хотите, чтобы они были компанией. Ищите подсказки о том, на что похожа компания, из самого процесса собеседования!
Что касается примера кода, если они попросят вас выполнить задание по программированию, попросите показать их стандарты кодирования, чтобы вы знали, как они ожидают, что код будет выглядеть, а также дайте представление о том, что они считают хорошей практикой кодирования.
Это не означает, что их код будет таким. Некоторые места могут управлять устаревшими приложениями или версиями с ужасной кодовой базой. Все, что не имеет стандартов кодирования (или не может указать на общие стандарты, такие как PSR-2), может иметь проблемы с качеством кода.
Небольшой фрагмент кода может быть не лучшим признаком, так как они могут написать небольшое приложение, которое будет очень аккуратным, но не будет представлять их основную кодовую платформу.
Что касается допроса сотрудников, спросите людей на собеседовании о лучших и худших сторонах работы там. Они могут обсудить это, и это ставит многих людей в тупик, поэтому не всегда репетируется.
Я понимаю ваше разочарование. Вы хотите иметь достаточно данных, чтобы принять обоснованное решение. Но вы сильно рискуете.
Если вы не намного превосходите других кандидатов с точки зрения требований, и компания перешла от режима собеседования к попытке убедить вас принять их предложение, ваши запросы, вероятно, заставят их решить, что делать предложение вам не стоит.
Столкнувшись с кандидатом, который хочет, чтобы я нашел код разоблачения, и хочет взять интервью у нынешних и бывших сотрудников; по сравнению с 9 другими, которые не просят об этом - я бы сосредоточился на 9.
Независимо от того, на каком этапе процесса находится ваша заявка, я считаю, что существует риск того, что ваша заявка не дойдет до следующего шага. Пока у компании больше квалифицированных кандидатов, чем открытых вакансий, они могут принять решение о быстром исключении заявок.
Как сотрудник я не уверен, что хотел бы пройти собеседование с кандидатом, если только это не было частью процесса для всех кандидатов. И в рамках этого процесса я буду оценивать кандидатов.
your requests will probably make them decide that it isn't worth making an offer to you. Откровенно говоря, если компания интерпретирует простые просьбы как повод для прекращения собеседования, я бы не хотел там работать. Почему бы им просто не сказать «Нет, извините»?Пожалуйста, простите еще один ответ в длинной серии ответов, но в моем предложении прямо указаны некоторые вещи, которые подразумевают другие ответы:
Во время собеседования компания будет спрашивать вас о вещах, которые их волнуют, и это может многое вам сказать, если вы будете внимательны. Проверка кода, модульное/интеграционное тестирование, стандарты кодирования — вот инструменты, которые помогают компаниям писать хороший код. Компании, которые заботятся о хорошем коде, используют эти инструменты, и в результате они будут спрашивать вас о вашем знакомстве с ними. Если сам процесс собеседования не делает его чрезвычайно важным, следуют ли они передовым методам, вот такие вопросы, которые я бы задал как интервьюируемый, чтобы попытаться понять это:
Эти вещи могут многое рассказать вам о компании, не нуждаясь ни в чем другом. Вы также можете сформулировать их так, чтобы они не звучали как вопрос и вовлекали интервьюера: «В прошлом я работал в командах, которые используют битбакет для управления проверками кода. Какие инструменты вы, ребята, используете для управления ими? " или «В дебатах «табы против пробелов» наша команда выбрала X. С ума сойти, сколько споров это вызвало! Как вы, ребята, приземляетесь в этих дебатах, и как вы, как команда, решаете, каким стандартам следовать?».
Подобные вопросы решают несколько задач:
Если вы спросите их о «табуляции против пробелов», и они ответят что-то вроде «Я не знаю, что бы люди ни хотели, я думаю», то вы, очевидно, проводите собеседование с компанией, которая не воспринимает вещи всерьез. Если вы начинаете дружеский разговор о непрерывной интеграции, а они не понимают, о чем вы говорите, то, очевидно, вы не по адресу.
По сути, компании, которые пишут хороший код, делают это потому, что разработчики заботятся о хороших методах написания кода. В результате вы сможете вести связный разговор с тем, кто берет у вас интервью во время технического собеседования, о лучших методах кодирования. Конечно, когда вы войдете, вы можете обнаружить некоторые области, где их стандарты не соблюдаются так, как они утверждали во время интервью - в конце концов, никто не идеален. Однако, если сотрудники заботятся о стандартах, то, по всей видимости, вам не о чем беспокоиться в этой области.
Как вы уже видели, это не лучшая техника интервью. Если бы это было так, это было бы обыденностью.
Попросив показать образцы кода вашего потенциального работодателя, вы превращаете собеседование в обзор кода, где вы являетесь судьей. Это также интеллектуальная собственность, и существует возможность раскрытия конфиденциальных материалов третьей стороне (вам, кандидату).
Этого не произойдет.
Вы также запрашиваете конфиденциальные контактные данные предыдущих сотрудников. Этого тоже не произойдет (по понятным причинам).
Вы можете лучше всего оценить пригодность компании, проведя исследование и задав вопросы, это то, что делают все остальные.
Например, совершенно нормально, если вы спросите, с какими трудностями они столкнулись при внедрении или проектах, а также поинтересуйтесь их текущими процессами разработки. Но имейте в виду, что такие вопросы могут привести к негативной реакции (никто не любит признавать, что они (или их компания) виноваты).
Ну, я чувствую необходимость вставить свои 2 цента.
Я не подпишу контракт, пока не:
Лучший способ достичь этого — заняться парным программированием со своими будущими коллегами в течение пары часов.
Я обычно уведомляю своих потенциальных работодателей об этом требовании в начале процесса собеседования, как правило, когда они спрашивают меня, есть ли у меня какие-либо вопросы. Именно в этот момент я говорю что-то вроде «Ну, это звучит здорово, и я заинтересован в продолжении процесса найма. Я должен сообщить вам, что я хочу (заполните краткое описание процесса здесь) до На самом деле я подписываю контракт, но я готов подождать, пока вы не будете уверены, что хотите меня нанять.
Я обычно упоминаю что-то вроде: «Я думаю, что это в наших интересах, если мы убедимся, что мы действительно подходим друг другу». Большинство компаний согласны.
Когда я нахожусь на стороне забора, я нахожу это разумным. Мой опыт показывает, что мои интервьюеры, как правило, ценят это. Те, которые не работают, вероятно, работают в среде, которую я хочу избежать. Потратить несколько часов на то, чтобы кандидат, которого вы хотите нанять, убедиться, что он хорошо интегрируется в вашу компанию, прежде чем нанимать, — это высокая отдача от инвестиций , и мне не нравится работать в компаниях, которые не вкладывают такие небольшие суммы в создание хорошей команды. .
Я не думаю, что сотрудники, с которыми компания могла бы позволить вам связаться, будут иметь большую ценность. Поскольку они не будут давать вам контакты всех сотрудников, они выберут группу счастливых и дружелюбных сотрудников, которые дадут вам точно такие же отзывы, которые вы получили от рекрутеров. Вам лучше довериться рекрутеру в этом вопросе, так как слишком легко «обыграть» этот вопрос.
С другой стороны, запрос о процессе и некоторых некритических образцах кода, созданных или поддерживаемых компанией, является вполне разумным запросом, если вы не просите, чтобы они переслали его вам или попросили уйти с ним. Я вижу, что этот вопрос поднимается в конце собеседования, когда рекрутер спрашивает, есть ли у вас какие-либо вопросы.
Я всегда хотел посмотреть на код, прежде чем начать. Но на месте вы можете спросить конкретно над чем вы будете работать, как настроена среда разработки и над каким непосредственным модулем вы будете работать и какие зависимости, технологии и где в SDLC текущий проект, а также если что n-уровневая архитектура, какие модули, спрашивайте, к чему у вас НЕТ доступа, где документация и т.д.
Что касается рекомендаций при трудоустройстве, я сделал это бесплатно, используя LinkedIn, вы можете найти людей, которые работают где-то еще, но раньше работали в рассматриваемой компании. По моему опыту, мои отзывы о LinkedIn, люди сказали, что хотели бы, чтобы они это сделали (спросите бывших работодателей в LinkedIn), и дали мне много информации, которую я не получил бы на Glassdoor или действительно
Я считаю, что на каждом собеседовании при приеме на работу становится очевидным, кто инициирует потенциальную сделку. Вы дефицитный товар, или вы стремитесь? Способности писать коммерческий код очень редки, так как это требует уровня концентрации, которого нет у многих помешанных на играх молодых людей. Следовательно, компания в большинстве случаев должна продавать себя вам. Я бы изменил ваш запрос, задав вопросы интервьюеру, чтобы оценить его или ее способности кодировать, а не просить показать часть кода компании. Если вы просите показать фрагменты, это говорит о том, что вы, возможно, ищете руководство для своих собственных ответов, тогда как просьба к интервьюеру закодировать для вас предполагает, что вы не хотите работать на дураков, правильное отношение.
Компании, специализирующиеся на выпуске программного обеспечения с открытым исходным кодом, обычно более открыты для этого.
Такие компании, ориентированные на открытый исходный код, предложили мне позвонить членам команды, чтобы обсудить их мнение о работе. Это мой ограниченный опыт, но похоже, что открытость — это культура, и обычно это означает, что компания не боится откровенных разговоров своих сотрудников о рабочем месте.
Как человек, который (за кофф-кофф... несколько десятилетий...) "опросил" множество "кодеров", позвольте мне теперь очень прямо сказать вам следующее:
«Мне плевать *на ваш исходный код!»
Если вы действительно пришли ко мне на собеседование, то я уже исхожу из того, что «вы технически компетентны». (Поэтому я ожидаю, что вы каким-то образом «приземлитесь на четыре лапы».) Итак, чего я хочу? Одна вещь:
«Когда вам представили техническое требование (которое, конечно, вызвало у вас рвоту...) , что вы сделали?»
Я очень сосредоточен на социальных вещах. Будете ли вы хорошо интегрироваться в любую из моих существующих команд или просто создадите проблемы? Будете ли вы "закапываться в окопы и помогать нам", не жалуясь (много...), или вы просто будете "резать и бежать"?
"Да, у меня есть деловая потребность нанять вас!" Но — «Вы тот человек, которого я хочу нанять?» 🤷♂️
Йонас Прем
Человек в маске