Pull to refresh

Comments 43

Никогда не берите тестовое задание, решение которого требует от вас времени больше, чем один-два вечера.
Абсолютно согласен. Иногда слагается мнение, что заказчик такой нищеброд, что выведет это в прод. Ему же это ничего не стоит.
Тогда пожалуйста скажите, что такое анонимная функция и отличия const от let.
Очень простые вопросы, даже обидно для Senior, it's not serious.

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

Интересно. Судя по ответу, вы довольно часто сталкиваетесь с тестовыми заданиями на неделю или две? Это реально распространено? А в какой среде-области? Мне просто ни разу не приходилось с таким сталкиваться и я, если честно, уверен, то это какая-то байка. Нет? Вернее, пару раз от момента когда я увидел задание и до момента, когда отослал результат проходила и неделя и больше (и один такой случай закончился удачным офером), но дело там было не в объёме работы, а в том, что область была та, где я до этого вообще ни в зуб ногой (вообще, у меня это почти всегда так получается — нафига переходить на другую работу, чтобы делать там то же самое, что на предыдущей?). То есть я неделю по вечерам разбирался в новой для себя технологии, потом за часа за три сделал задание. Но чтобы прям неделю плотной работы — ну, нафиг, конечно.


Очень простые вопросы, даже обидно для Senior, it's not serious.

Это фигня, я там дальше чаем подавился (два раза — второй раз но слове сИмафоры :) ), — "Невообразимый бред спрашивать .net разраба о том, что такое мьютексы и симафоры?" — Не, я тоже нифига не помню в чём там разница, но почему это невообразимые бред? Вопрос, как вопрос :). Кстати, с точки зрения претендента очень полезно перед собеседованиями прям взять посидеть и прокачать знания по многопоточности до довольно глубоких глубин. Пригодится или нет — бабка надвое сказала (во всяком случае, небесполезно при поиске косяков, даже если сам не пишешь конкарент код), но на собеседовании даже если дойти всего лишь до уровня модели памяти и happens-before — это производит глубокое и очень положительное впечатление на интервьюеров :).

Практика показывает, что вероятность использования Mutext\Semaphore на практике стремится к нулю (в веб разработке скорее всего именно 0). Тем более когда есть более человекоудобные решения, такие как TPL\lock.
Эээ, как раз в вебе конкуренции больше всего (из-за параллельности запросов), и часто требуется знать про lock-free и blocking алгоритмы доступа к ресурсам.
Второе место, где это же надо знать это gamedev back-end, но это более редкая работа, чем веб-программирование.

А SemaphoreSlim в доднете вообще самый простой способ организовать очередь к одному ресурсу. Он же является аналогом MutexSlim. Его надо знать.
за 8 лет, везде где я работал, никто не использовал это ни разу. (5+ разных энтерпрайс высоконагружнных проектов). И не знаю никого, ктобы использовал.

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

Как показывает практика, проецируя на математику:
На собеседовании тебя спрашивают доказательство теоремы Ферма, а когда тебя наняли ты решаешь максимум квадратные уравнения.

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

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

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-мира.

А разве кто-то представляет? Но эти крупные компании — они весьма значимый кусок индустрии, не менее значимый, чем маленькие фирмы или проекты, где реально нужны скиллы. Иными словами, на одном полюсе у нас абстрактные инженеры, умеющие программировать "на всем", на другом — специалисты с конкретными скиллами. Большая часть мира — она где-то между, как обычно.

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

Серебряной пули, как мы все знаем, нет… А так да, у всех цели разные, и интервью все проводят по-разному, и какие-то вопросы имеют смысл для одних сегментов, какие-то — для других. Что весьма очевидно, если вдуматься, но действительно явно не звучало.

Не совсем понял, .NET разработчики не пишут многопоточные программы?

Только их и пишут на самом деле

UFO just landed and posted this here

Во многом согласен с автором. Трудоустройство это всегда сложно. У тебя нет работы и понимаешь что финансы тают каждый день приближаясь к отметке 0. Ты в чужом городе и/или в чужой стране. Ты участвуешь в собесе и в большинстве случаев ты уже не первый не десятый а примерно пятидесятый. То есть шансов получить офер у тебя что то в районе 2%. Ты попадаешь в руки hr которые неизвестно какое задание получили. И вообще оценивают на уровне нравится/не нравится. Потом если повезет, собес с техническим специалистом у которого сорвало крышу от того что он за два года вырос от треника, шарахающегося от своей тени до тимдида. И наконец если очень крупно повезет собес с СЕО-1 который делает или не делает офер в зависимости от комбинации тараканов в голове. Печально.

Спросить .net разраба про механизмы синхронизации очень адекватное же, нет?
Если это не джун и не формошлеп — да, вполне.
Когда один «кот в мешке» дает «кота в мешке» другому «коту в мешке» — это тестовое задание.
Когда устраивался джуном и получил тестовое, то быстренько нашёл его решение на гитхабе, да и не одно. Сделал по своему, чтобы смог защитить, и был прав — спрашивали только по написанному коду, спрашивали, как можно иначе сделать и можно ли лучше. После тестового взяли, долго работал, всё было замечательно. Думаю, что джуну всё же лучше не разбрасываться тестовыми. Особенно сейчас, когда их значительно больше, чем 10 лет назад :)
да… Батенька. Я (15лет+ в Full stack, приватный предприниматель, абсолютно не разу ни использовал чужие библы и фреймы, вообще с ума сводит, в уме не укладывается… developer — ответственное лицо, выпускает продукт на фреймах) в последнее время, в силу обстоятельств, начал искать работу, получил похожий опыт, (эти рекетеры даже шапок в резюме не читают, типа внимание, только удаленка, пишу без фреймов, видят пример хороших результатов и начинают тебя долбить все в те места которые ты указал в контакте) короче для себя я все эти фрейм — сектантские общества сразу отсеиваю так: захожу на их сайт (который вроде как их лицо), но делаю тесты, смотрю реализацию и вижу жо.., пардон. Тут у меня и уже более менее правильное мнение о них складывается, и я не жалею… что я прошел мимо их (да пусть хоть миллион предлагают).
Можете дать один-два примера тестов и их интерпретации? Если правильно понимаю, то по этим тестам вы оцениваете качество сайта и, косвенно, компетенцию исполнителей.
Самые простые, открывайте Developer Tools, LightHouse, dom contentload, Load, network, Elements… технику рассказывать не буду, но там все на лицо, разберетесь быстро.
Sign up to leave a comment.

Articles