Собеседование с кандидатами на «плохие» проекты

Я действительно не знаю, существует ли такое понятие, как «плохой» проект как таковой... но, конечно, я могу понять, насколько сложно говорить с потенциальными новыми сотрудниками о проекте, который вы не находите всем. что весело делать. Есть, может быть, несколько способов, которыми я бы подошел к этому:

• Не «придумывайте» и не лгите о вещах. Нормально быть честным о том, как парни начинают. Если это ситуация «нам нравится проверять людей на этом, чтобы убедиться, что они в порядке, но если вы нам нравитесь, мы заставим вас заняться чем-то другим», я думаю, что это совершенно уместно сказать кому-то. Однако, если вы говорите кому-то неправду, в лучшем случае они будут плохо думать о вас, а не о компании, а в худшем случае вам придется снова и снова проходить собеседование на эту должность в через пару недель после увольнения.

• С другой стороны, не лезьте из кожи вон, чтобы очернить его. На это есть две причины: во-первых, боль в заднице одного человека — это возможность для другого. Кто знает, может быть, следующий человек, которого вы наймете, будет тем, кто посмотрит, например, на некоторые из этих старых технологий и убедит вашего клиента перейти на что-то новое. Или, знаете, может и нет, но нет никакого смысла, например, прямо разбрасываться этим. Другая причина заключается в том, что когда вы делитесь негативной информацией с людьми, они будут ассоциировать вас (и, в данном случае, вашу компанию по доверенности) с негативом. Просто так устроен человеческий разум, и это большая часть того, почему все плохо относятся к офисным сплетням.

• Работайте над этими мягкими навыками! Вы знаете, как агенты по недвижимости часто называют небольшой дом «уютным», а сломанный — «ремонтником»? Что ж, безусловно, есть положительные способы продать опыт. Хорошо, так что, может быть, эта работа не то, что вычто вы хотите сделать, но в зависимости от обстоятельств... например, акцент на обслуживании, а не на разработке, может быть представлен как отличная возможность для человека, плохо знакомого с S-Dev, но имеющего, например, опыт работы в области обеспечения качества или технической поддержки, чтобы оттачивать свои навыки, работая в установленных рамках. Если вы находитесь в офисе клиента и работаете бок о бок с ним, это может быть отличной ситуацией, чтобы научиться разговаривать с конечными пользователями и заинтересованными сторонами и понимать их (что, кстати, очень, очень полезно для любого программиста). ). Даже справляться с бюрократией — это навык, который можно отточить и который может быть очень и очень ценным в некоторых профессиях.

• Некоторые из этих вещей будут нарушать условия сделки, или, по крайней мере, должны быть. Извините, мне пришлось добавить это, потому что исходный пост был изменен. Я постараюсь сделать это как можно более неспецифическим для отрасли, но я должен сказать, что нетхорошее оправдание отсутствия контроля версий/исходников, и точка. Даже крошечный дом имеет доступ к Github. Если клиент не позволяет этого, клиент должен быть информирован о том, почему это необходимо. Поскольку это относится к вашей ситуации, это сложная ситуация. Если бы я обратился к вам, одна из вещей, о которых я определенно спросил бы, это ваш контроль версий. Если ты солгал мне об этом, я могу уйти в первый же день. Я бы почти наверняка ушел, если бы не нашел систему управления версиями и получил отказ, когда попытался реализовать какую-то его форму. Более младший разработчик может не «понимать» важность этого и поэтому может не спрашивать. Даже тогда, я не знаю, я сомневаюсь, должны ли вы чувствовать себя обязанными поднимать этот вопрос самостоятельно.

Честно говоря, все эти другие вещи являются рабочими вопросами. Мне приходилось иметь дело с медленными и тормозящими рабочими станциями, бюрократией, действовать как мой собственный БА, выяснять, что я должен делать по мере продвижения... на самом деле, все эти вещи, я чувствую, являются частью опыт разработки программного обеспечения. Работа без контроля версий невозможна или, по крайней мере, не должна быть (и я уверен, что в других отраслях есть подобные «неудачные» вещи).

Я бы ответил на этот вопрос, сказав что-то вроде этого:

«Есть несколько отличных проектов, над которыми вы могли бы работать в конечном итоге, но вам придется начать с некоторых из наших старых старых проектов. Они сложные, не такие новые разработки, но вы многому у них научитесь, и это будет отличный опыт. Я не могу сказать, как вам будет работать над ними, поскольку мы все разные, лично я не большой поклонник исправления ошибок и работы со старым кодом других людей, но я, по крайней мере, наслаждаюсь возможностью показать, как я мог бы улучшить код.Вам это может понравиться, а если нет, то через некоторое время вам все равно будет предоставлена ​​возможность изменить проекты.Что касается компании в целом, они замечательные, мне очень понравилось в них работать ."

Мне уже приходилось говорить что-то очень похожее претендентам раньше. Я не хочу им врать, но вы определенно можете «смягчить удар», так сказать.

Я не думаю, что вы должны откровенно лгать о компании, но в то же время, если вы довольны работой там, скажите об этом и просто меньше сосредотачивайтесь на проектах, над которыми они, вероятно, будут работать.

О лжи по бездействию

Если у меня есть только ограниченные возможности трудоустройства: я буду чувствовать себя недовольным и, в конце концов, уйду после того, как ваша компания вложит в меня много времени и денег.

Если у меня есть несколько вариантов трудоустройства: я уйду очень быстро и, вероятно, расскажу другим, кто спросит. Представитель вашей компании обязательно уволится, если HR будет делать сомнительные вещи (см.: HR usually omits that)

Отсутствие инструментов для работы (отсутствие контроля версий, медленные компьютеры)

Примерно так же, как указано выше. Ни один достойный разработчик не собирается задерживаться, если их рабочее место не облегчает их работу. Это все равно, что просить плотника забивать гвозди бананом. Единственная причина оставаться здесь — это отсутствие другого выхода.

На проектах, у которых есть «багаж»

Когда вы упоминаете проекты, в которых отсутствует документация, трудные клиенты, старые/устаревшие технологии, это проблемы, с которыми рано или поздно столкнется каждая крупная компания. Как интервьюируемый, я ожидаю, что вы упомянете об этом заранее, потому что как сотрудник я ожидаю, что у компании будет стратегия для решения этих проблем. Основная проблема здесь не в том, что вы не знаете, как рассказать интервьюируемым об этих проблемах, а в том, что у вашей компании, похоже, нет стратегии по устранению этих болевых точек просто потому, что она дает вам денежный поток. Это самодовольство в лучшем случае.

Как вы доносите реальность до интервьюируемых?

Мое предложение было бы быть честным. Если вы их наймете, они рано или поздно узнают правду. Сообщите им об этом сейчас, чтобы они могли принять взвешенное решение. Те, кто отчаянно нуждается в работе, все равно скажут «да», а те, кто нет, скажут «нет» (что дешевле, чем нанять их, а затем быстро уволить).

Как человек, привлекаемый для подобных проектов, я это вижу так:

• Убедитесь, что вы не лжете и не вводите в заблуждение. даже по упущению. Это заставит людей уйти, и быстро. Вероятно, не принеся много пользы компании, прежде чем они уйдут.

• Не возлагайте на людей ответственность за ошибки, которые, как вы не можете доказать, являются их и только их ошибками. И убедитесь, что они это знают. «В некоторых проектах не используется никакая система контроля версий, потому что клиент этого не разрешает». - это просто ужасно. Вы даже не можете использовать GIT для своей локальной копии кода? Если это так, многие разработчики развернутся и убегут. И это правильная реакция. Без контроля версий вы не знаете, действительно ли они виноваты, поэтому, если предполагается, что их продвижение, преимущества и т. д. зависят от ошибок, которые кто-то другой может внести в код, это просто несправедливо по отношению к ним. Поэтому убедитесь, что они знают, что этого не произойдет.

• Не устанавливайте жестких сроков для чего-либо, связанного с API, которые не задокументированы или могут быть изменены без предварительного уведомления. Опять же - убедитесь, что они это знают.

• Ведите переговоры со своими клиентами . Задержка нажатия клавиши является нарушителем соглашения. Вы не можете ожидать, что разработчик сосредоточится на своей работе, если у него нет даже технических средств для набора текста.

• Скажите им заранее, как долго они будут оставаться на плохом проекте. Я мог бы согласиться провести месяц, а то и три, работая в таких условиях. Может быть. Если бы денег было достаточно. Но я хотел бы быть уверен, когда это закончится.