Pull to refresh

Comments 93

Тут надо различать тестовые задания.
Тест на 1 час из небольших задач или тест из готового проекта часов на 8+.

Первый, я уверен, никто не против сделать, хотя бы для разминки.
Второй — это явно перебор.

Вот и вся история )

ЗЫ: а примеры из статьи лишь показывают адекватность собеседования. В первом случае оно было адекватное, во втором — кто то из участников явно был не в духе. Или собеседуемый психанул на пустом месте или собеседующий зачем то его хотел завалить.
Ничего про тестовые задания в примерах нет.
Я бы сказал, что хорошее тестовое должно обязательно быть максимально приближено к реальной работе — потому что «задачки» можно и на собеседовании выкатывать. И некоторые так и делают, и яростно отстаивают именно такой подход.

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

Но при всем при том я абсолютно согласен, что оно так же обязано быть достаточно недлинным. Лично я вот резко хуже отношусь к тестовым, которые по прикидкам займут больше времени, чем один подход на 2-3 часа. Если компания просит что-то более долгое — то только если она готова оплачивать потраченное на них время.
Я бы сказал, что хорошее тестовое должно обязательно быть максимально приближено к реальной работе


Поддержу.

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

Был случай, когда на тест дали небольшую «домашнюю тестовую задачку» по реальной тематике. Нужно было чуть дополнить и расширить функционал в имеющемся коде. Объем был небольшой — на полдня работы максимум. Но такое задание считаю вполне адекватным — тут сразу и владение нужным инструментарием и умение читать и понимать чужой код и оценка собственного кода.

А там, где работаю сейчас, никаких тестов не было. Просто посидели, поговорили. Чем занимался я, чем занимаются тут. Вполне адекватное общение получилось. И взаимноприятное.

В целом, к реальным тестам отношусь вполне нейтрально. К «олимпиадным» задачам и задачам из учебников — резко отрицательно. На собеседовании они скорее в минус тестирующему т.к. показывают его формализм в подходе и отсутствие интереса к соискателю
Ну, реальные задачи которые хоть что то бы проверяли всё равно сводятся к вполне конкретным постановкам и случаям, а если её ещё чуть-чуть доработать (убрав подсказывающие условия и обезличив данные) как раз и получаются обычные тестовые задания в пределах часа подумать, протестировать и написать.

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

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

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

ЗЫ: а что, когда теория пройдена и кандидат не может справится с простым тестовым заданием — это норм?)
Ну это если прям совсем нулевые кандидаты или никакого уважения к соискателям и работы толком и не проверяются. Потому что проверить сделанное задание, лично для меня, задача ощутимо сложнее чем потратить немного времени на разговор.

Мы только что приняли решение давать простенькое задание (~2 часа для человека с идеальным совпадением по квалификации) до первого собеседования с технарями (не HR). Когда мы его обсуждали было очень, очень трудно (придумать что-то такое, что легко сделать, но по чему будет хорошо видно что человек знает что делает). Придумали. В рамках разработки ТЗ я его сам решил, и даже обсудил с коллегами (у которых были альтернативные методы решения).


Первый же человек, который по резюме выглядел интересно написал там такого....


Если кому интересно, должность девопс/администратор — а задача была с помощью ансибл установить/настроить nginx (статика из одного файла в котором значение переменной), и написать к этому тесты.


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

Когда работаешь в компании, часто задачи это добавления функционала к существующему проекту, исправления, изменение его же.
Для тестового задания часто просят создать проект с нуля, сделать конфигурацию, деплой на сервер (если возможно) добавить много boilerplates (если используется фреймворк). Получается что основное время уходит на это. Поэтому когда пишут, что задание на 4 часа, по факту 4 часа это работа с кодом, и еще 4+ часов на настойку всего, что нужно для кода.
Конечно, есть рабочие проекты, где создание с нуля приложения это частая потребность (например продолжительность проекта до полгода и для нового заказчика снова с нуля), но таких не очень много, по моему опыту. А задания тестовые у всех примерно одинаковые. Вот поэтому и не нравятся они.
UFO just landed and posted this here
Ну теперь Вы поняли наверно, что тестовые это сплошной субьективизм и болезнь современного IT
UFO just landed and posted this here
В современном IT есть бешенный технологический темп.Современное IT это большой котел, который засасывает всех людей при этом желания людей их право участвовать или нет не принимаются в счет.Цель современного IT установить как можно больше цифровых связей и все.Человек тут как единица это нично.Вот в это 'ничто' Вас как человека и ставят все эти тестовые задания, которые забирают время Вашей жизни.При этом пока будут люди не способные сказать работодателям(от слова раб) сказать — «нет», процесс будет повторятся.Вам только кажется что вот мне просто интересно и я так и быть сделаю это тестовое.Обратите внимание на опрос(тут выше).Люди понимают что тестовые отнимают много времени и сил, но… продолжают соглашаться и тянут лямку как бурлаки на Волге.Все равно бесплатно делают задания.Понимание приходит только с опытом, если Вы смотрите на себя как на человека а не как раба или цифрового робота то Вы задумаетесь а зачем все это, почему так, почему мне недоверяют? При этом Вы понимаете что недоверяють никому.Почему так? Думает только человек — раб исполняет.Желаю Вам набираться опыта!
Задача была сделать карту с [...] экспортом в gpx [...].
[...] бортанули из-за того, что [...] gpx файл не проходил валидацию.

То есть, вас попросили сделать файл определенного формата, а вы сделали что-то другое, что, вероятнее всего, поломает половину консьюмеров — и у вас, как вы выразились, бомбит? Мило.

UFO just landed and posted this here
Если вы фронтэнд — то API (а выдача файла требуемого формата — это оно самое) бекэнда вам не указ, что ли?
UFO just landed and posted this here
Я посмотрел, и если бы я выставлял задание в том числе именно чтоб проверить, как кандидат умеет соблюдать контракты (не знаю, что у вас проверяла контора) — я бы вас зарубил именно на том, как вы генерируете файл — подход «конкатенация строки» вообще не масштабируется и провоцирует ошибки. Для искусственной «олимпиадной задачки» может и пойдет, но для задачи приближенной к боевой — это очень грустно.
UFO just landed and posted this here
Пардон, выходные пролетели незаметно.

Если вы генерируете xml — у вас есть варианты: например, написать XML Schema и проверять правильность вашего результата по ней (для задания «старайтесь не пользоваться сторонними библиотеками» этот вариант очевидно не очень зайдет — но в проде я бы рассматривал именно его). Или хотя бы генерировать xml из его же элементов, чтоб хотя бы исключить ситуации, когда вы тупо опечатались в тегах и из-за этого нарушили контракт. Еще лучше будет, если взять тайпскрипт, и его типами реализовать правила вложенности, что в чём может быть.

То есть, условно говоря, подход в духе —
class DocElement implements XmlElement {
  constructor(tag: string, children: XmlElement[]) {
    this.tag = tag;
    this.children = children;
  }

  toString(): string {
    const { tag, children } = this;
    const content = children.map(child => child.toString()).join('');
    return `<${tag}>${content}</${tag}>`;
  }
}

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

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

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


На очном сажаю кандидата за рабочее место, подключенное к одной из боевых систем, благо таковая и предназначена для работы в «демилитаризованной зоне». Есть только вектор/направление собеседования: исследовать окружение с текущими правами и в финале – «вырваться» в Интернет. Как мне кажется, таким способом «убиваю сразу нескольких зайцев».


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


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


Проголосовал за «нормальную практику».

Привет! Спасибо за классную историю. А у кандидатов какая реакция? Были, может, ситуации нестандартные?

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


Понимаю, что психотип кандидата — отменного исполнителя в реальном «бою» — я таким образом не раскрою, но и набираю я «бойцов» — экстравертов в «фронтовую разведку», так сказать. Поэтому мои технологии далеко не для всех и, тем более, не для software.


Был один казус, когда я спросил претендента: «а какой IP адрес на вашей машине?», на что получил искрометный ответ: «пожалуй, я пойду, т.к. на текущем месте работы я строю кластеры в федеральном масштабе, а вы меня про какие-то IP-адреса спрашиваете». То ли описание вакансии человек не прочитал или не понял, то ли...


А вот после окончания теста/собеседования практически все благодарили за интересность и уникальность формата вне зависимости от результата. Даже если мой вердикт, который я озвучиваю сразу, — отрицательный, многие просили «ответы», либо возможность подумать дома и прислать «решение» — просто для собственного удовлетворения. И да, начиная тест, я произношу сакраментальную фразу: «все, о чем я буду вас спрашивать или что попрошу сделать, можно реализовать и никаких подковырок в моих вопросах нет и быть не может».

За тестовые надо платить.Тогда появляется ответственность работодателя и возникает желание его сделать у претендента
Тогда появляется возможность дать тестовое всем своим друзьям, и деньги за него поделить пополам.
Тестовое — глупость.
Есть испытательный срок, который создан чтобы понять как человек работает.
Самое адекватное тестовое задание которое у меня было, выглядело так:
Пригласили на работу удаленно, дали задачу в проекте, установили на неё срок и оплату. По результату я либо выхожу работать дальше, либо заканчиваем сотрудничество.
По сути просто ограничили испытательный срок несколькими днями. Это адекватно. Увидели в бою квалификацию. Короткое тестовое не может выявить ничего, что не способно выявить нормальное собеседование, и используется только для того, чтобы тратить время соискателя, вместо времени собеседующих.

Вот именно, чтобы понять КАК человек работает. А тест помогает понять а может ли человек работать на этой позиции в принципе.

То есть человек уволился с предыдущей компании, перешел на новую должность и сразу через 3 дня вылетает с нее. По Вашему это будет честно по отношению к кандидату? Уж лучше подольше искать человека.
Так работает испытательный срок.
Возможность уволится и быть уволенным без объяснения причины в любой момент.
Да, это честно. Тем более это работает в обе стороны.
Ну, как бы, что бы начать испытательный срок надо уволиться с предыдущей работы.
А вернуться на неё вряд ли получится.

Не вижу как это работает в обе стороны. =)
Вы никогда не уходили во время испытательного срока? Рекомендую попробовать.
Зачем?
Что бы сидеть без работы?
Алименты и кредиты как то сложно платить когда нет денег.

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

ЗЫ: уходил. Но это была очень специфическая история.
Работу нельзя выбирать под давлением обстоятельств. Выбор получается весьма фиговеньким очень часто.
Тем более нет смысла идти туда откуда есть риск уйти через три дня или вообще на испытательном.

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

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

А вот так, увольняться с работы где тебе платили ради кота в мешке и прохождения «испытательного срока» вместо «собеседования» — нет, спасибо.

Короче, смысл был в том, что собеседоваться можно параллельно работе, а проходить испытательный срок — нет. Поэтому лучше собеседоваться, чем проходить испытательный срок )
Ну речь же не про отмену собеседования. А про тестовые задания.
Тестовые задания нужны в двух случаях:
1) Кандидат врёт(тут не тестовое задание нужно, а испытательный срок)
2) Нужно сэкономить время специалистов компании за счет кандидата(тут надо менять подход к найму)

Вот и получается, что тестовое задание не нужно.
Тестовые задания — это часть собеседования. Такая же бессмысленная или нет как и остальная его часть. И нужно для увеличения уверенности в том, что сотрудник подходит.

Если можно увеличить уверенность в том, что на новом рабочем месте всё будет хорошо — почему бы этого не сделать?

3. Нужно дополнительно убедиться что кандидат подходит.

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

Потому что сидеть без работы совсем не хочется.
Работодатель теряет время, а время — это деньги. Работодатель возлагает на кандидата определенные надежды и т.д. Мы же не говорим про гребцов на галеру, где один помер и фиг с ним, а у компании денег немеряно и времени вагон. Текучка кадров может быть только на низкооплачиваемых должностях.
Работодатель теряет столько же времени как и работник.
Вот только работник теряет стабильную работу и заработок который у него был, ради того что бы начать проходить «испытательный срок» тут. А работодатель в этом плане ничего не теряет — как была у него вакансия до, так и останется.

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

Так что риски несоизмеримы.

Работодатель обычно теряет больше времени на испытательный срок, чем работник.

ну работодателю это не так и критично, как работнику. =)

Работник получает за испытательный срок деньги.

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

ЗЫ: да и работник, в общем то, не сложа руки сидит в этом время и деньги им заработаны )
Вот как раз на испытательном сроке обычно платят больше чем работник зарабатывает, даже без учёта времени тех, кто его в курс дела вводит. Хорошо если к его концу выходит на операционную окупаемость.
UFO just landed and posted this here
VolCh бывает что больше, бывает что меньше. Зависит от работы, как водится.

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

В то же время работник:
1. Теряет работу которую имел и после ухода с испытательного срока остаётся в более плохом положении, чем был.
2. Без денег от работы одного работника у работника куда больше проблем чем у фирмы.

not_enough хочется верить, что больше чем платит ему )
> Сотрудника берут обычно на вакансию, а не на замену кому то, т.е. от того что человек уйдёт фирма вернётся к предыдущему состоянию, а не худшему чем было.

В моём мире куда чаще фирмы берут на замену, чем на расширение. Стараются перехлестнуть уходящего и приходящего сотрудника, но не всегда получается: я вот за 2+ месяца объявил о своём уходе, вчера первый день на новом месте, а человека, который хоть частично меня заменит по текущим задачам готовы брать уже за большие деньги, но не получается. Вернее одного ношли, но не прошёл и первого дня испытательного срока.

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

UFO just landed and posted this here

Чтобы выбрать себе работу по душе. А чтоб не переживать нужно иметь финансовую подушку.

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

А ещё лучше — иметь финансовую подушку и не тратить её когда можно её не тратить. И не сидеть безработным без необходимости. =)

ЗЫ: работу по душе можно выбирать и работая на работе которая не очень по душе, но которая кормит. Обычно — в этом и смысл )

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

Не соглашусь. Если речь идет о проекте среднего и более размера, то новому человеку обычно нужно как минимум несколько дней на «знакомство» с ним. Настройка окружения, скачивание и поднятие n-го количества репозиториев, получение кред для входа в различные сервисы — все это занимает намного больше времени чем тестовое. При чем как у потенциального сотрудника, так и у сторожил компании, которым приходится первое время многое объяснять\показывать\вводить в курс дела. Мне кажется, обоим сторонам намного легче, когда несколько сосискателей параллельно тратит пару часов своего времени на тестовое, чем контора тратит по пару дней\недель на каждого, чтобы в итоге уволить и попытаться взять другого. Также плюсом для компании является то, что можно оценить нескольких кандидатов в сравнении с друг другом. А брать сразу пару человек на испытательный срок с условием, что возьмут в итоге одного — еще более неуважительно к их и своему времени.
Если компания стабильно отсеивает соискателей после тестового/испытательного — ей надо серьезно подумать над тем, кто у неё этим занимается и гнать их в шею.
помню был на собеседовании в Veeam. Я не мог оценить свои навыки адекватно — ну не было на текущей работе ребят использующих тот же стек технологий. Я сам попросил тестовое задание. Оно было достаточно сложное — на пару недель, но оно позволило понять и ориентир работодателя и даже подковаться, где плавал. Это очень хороший опыт и сразу понимаешь «смогу или нет».
Получал тестовые и из других мест. Где-то брался и решал, где-то не мог. Тестовое — это неплохо, потому как обе стороны могут оценить адекватность друг друга. Например стал решать тестовое одной конторы — а там не понятны условия задачи. Пишу на почту, а там ответ «как поняли, так и делайте?». В другом месте — «да, Вы все правильно поняли. А тут мы ждем от Вас это и вот это». Уже об HR сразу что-то понятно. Однозначно тестовые нужны, особенно в мегаполисах и тем, кто собрался в них переезжать.
Тут есть все необходимое время. Ты не нервничаешь, как при человеке. Можешь оценить адекватность. Не надо никуда ехать. Сплошные плюсы. А решать или нет — дело личное, которое показывает — хочешь тут поработать или нет.
UFO just landed and posted this here
Считаю что тестовое задание это очень хорошо и правильно для соискателя. По заданию сразу видно с кем имеешь дело. Особенно хорошо когда прямо в объявлении о вакансии пишут, что «у нас нужно заполнить анкету, подождать пол часа в очереди и выполнить тестовое задание». Спасибо таким хырам.

Со стороны работодателя никогда не давал тестовых заданий. Это не порядочно.
UFO just landed and posted this here

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

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

Как вы относитесь к гитхабу соискателя, если там есть мягко говоря проекты не лучшего качества? Например, если я делаю тестовое задание — то стараюсь сделать это хорошо, но вот для себя бывает немного и халтурю. Например если я хочу проверить концепт и хочется что бы он был сохранён для обращения в будущем.
Что лучше в таком случае, сделать тестовое или всё же гитхаб? :)
Например свой гитахб github.com/Dzmitry1983 я бы своему работодателю не показал.
Как вы относитесь к гитхабу соискателя [...]

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


Выберите один проект, за который не стыдно — хоть тестовое из прошлой жизни, хоть свой домашний проект на Идрисе. А если такого нет — вот тут лучше, наверное, все-таки сделать задание :)

Вы забываете одну вещь — я откликаюсь или мне пишут не один человек. В итоге если, например, у меня 10 откликов и каждый требует решить свою задачу, то итого мне нужно будет в районе 10-20 часов на решение задач. Но не нужно забывать, что я еще работаю. В итоге ты сидишь и пашешь после работы не разгибаясь. Именно из-за этого и не люблю задачи.
Одно дело сделать одну задачу, даже пусть и на 5-6 часов, выложить её на гитхабе и пусть остальные смотрят и оценивают.
Но в процентах 90% я слышу только одно — вы все-таки решите нашу задачку. А чем ваша задача отличается от других? Вы особенные задачи даете? Или остальные дают тупые задачи, а вот ваша она одна единственная и неповторимая. Или вы можете оценить только свою задачу?
Ведь цель всех задач — посмотреть на ваш код, как вы мыслите.
Вы выбираете компанию. Если вам все равно где работать и что делать, то компании будет все равно кого искать, лишь бы работал. Рано или поздно придет человек, которому захочется работать именно в той компании, которая предложила задание и он сделает это задание. Это как экзамен в ВУЗ. Выбор есть у всех.
Основная часть компаний не известны. Известные конторы можно посчитать по пальцам. И мне можно сказать без разницы где работать. Узнать компанию можно только работая в ней. Естественно, если мне предложат в 2 раза больше моего предложения и скажут мы вас точно возьмем, то я буду делать. А так — делать и не знать возьмут меня или нет…
Я не Бил Гейтс, чтобы меня с руками отрывали.
UFO just landed and posted this here
michaael, поддержу Вас. Ответы на многие задачки могут выкладываться на гитхабе в публичном доступе(такая ситуация мне встречалась) — скачал и делать уже не нужно. Задачка должна быть уникальной, чтобы ее нельзя было склонировать или найти на других ресурсах, иначе смысла в тестовом задании нет.
Если хитрить то всегда можно найти человека который за N денег сделает за тебя задачу… А если в процессе выполнения тестового человек погуглит, найдет имеющиеся решения и подчерпнет оттуда интересные идеи — это скорее плюс.
Привет, очень интересная мысль — заберу ее в субботнюю трансляцию задать докладчикам, если вы не против?
Забирайте. Интересно будет услышать мнение других.
UFO just landed and posted this here
замечательный митап. спасибо ребята.
От себя добавлю, что лучше бы, чтобы в тестовом задании был заложен технологический стек, по которому будут гонять на собеседовании. Таким образом получится, что решил тестовое задание и теорию просто освежил в памяти, к собесу готов; а если видишь, что не по плечу — чего-то не знаю, то сразу книжку в руки и дотягиваться; ну, а если не сам решил, то смыла идти на собес вообще нет. В таком случае тестовое при любом раскладе будет решено не зря.

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

Вчера как раз был пример. Контора ноунейм, прежде чем с вами проводить собеседование, нужно делать ТЗ. Время выполнения — от 4 до 6 часов. Реально это означает в районе 10 часов. Т.е. я должна 10 часов потратить на ТЗ, при этом не зная какие у них процессы, как построена работа.
А так у меня был пример — пришла на собеседование, стали рассказывать что за проект и как работают и вот на этом этапе я поняла, что это не то, что мне нужно. Это хорошо, что не нужно было делать ТЗ. А так получилось бы зря потраченное время.
Я стараюсь даже на техсобес не соглашаться до того, как мне вакансию «продадут».

А я вообще не соглашаюсь ни на какие собеседования, кроме обеда с CTO; вон полный гитхаб кода, смотрите, если вы вдруг про меня каким-то окольным путем узнали.


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

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


Ну а так, многие хантинг начинают по схеме "1. есть интересная вакансия, дайте резюме 2. Теперь тествовое сделайте, и если нам понравится, то 4 уровня собеседований"

Мне лично подойдет любой код, на каком угодно языке (у нас недавно соискатель на Идрисе выпендрился, но ожидаемо не осилил все сделать как надо, причем на каком-нибудь Хаскеле, я думаю, сумел бы). Есть готовый — отлично; нет — не беда, вот вам ТЗ.


Но о чем можно спрашивать кандидата после ТЗ — я ХЗ :)


И так же все понятно. Либо теперь я очень хочу, чтобы мы работали вместе, и сделаю все, чтобы это стало обоюдным желанием, — либо зачем нам всем тратить зря время?

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


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


В общем "красных флагов" для вас нет, но и сказать "нужно брать, он тестовом уже порешал половину наших проблем на продакшене, к которым мы даже не знали с какой стороны подойти" вы не можете. Вы предложите мне ТЗ? А зачем мне его делать, если я про вашу компанию и конкретную позицию знаю только что-то вроде "лидеры рынка в узком сегменте, требуется работник работу работать, требования: куча абреввиатур, предлагаем деньги, отпуска и больничные", а другие хотя бы о компании расскажут без тестового, а может и офер сделают даже.

Ну раз уж вы меня спрашиваете — я от своего имени и отвечаю.


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


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


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


Очень, кстати, отрезвляющий, получился эксперимент.

Ну и так-то я про компанию и вакансию с удовольствием расскажу до всякого вообще кода — только спросите.

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

Как будто разные люди пишут. :) Бывает


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


И известность компании или проекта, глобальная или локальная, тут на… дцатом месте.


Я в своё время делал эксперимент такой: сделал ТЗ, дал ребятам из команды, посмотрел на результат — по нему я бы их отсеял до собеса. А так нормально работают.

Как будто разные люди пишут. :) Бывает

Я имел в виду «предметно разговаривать на технические темы, выяснять уровень компетенций». Потрещать про то, как у нас круто — меня уговаривать не нужно.


хочется узнать, а хочется ли мне попасть на конкретную позицию, [+++]

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


сделал ТЗ, дал ребятам из команды, посмотрел на результат — по нему я бы их отсеял до собеса. А так нормально работают.

Определите «нормально», пожалуйста. У нас те, кто приходит через ТЗ ко мне, все идут рано или поздно в mission critical. Во фронте, например, все гораздо лояльнее — там одной ошибкой контору разорить не удастся.

Я имел в виду «предметно разговаривать на технические темы, выяснять уровень компетенций». Потрещать про то, как у нас круто — меня уговаривать не нужно.

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


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

Считаю такое целенаправленное поведение на конференциях, митапах и т. п. неэтичным со своей стороны, даже когда активно ищу работу.


Определите «нормально», пожалуйста.

Не разоряют контору :) В том числе при работе с автоматическими исходящими безнал переводами. В целом сделал вывод, что плохой из меня составитель и/или анализатор ТЗ.

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

Разумеется. Это нам в первую очередь нужно, чтобы кандидат прямо хотел выполнить ТЗ вчера, а не соискателям, и я прекрасно это понимаю. Потому что если есть устремление — то и ТЗ будет совсем иначе сделано, с огоньком и ответственностью. Где-то тут, возможно, кстати, кроется причина невысоких результатов ваших коллег — люди не любят делать бессмысленные вещи.


Считаю такое целенаправленное поведение на конференциях, митапах и т. п. неэтичным со своей стороны, даже когда активно ищу работу.

Опа. Это почему? Повторюсь еще раз: условный вы условным нам можете быть нужны гораздо больше, чем наоборот (а в идеале все стороны очень хотят, даже если пока про это не знают). Так что я лично считаю эту заморочку вредной. Да какого черта, вообще, я на некоторые конференции вообще езжу только за тем, чтобы ко мне подошли расспросить про то, как у нас.

Я обычно на конференции или митапы хожу для обмена опытом. Иногда, чисто случайно, для хантинга. :) Ну, на конфу давно записался, а время наступило и у нас вакансия как раз открыта. Услышал, что кто-то работу ищет — предложил. Или раз было, лет 5 назад, зашёл разговор на афтерпати про деплои и т. п., я рассказал как мы докер используем так, что под каждую ветку полный енв поднимается со своими доменами типа (admin|app|shop).task-\d+.dev.example.com, один сказал завистливо что-то типа "везёт вам, разрешают, а у нас консерваторы и перестраховщики", я ему что-то вроде "мы сами себе разрешаем, больше некому", он что-то вроде "вот бы к вам попасть", а я ему "вот, апплайсяс" и сылку на вакансию. Год вместе проработали, потом я ушёл.

Как по мне, то вполне нормально провести техсобес после ТЗ, но в виде обсуждения результата. В зависимости от уровня позиции можно пообсуждать от что это собственно значит до какие могут быть проблемы с этим кодом и как их можно решить.
у меня было так — ТЗ было выполнено, тесты код прошел и хэш-суммы файлов совпали, а на собес пришел и там завалили. Тут правда сыграло роль, что не выспался, нервничал и ревьюер просил решать (уже задачки на 5 минут) и попутно объяснять. Если бы дали задачки решить «без человека», а потом объяснить, то справился бы лучше, ибо мысли соберешь, а так боишься «ляпнуть что-нибудь не то». Поэтому даже на те вопросы, на которые ответ знал, не смог ответить.
В целом собес есть собес. Оглядываясь назад я понимаю, что это все равно было какой-то опыт. Опыт всегда хорош вне зависимости от результата. Я понял, где нужно было подтянуться и что я знаю, а что нет. И волноваться меньше нужно(+20 к урону успеху), и высыпаться. Да и со стороны ревьюера, если посмотреть, то он же тоже человек, и ему с тобой работать. Так возьмут, а характерами не сойдетесь и уволят — ты время потерял и он потерял, да и нервы друг другу попортите.
Правда было обидно, что пришлось ехать из другого города и результата не вышло.

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


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

Спасибо, учту. На самом деле нутро подсказывало, что так оно и есть: придется подстраиваться под этого человека.
Хм… странное ощущение — после Ваших слов я стал спокойнее относиться к той ситуации. Уже не жалею, что «провалился» :)
Sign up to leave a comment.