Comments 43
Никогда не берите тестовое задание, решение которого требует от вас времени больше, чем один-два вечера.Абсолютно согласен. Иногда слагается мнение, что заказчик такой нищеброд, что выведет это в прод. Ему же это ничего не стоит.
Тогда пожалуйста скажите, что такое анонимная функция и отличия const от let.Очень простые вопросы, даже обидно для Senior, it's not serious.
Джуны это должны понимать.
Иногда слагается мнение, что заказчик такой нищеброд, что выведет это в прод.
Интересно. Судя по ответу, вы довольно часто сталкиваетесь с тестовыми заданиями на неделю или две? Это реально распространено? А в какой среде-области? Мне просто ни разу не приходилось с таким сталкиваться и я, если честно, уверен, то это какая-то байка. Нет? Вернее, пару раз от момента когда я увидел задание и до момента, когда отослал результат проходила и неделя и больше (и один такой случай закончился удачным офером), но дело там было не в объёме работы, а в том, что область была та, где я до этого вообще ни в зуб ногой (вообще, у меня это почти всегда так получается — нафига переходить на другую работу, чтобы делать там то же самое, что на предыдущей?). То есть я неделю по вечерам разбирался в новой для себя технологии, потом за часа за три сделал задание. Но чтобы прям неделю плотной работы — ну, нафиг, конечно.
Очень простые вопросы, даже обидно для Senior, it's not serious.
Это фигня, я там дальше чаем подавился (два раза — второй раз но слове сИмафоры :) ), — "Невообразимый бред спрашивать .net разраба о том, что такое мьютексы и симафоры?" — Не, я тоже нифига не помню в чём там разница, но почему это невообразимые бред? Вопрос, как вопрос :). Кстати, с точки зрения претендента очень полезно перед собеседованиями прям взять посидеть и прокачать знания по многопоточности до довольно глубоких глубин. Пригодится или нет — бабка надвое сказала (во всяком случае, небесполезно при поиске косяков, даже если сам не пишешь конкарент код), но на собеседовании даже если дойти всего лишь до уровня модели памяти и happens-before — это производит глубокое и очень положительное впечатление на интервьюеров :).
Второе место, где это же надо знать это gamedev back-end, но это более редкая работа, чем веб-программирование.
А SemaphoreSlim в доднете вообще самый простой способ организовать очередь к одному ресурсу. Он же является аналогом MutexSlim. Его надо знать.
А теперь вопрос. На кой хрен об этом спрашивать, когда есть более актуальные и важные вещи?
Как показывает практика, проецируя на математику:
На собеседовании тебя спрашивают доказательство теоремы Ферма, а когда тебя наняли ты решаешь максимум квадратные уравнения.
Давайте уже быть реалистами, нет смысла спрашивать то, что используется максимум раз в никогда
И человек нанимает людей со знаниями подобными своим.
Но для личного роста и команды надо нанимать разных людей, включая более опытных чем сам.
btw. хороший математик в команде лишним не будет т.к. у некоторых задач помимо решения «в лоб» есть и математическое решение.
Нанимать надо тех, кто справится с задачей, а не тех за счет кого «я буду развиваться» — это паразитизм на рынке труда в чистом виде.
btw. Для решений квадратных уравнений — нужно уметь решать квадратные уравнения, а не доказывать теорему Ферма или Коши. Акстись дружище
Тогда пожалуйста скажите, что такое анонимная функция и отличия const от let.
const — это была ошибка введённая в спецификацию языка. const не нужен.
Нужен только и только let
Но чтобы это понять, не хватит знаний и Senior.
Мне еще не известен ни один случай, чтобы человек, который неделю делал тестовое задание и получил хороший оффер.
У меня так было. Работаю уже год, всё нравится. Да и то, что собеседования не было от слова совсем — считаю плюсом.
У меня так было. Работаю уже год, всё нравится
Я так получил свою первую работу. Технологиями, используемыми в конторе я не владел совсем. Мы договорились, если я сделаю простой проект, то видимо имеет смысл со мной сотрудничать. Ну вот где-то неделю я его и ковырял. Сейчас я понимаю, что разработчик с опытом сделал бы его за вечер, ну в крайнем случае за день.
Если есть желание устроится на должность с зарплатой на пределе своих возможностей, уже пройдено несколько собеседований хотя бы по часу, то почему нет?
Ведь хотя рассылка тестовых заданий для конторы и ерунда, но проверка их уже требует времени программиста из компании.
Да и цена найма для конторы, особенно если она хайрит через посредников, это 1-3 месячную зарплата посредникам и еще в такие же деньги ей увольнение обойдется в случае ошибки с наймом.
Более того, чаще всего — если собеседование ведёт один технический специалист, то это идеальные шансы на успех. Если их уже двое или трое (а иногда и больше) — это плохо. Угодить сразу всем — очень сложно.
Вот не соглашусь. Кмк двое — идеальный вариант. Моральное давление на кандидата минимально (но больше, конечно, чем когда 1х1), а для интервьюеров оно вообще как парное программирование работает — один спрашивает, другой слушает, потом меняются. Создаётся более полное впечатление о кандидате.
К тому же, почему один человек не в состоянии оценить вашу компетенцию?
Ровно вот поэтому
Каждый опытный разработчик обладает знаниями, которыми не обладает другой точно такой же разработчик, в том же стеке, на том же языке, на тех же фреймворках.
У меня в последнее время были два интервюера. Skilled mate, по делам.
Team Lead просто смотрит на первую часть сосеседования, добавляет свои вопросы в конце. Чувствовал себя на таком собеседовании нормально. Не было вопросов, на которые не мог бы ответить.
Часто в начале собеседования ещё HR всплывает, но потом сливается почему-то, в процессе.
Прокомментирую как человек, проводящий по 1-2 интервью в неделю в Google. Передо мной, как интервьюером, стоит ровно одна задача — понять, хочу я нанять этого человека, или нет. Не хорошо ли он знает <ЯЗЫК> или ещё что-то, не умнее ли он меня, не (даже) решил ли он задачу — а нанимать или нет. По комплексу факторов. И такая же задача стоит у всех собеседующих, думаю, во всех компаниях — нанимать или нет.
Соответственно, я буду вести интервью так, чтобы ответить на этот вопрос как для себя, так и для других людей, принимающих в итоге решение о найме. Других целей у меня на интервью нет. В частности, нет цели объяснить кандидату, что с ним не так (если не так). Рекрутер, конечно, потом что-то скажет (не знаю уж, что), но мне никто не ставит задачу объяснить причины отказа (тем более, что и решение принимаю не я).
Более того, у меня десятки других дел, требующих моего внимания, и мне уж точно не интересно заниматься доминированием или еще какими-то психологическими играми с людьми, которых я, скорее всего, вижу в первый и последний раз в жизни. Я почти всегда даю одну и ту же задачу, я хорошо знаю возможные решения, типичные проблемы, куда можно глубже копнуть, — процесс весьма оптимизирован. Это все равно по-своему интересно, и иногда получаются очень интересные разговоры, люди продолжают удивлять в хорошем и плохом смыслах, но вот чтобы как-то самоутверждаться за счет людей, которые и так в диком стрессе, а для меня это рутина, — увольте.
тем более, что и решение принимаю не я)
Нет ничего хуже, когда тебя интервьюирует и выбирает человек, который даже не будет с тобой потом работать
Уже после собеседования бывает team fit, когда говоришь с конкретными командами. Интервью — это конвейер…
Как вообще можно выбирать человека в команду, не дав пообщаться с тимлидом команды?В духе западной толерантности.
В рамках которой для найма человека должны учитываться только его умения в контексте исполняемых обязанностей. Поэтому в резюме кандидата которое ляжет на стол принимающего решение может не быть фото, данных о расе, поле, возрасте и так далее.
Подразумевается, что личное общение с непосредственно командой может отвергнуть достойного кандидата из-за каких-то личных bias, поэтому люди общающиеся с кандидатом зачастую специально выбираются из тех, кто не будет с этим кандидатом работать в дальнейшем. Это может быть и тимлид разумеется, но из другой команды, например.
Явление пока не массовое да и имеет забавный обратный ход, когда расу и пол как раз начинают указывать и учитывать, потому что когда их не учитывали и брали только по проф. навыкам, то на некоторых должностях внезапно не оказывалось представителей некоторых классов в принципе, хотя по стандарту должно быть 10-25-50%.
При этом если на западе человеку откажут в найме на работу по причине «не понравился тимлиду» (субъективно, без объективных профессиональных фэилов кандидата), то конторе очень повезет, если она просто сможет откупиться за это деньгами, а не потеряет репутацию «расистов, сексистов, гомофобов» или еще какую-нибудь там.
Человека сперва оценивают вообще, брать или не брать на должность инженера или ещё кого-то, а уже потом он общается с командой. То есть до команды доходят только те люди, которые фильтр уже прошли.
Передо мной, как интервьюером, стоит ровно одна задача — понять, хочу я нанять этого человека, или нет. Не хорошо ли он знает <ЯЗЫК> или ещё что-то, не умнее ли он меня, не (даже) решил ли он задачу — а нанимать или нет. По комплексу факторов. И такая же задача стоит у всех собеседующих, думаю, во всех компаниях — нанимать или нет.
В этом и состоит проблема вопросов на «абстрактных» собеседованиях.
Человек, который собеседует для найма человека в СВОЮ команду примерно представляет, что ему надо, хотя, скорее всего, далеко не с первого раза.
Собеседующий «от компании вообще» должен захотеть взять человека. Почему он захочет или нет — это вопросы его внутреннего мироощущения. Да, может быть обратная связь с командой, куда чела таки потом взяли, но степень её влияния — неизвеста никому, т.к. та команда не знала, по каким признакам не прошли остальные, и видит только некий готовый результат, который можно потом интерпретировать в усиление фильтра.
Понятно, что задача собеседующего — отфильтровать входящий поток. Но говорить, что он это делает правильно либо оптимально — невозможно.
Если бы было универсальное решение данной проблемы — не было до сих пор актуальной нужды в испытательном сроке.
При этом не фильтровать входящий поток — невозможно, т.к. это несравнимо дороже, чем фильтровать по результатам испытательного срока.
Вы во-многом правы, плюс добавьте к этому, что для крупных компаний на средние и высокие должности испытательный срок должен занимать годы (только освоение внутренних технологий на достаточном уровне может занять 6-12 месяцев), что лишает его всякого смысла. Поэтому испытательный срок и применяется не так уж часто.
Да, это игра в угадайку — попытка предсказать будущую производительность человека по очень слабым исходным данным. Но другого способа-то и нет.
Да, это игра в угадайку — попытка предсказать будущую производительность человека по очень слабым исходным данным. Но другого способа-то и нет.
Проблема не в способе (другого действительно пока не придумали), а в подходе.
«Профессиональный технический собеседующий» против «команды, подбирающей себе коллегу под требуемый спектр задач».
Я такой же профессиональный собеседующий, как любой другой инженер :) Это общественная нагрузка такая — собеседования. Каждый сколько-то проводит. Просто так нагрузка масштабируется, каждый по чуть-чуть делает, в итоге процесс предсказуем. У меня вот в команде вакансий нет сейчас, я помогаю другим таким образом. А команды уже выбирают себе из тех, кто прошел через общий процесс.
Я такой же профессиональный собеседующий, как любой другой инженер :) Это общественная нагрузка такая — собеседования.
Как бы то ни было — по факту у Вас это часть профессиональных обязанностей.
Пока стоит задача — отфильтровать входящий поток до некоторого количественного минимума — это одно. И критерии отбора соответствуют этой задаче.
Когда же изначально стоит задача найти человека, подходящего на конкретную должность в конкретной команде — то и критерии отбора, в общем, несколько другие.
Я вашу логику понимаю, но в больших компаниях это немного не так работает… Все приходящие новички — они на одно лицо, им надо учиться внутренним технологиям и практически всему. Именно поэтому такой акцент на элементарные задачи и "основы" — все, что выше — оно почти и не нужно. Ну то есть, для примера, питон, алгоритмы, навыки тестирования, проектирования, вот это все надо всем и всегда, а все остальное учить на месте.
Другими словами, в крупных компаниях настолько замкнутая своя техническая экосистема, что практически любой конкретный опыт кандидата нерелевантен. Нам не важно, какие вы знаете фреймворки — наших вы все равно не знаете.
Конечно, для уникальных вакансий или людей очень высокого уровня это не так — но их единицы. А рядовых инженеров набирают тысячами в месяц.
А если кто-то хочет себе в команду конкретные скиллы, то внешние кандидаты вообще не рассматриваются. Тогда надо внутри искать.
Ну, в общем, это свой мир.
Ну, в общем, это свой мир.
Тогда не стоит принципы отбора в крупных компаниях представлять как норму для всего IT-мира.
А разве кто-то представляет? Но эти крупные компании — они весьма значимый кусок индустрии, не менее значимый, чем маленькие фирмы или проекты, где реально нужны скиллы. Иными словами, на одном полюсе у нас абстрактные инженеры, умеющие программировать "на всем", на другом — специалисты с конкретными скиллами. Большая часть мира — она где-то между, как обычно.
Во многом согласен с автором. Трудоустройство это всегда сложно. У тебя нет работы и понимаешь что финансы тают каждый день приближаясь к отметке 0. Ты в чужом городе и/или в чужой стране. Ты участвуешь в собесе и в большинстве случаев ты уже не первый не десятый а примерно пятидесятый. То есть шансов получить офер у тебя что то в районе 2%. Ты попадаешь в руки hr которые неизвестно какое задание получили. И вообще оценивают на уровне нравится/не нравится. Потом если повезет, собес с техническим специалистом у которого сорвало крышу от того что он за два года вырос от треника, шарахающегося от своей тени до тимдида. И наконец если очень крупно повезет собес с СЕО-1 который делает или не делает офер в зависимости от комбинации тараканов в голове. Печально.
Заметки про интервью на разработчика