Как пройти собеседование по техническому тестированию, которое является абсурдным (например, неразумно большое задание с коротким сроком выполнения)?

Уходя от них.

GS (Goldman Sachs) однажды хотел маленький образец кода от меня, который спустился в симулятор биржевой книги заказов. Ничего особенного, ИСКЛЮЧИТЕЛЬНО они указали полное тестовое покрытие и КАЧЕСТВО КОДА ПРОИЗВОДИТЕЛЯ. Для того, что критично, он тянется до недели работы тестирования каждого края случае, потому что этот тип кода является чрезвычайно критичным.

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

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

Помните, что это IT - а IT - это рынок продавцов. Тонны рабочих мест - нет специалистов. Веди себя так. Не иметь дела с идиотами. Я отказываюсь от любой работы по кодированию без собеседований с ПРИОРОМ, потому что есть и другая сторона: Все эти “интересные, сложные” проекты - все равно одни и те же глупые, одни и те же снова и снова. Сначала я хочу знать, хочу ли я тратить своё время впустую, потому что мне нравится заниматься проектами, которые мне нравятся, а рекрутеры совершенно не знают, о каких проектах идет речь в наши дни.

Помните, когда компания проводит собеседование с вами, вы также интервью с ними.

Использовать бессмысленные тесты в качестве инструмента скрининга.

Если ТЕСТ дает вам необоснованные цели и сроки, угадайте, что вы можете ожидать на работе.

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

Опять же, это не вы, это они.

Проницательность 20/20. Вот что вы должны сказать в следующий раз:

“Как правило, я не делаю никаких домашних заданий на дом, если я не поговорю с клиентом первым.”

“Вы клиент? Нет, тогда соедините меня с менеджером по найму клиента. И нет, если вы работаете в HR (вы не клиент, если только не хотите, чтобы я построил приложение, связанное с HR).”

“Хорошо, что этот человек делает для вашей компании? Будет ли он тем человеком, которому я буду отчитываться в случае, если ваша компания возьмет меня на работу? Хорошо, да. Я хочу поговорить с этим человеком.”

Как только Вы наконец-то говорите с этим человеком, Вы говорите что-то вроде:

“Хорошо, Вы читали мое резюме? Как ты думаешь, мы можем пропустить весь этот проект?”

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

“Проблема в том, что меня уже сжигали раньше.

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

А в другой раз было небольшое несоответствие версий, и их ИТ-отдел не знал, как настроить конфигурационный файл, чтобы заставить мой проект работать”.

Но что бы вы ни делали, не давайте это объяснение рекрутеру. Не объясняйте и не оправдывайтесь перед рекрутером. Бесполезно пытаться объясниться привратнику. Чем больше информации вы даете привратнику, тем больше вероятность, что он будет использовать эту информацию против вас, так как по своей конструкции, привратник очень редко имеет право идти на уступки, но, с другой стороны, их роль больше о поиске причин, чтобы отсеять кандидатов.

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

“Хорошо, я готов сделать проект на дом, но я лучше буду там, когда мой проект будет установлен и оценен.

Как вы думаете, мы могли бы установить время, когда я мог бы прийти со своим кодом, и мы могли бы установить его вместе на одной из машин вашего разработчика? ”

“Как насчет этой предстоящей среды? […] Ты будешь там? Будет ли там и один из разработчиков? ”

Но опять же, делайте это, только если вы получаете хорошие флюиды от этого человека. Доверяй своим интуитивным чувствам. Если по какой-то причине вы чувствуете, что они используют этот проект как ленивый способ отсеять многие десятки претендентов. Или, если по какой-то причине, вы чувствуете, что они пытаются извлечь из вас какую-то свободную работу, чтобы они могли поставить её в производство, не соглашаются на домашнее задание.

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

И если по какой-то причине, вы не получаете такого уважения. Например, если они поменяли инженера, с которым вы должны были встретиться в последнюю минуту с сотрудником отдела кадров. Будьте вежливы, но будьте тверды. Не давай им свой проект. Скажи им, что ты будешь рад перенести собеседование и уйти.

Мне не нравится ссылаться на другие ответы в своих ответах, так как ответы должны быть понятны сами по себе. Тем не менее, главный проголосовавший ответ в основном сводится к “Компания - стая идиотов”. Беги от них". Это не даёт ОП ничего, что могло бы улучшить в себе, и ничего не изменить в будущем. Я вижу области, которые операционная система могла бы улучшить, независимо от того, сделала компания что-то неправильное или нет, чего мы, как ответчики, на самом деле не знаем, так как слышали только одну сторону истории.

Насколько я вижу, вы не общались до того, как начали задание, которое, по вашему твердому убеждению, не могло быть выполнено за два часа.

Вот последовательность событий, как я ее вижу:

1. Вас попросили выполнить задачу по кодированию

2. Когда вы получили вызов, вместо того, чтобы сообщить о своих проблемах, вы начали кодировать

3. Вы поспешили с вызовом, срезая углы

4. Вы представили низкокачественный проект, который не работал без большого количества скрипок

5. После получения обратной связи, вы начали оправдывать свою работу

Вот как я представляю себе компанию, которая это видела:

1. Кандидат принял все условия конкурса
2. Кандидат представил проект в срок
3. Проект не сработал
4. Наш ведущий разработчик сказал, что код был очень плохого качества
5. Кандидат начал оправдываться за свою работу

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

Я не могу подчеркнуть, насколько важно, чтобы обе стороны имеют общее понимание ситуации. У вас был непреодолимый пробел в понимании, потому что вы упустили возможность обратиться к нему. В следующий раз, когда у Вас возникнет проблема, сразу же сообщите об этом, или другая сторона подумает, что все в порядке! Не сообщать важную информацию - значит лгать по пропуску, а любая форма лжи - непрофессиональна. Как они реагируют на информацию - это их ответственность, а не ваша.

Я рекомендую прочитать The Clean Coder: Кодекс поведения профессиональных программистов Роберта С. Мартина (дядя Боб), в частности:

• Глава 2: Говоря нет
• Глава 3: Говоря да
• Глава 10: Оценка
• Глава 11: Давление

Если компания отклоняет ваше заявление из-за того, что вы просили обратной связи и уточнения перед началом работы, они не отфильтровали вас, you отфильтровали them как компанию, в которой вы не хотите работать.

Я столкнулся с некоторыми умными и глупыми тестами (SQL/BI) и активно вышел из одного, который был глупым, объясняя, что они хотели неправильный подход.

Я также видел тесты, которые на самом деле были попытками свободного проекта, с “примерами работы”, которые по сути были новым решением. Опять же, я отказался их выполнять.

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

Или они не знают, что делают, тогда вы много узнаете о компании, или они хотят видеть, что вы не тратите время (деньги компании) на плохие поступки вместо того, чтобы разговаривать с человеком без технических знаний, чтобы судить об этом.

Есть два результата, вы проходите с блеском за то, что делаете правильные вещи, или вы уклонились от пули и не должны возвращаться в течение двух месяцев, рассказывая нам, как ваш босс требует невозможные вещи ;)

Вот мой подход:

1. Общайтесь со своим контактным лицом в компании, что вы не думаете, что это возможно в то время, и что вы планируете на самом деле делать.

2. Если есть время подождать ответа, подождите; если нет, делайте то, что хотели, и подробно задокументируйте свой выбор

3. Обратите внимание, что очень немногие интервьюеры на самом деле калибруют и проверяют, что задание занимает 2 часа. Если вы действительно хотите работу, довести ее до определенного уровня полноты в заданное количество времени.

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

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

1. раздражается и уходит или
2. тот, кто молча пытается разобраться в этом или вы
3. на самом деле пытаются спорить и объяснять с руководством, что вещи являются необоснованными или
4. так напрягаться, что вы не знаете, что делать или
5. вы тот, кто делает вид, что пытается разобраться в этом, но дать столь же абсурдные результаты обратно, потому что это именно то, что кто-то придумывает такое задание будет заслуживающим?

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

Прошу прощения, но вы упускаете суть.

Подумайте об этом с точки зрения команды. Им нужен кто-то, кто знаком со всеми ASP.NET, MVC, REST, разговаривает с базой данных, и умеренно продвинутой функцией одного автозавершенного текстового поля.

Могут ли I сделать эти вещи? Да, в конце концов. В конце концов, я слышал _все эти вещи, так что я могу пойти вперед и перечислить их в своем резюме. Такой эксперт, как вы, будет в состоянии проложить провода вместе рабочей системы в течение срока, потому что вы имеете дело с этим стеком все время, но мне придется потратить часы, копаясь в руководствах.

Резюме является куском бумаги, где перечисление пулевые точки является тривиальным. Плохая аренда - это хуже, чем нет. Я предполагаю, что у Вас не было личной рекомендации от кого-то из команды, поэтому менеджер по найму ищет демонстрацию компетентности. Правда, настоящая система, готовая к производству, заняла бы гораздо больше времени, но тест не требовал готовности к производству, потому что спрашивал, что бы ты сделал с большим запасом времени. Успех теста показывает, что вы свободно владеете всеми слоями и, что более важно, что вы знаете, как расставить приоритеты. Заставьте его работать и then сделайте его красивым!

Двухчасовой тест не время для астронавтики архитектуры.

Более того, вы почти наверняка не первый кандидат, чтобы увидеть этот тест. Команда использовала и, возможно, несколько раз подправила свой фильтр, и хотя бы один разработчик прошел. Заворачивание носа - как это стало очень модно в последние годы - в праведном негодовании или “просвещении” их, почему это плохой тест, по их мнению, поместит вас в категорию bozo. Они подумают, что нам не придется иметь дело с другим прокрастинатором или примадонной. Как с этим справиться? Посмотрите на это с точки зрения вашего потенциального клиента. Вместо того, чтобы увольнять как абсурд, дай волю сомнениям. Для двухчасового теста кратко запишите свои предположения, сделайте дело солнечного дня для простой демонстрационной работы, а за оставшееся время документа, как бы вы сделали реальную систему надежной.

Так как другие ответы хотя бы намекнули, мотивация теста _c может быть разумной, особенно если тест:

1. хорошо соответствует требованиям actual job requirements;
2. Минимизирует менее важные элементы;
3. Очевидно, что это не попытка получить “бесплатную работу”; и, возможно,
4. Приходит хотя бы с некоторыми подсказками о том, что “ищут” рецензенты.

На предыдущей работе я спроектировал и администрировал спорно-“абсурдный” тест по программированию. Работа всегда была работой разработчика ASP.NET/SQL Server с полным стеком, а задача заключалась в создании очень простого веб-приложения, включающего одну страницу и две или три простые хранимые процедуры. Кандидат выполнял тест на месте, используя стандартные инструменты:

1. Visual Studio (версия по выбору кандидата в последних двух или трёх версиях);
2. SQL Server Management Studio;
3. Веб-браузер, не только для тестирования, но и для поиска документации, ресурсов и т.д.., Я предоставил кандидату базовое решение “оболочки” (в каждой из разрешенных версий Visual Studio), и заранее создал базу данных и таблицы.

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

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

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

1. Мы хотели убедиться, что кандидат хоть наполовину понял требования к работе. Помните, это было для должности высокого уровня. (Более половины времени ответ был “нет”)
2. Кандидат должен был уметь анализировать основные требования и разбивать их на управляемые, дискретные задачи.
3. Продление теста в течение часа заняло бы больше времени кандидата, не давая нам много дополнительной информации, если таковая имеется.

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

Если бы у кандидата было бегущее решение, которое бы справилось с предполагаемой частью общей задачи, кандидат почти наверняка бы прошел эту фазу собеседования. Даже если решение еще не было принято, если бы мы могли видеть значительный прогресс и доказательства компетентности кандидата, мы бы все равно, как правило, рассматривали бы кандидата. Мы всегда проверяли историю браузера кандидата, чтобы узнать, к каким ресурсам он обращался.

Причины, по которым фактические кандидаты не преуспели:

1. Буквально ничего не производит после целого часа. Мне грустно говорить, что такая ситуация происходила несколько раз.

2. Плагиатируя код с текущей работы кандидата и пытаясь (и не в состоянии), чтобы изменить его в соответствии с требованиями теста. Когда мы подозревали это, история браузера выдавала его.

3. Невозможность сформировать строку соединения для подключения приложения к базе данных. Это может показаться немного несправедливым, но помните, что мы искали кандидатов старшего уровня, включая опыт разработки SQL Server старшего уровня. Мы, конечно, didn’t ожидали, что кандидат вспомнит, как построить строку соединения, но мы did ожидали, что кандидат сможет быстро ее найти. ConnectionStringBuilder также было бы абсолютно нормально, но никто никогда ее не использовал. Самый первый пример из https://www.connectionstrings.com/sql-server/ сработал бы просто отлично.

Была еще одна часть интервью с менеджером и командой разработчиков вместе, и мы задавали вопросы о решении кандидата, как она подошла бы к остальной части проекта, и т.д.

В общем, я советую рассмотреть мотивацию работодателя на “абсурдный” тест перед тем, как увольнять его с работы.

В этом ответе не говорится о том, являются ли такие тесты хорошими или нет (или же я потворствую им), но основное внимание уделяется конкретному вопросу _

Как я могу решить, должен ли я проходить технические тесты, которые я считаю абсурдными (е). Например, неразумно большую задачу с коротким сроком выполнения) в будущем?

• Как вы бы поступили в реальном мире:

• Сообщите, сколько времени задача займет разумно.

• Изложите свой план того, что делать в данное время (то есть, делать меньше, или делать хуже, или и то, и другое).

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

• Четко документируйте, где вы срезаете углы, каковы последствия, и каков результат TODO.

• Все это очень поможет мне, как работодателю или клиенту, судить, хочу ли я работать с вами.

• В зависимости от структуры управления работодателя/клиента, парень, нанимающий вас (т.е. ваш непосредственный начальник/клиент), вполне может оказаться в таком положении, когда он не сможет влиять на то, какую работу вы получите. Матричное управление действительно существует… в этом случае я бы предпочел иметь кого-то, кто может справиться с такими ситуациями с изяществом, а не героя, который поставляет самый большой код всех времен, но не способен сообщать о границах времени/качества.

Точная мера того, стоит ли идти на большее качество или на большее содержание, зависит от того, что вы делаете. Например, в вашем случае, вы, вероятно, будете больше заинтересованы в том, чтобы они увидели, что вы можете предоставить качественную работу. Таким образом, вы можете вырезать несколько функций (используя какой-нибудь плейсхолдер и т.д.), но при этом сохранить качество кода на высоком уровне. Точно так же, если бы работа была, скажем, связана с безопасностью, вы бы сделали то же самое. Но если это абсолютно некритичное доказательство концепции чего-то, то можно больше двигаться в другом направлении. Задокументируйте все это (лаконично), и вы уже в пути.

PS: Мне нравится избегать “безумных или плохих” суждений. Т.е. вас не должно волновать, является ли клиент просто сумасшедшим, или он хочет вас вытащить (т.е. вы выполняете работу бесплатно), только судя по размеру задачи. реальное количество, которое имеет значение для вас - это ваше время, и что было зафиксировано. До тех пор, пока вы не против инвестировать эти два часа в потенциального нового клиента, не имеет значения, легко ли выполнить задание, или это работа под высоким давлением, или просто два часа светской беседы в их офисе.

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

Вы являетесь продавцом на рынке труда, и это ваша ответственность, чтобы разместить покупателей как можно больше. У вас мало возможностей для ведения переговоров, за исключением того, что вы претендуете на другую должность. Конечно, тест на программирование, что all кандидаты должны будут сделать, не является неразумным, независимо от того, можете ли вы на самом деле конкурировать с ним или нет. Если вы обладаете высокой квалификацией, но не можете пройти тест, другие кандидаты также не смогут его пройти. Так в чем проблема?

Вы стараетесь изо всех сил. Злишься, что тебе не предложили эту должность? Компания должна нанять кого-то, так что кто-то другой мог бы сделать работу лучше. Смысл невозможного теста по программированию в том, чтобы найти кандидата с лучшими результатами. Ли лучший кандидат завершить упражнение не имеет значения.

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

Вы должны чувствовать себя комфортно для любого технического теста, если вы думаете, что у вас есть навыки для этой работы, и все другие кандидаты должны были бы сделать это. Никогда не делайте безумный тест, если вы верите, что это попытка бесплатного программирования или / или дается вам из-за предвзятости (например, расизм).

PS: Я никогда не упоминал, что OP не является “достаточно хорошо”. @TessellatingHeckler