Комментарии 93
Тест на 1 час из небольших задач или тест из готового проекта часов на 8+.
Первый, я уверен, никто не против сделать, хотя бы для разминки.
Второй — это явно перебор.
Вот и вся история )
ЗЫ: а примеры из статьи лишь показывают адекватность собеседования. В первом случае оно было адекватное, во втором — кто то из участников явно был не в духе. Или собеседуемый психанул на пустом месте или собеседующий зачем то его хотел завалить.
Ничего про тестовые задания в примерах нет.
А вот тестовое «домашнее задание» может быть не сферическим в вакууме, а чем-то более-менее напоминающим работу, и тогда оно и будет проверять, сможет ли человек справляться именно с типичной работой, да и более того, возможно будет вызывать отклик у человека, которому нравится подобная работа.
Но при всем при том я абсолютно согласен, что оно так же обязано быть достаточно недлинным. Лично я вот резко хуже отношусь к тестовым, которые по прикидкам займут больше времени, чем один подход на 2-3 часа. Если компания просит что-то более долгое — то только если она готова оплачивать потраченное на них время.
Я бы сказал, что хорошее тестовое должно обязательно быть максимально приближено к реальной работе
Поддержу.
Было несколько случаев — иногда на собеседовании начинали давать задачки из учебника, абсолютно оторванные от жизни. Иногда решал, иногда сразу отказывался и уходил. Под настроение. Но с такими работодателями однозначно не связывался и не буду связываться, ну разве что совсем край и кушать нечего.
Был случай, когда на тест дали небольшую «домашнюю тестовую задачку» по реальной тематике. Нужно было чуть дополнить и расширить функционал в имеющемся коде. Объем был небольшой — на полдня работы максимум. Но такое задание считаю вполне адекватным — тут сразу и владение нужным инструментарием и умение читать и понимать чужой код и оценка собственного кода.
А там, где работаю сейчас, никаких тестов не было. Просто посидели, поговорили. Чем занимался я, чем занимаются тут. Вполне адекватное общение получилось. И взаимноприятное.
В целом, к реальным тестам отношусь вполне нейтрально. К «олимпиадным» задачам и задачам из учебников — резко отрицательно. На собеседовании они скорее в минус тестирующему т.к. показывают его формализм в подходе и отсутствие интереса к соискателю
Конечно, это может зависеть и от области работы (вдруг одно окружение настраивать надо двое суток), но там уже другая история )
Первый раз сделал, и даже получил фидбэк. Второй раз задал вопросы (а нафиг столько мелочей, а что вы вот тут подразумевали), оставили без ответа.
Больше понравился подход живого кодинга. Дают простую задачу на полчасика-час и решаешь вместе с ревьюером (обсуждая всмысле). Больше похоже на реальную работу.
Мы только что приняли решение давать простенькое задание (~2 часа для человека с идеальным совпадением по квалификации) до первого собеседования с технарями (не HR). Когда мы его обсуждали было очень, очень трудно (придумать что-то такое, что легко сделать, но по чему будет хорошо видно что человек знает что делает). Придумали. В рамках разработки ТЗ я его сам решил, и даже обсудил с коллегами (у которых были альтернативные методы решения).
Первый же человек, который по резюме выглядел интересно написал там такого....
Если кому интересно, должность девопс/администратор — а задача была с помощью ансибл установить/настроить nginx (статика из одного файла в котором значение переменной), и написать к этому тесты.
Идея во-первых убрать стресс у человека (по сравнению с вопросом на собеседовании), если он какой-то детали не знает (ну да, задание будет 4-6 часов, включая чтение, зато интересно и спокойно делать), во-вторых будет о чём говорить на собеседовании.
Для тестового задания часто просят создать проект с нуля, сделать конфигурацию, деплой на сервер (если возможно) добавить много boilerplates (если используется фреймворк). Получается что основное время уходит на это. Поэтому когда пишут, что задание на 4 часа, по факту 4 часа это работа с кодом, и еще 4+ часов на настойку всего, что нужно для кода.
Конечно, есть рабочие проекты, где создание с нуля приложения это частая потребность (например продолжительность проекта до полгода и для нового заказчика снова с нуля), но таких не очень много, по моему опыту. А задания тестовые у всех примерно одинаковые. Вот поэтому и не нравятся они.
Задача была сделать карту с [...] экспортом в gpx [...].
[...] бортанули из-за того, что [...] gpx файл не проходил валидацию.
То есть, вас попросили сделать файл определенного формата, а вы сделали что-то другое, что, вероятнее всего, поломает половину консьюмеров — и у вас, как вы выразились, бомбит? Мило.
Если вы генерируете 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-адреса спрашиваете». То ли описание вакансии человек не прочитал или не понял, то ли...
А вот после окончания теста/собеседования практически все благодарили за интересность и уникальность формата вне зависимости от результата. Даже если мой вердикт, который я озвучиваю сразу, — отрицательный, многие просили «ответы», либо возможность подумать дома и прислать «решение» — просто для собственного удовлетворения. И да, начиная тест, я произношу сакраментальную фразу: «все, о чем я буду вас спрашивать или что попрошу сделать, можно реализовать и никаких подковырок в моих вопросах нет и быть не может».
Есть испытательный срок, который создан чтобы понять как человек работает.
Самое адекватное тестовое задание которое у меня было, выглядело так:
Пригласили на работу удаленно, дали задачу в проекте, установили на неё срок и оплату. По результату я либо выхожу работать дальше, либо заканчиваем сотрудничество.
По сути просто ограничили испытательный срок несколькими днями. Это адекватно. Увидели в бою квалификацию. Короткое тестовое не может выявить ничего, что не способно выявить нормальное собеседование, и используется только для того, чтобы тратить время соискателя, вместо времени собеседующих.
Вот именно, чтобы понять КАК человек работает. А тест помогает понять а может ли человек работать на этой позиции в принципе.
Возможность уволится и быть уволенным без объяснения причины в любой момент.
Да, это честно. Тем более это работает в обе стороны.
А вернуться на неё вряд ли получится.
Не вижу как это работает в обе стороны. =)
Что бы сидеть без работы?
Алименты и кредиты как то сложно платить когда нет денег.
Лучше я побольше пособеседуюсь и выберу тех, от кого с большой вероятностью не уйду или буду иметь время для поиска замены. Три дня — явно не такая история.
ЗЫ: уходил. Но это была очень специфическая история.
Поэтому прежде чем увольняться и уходить куда то я лучше пройду побольше собеседований и знакомств с ними, а не уволюсь и начну проходить у них испытательный срок «для познакомиться».
ЗЫ: работодатель от моего ухода ничего не теряет, в общем то, а я теряю работу которая у меня была. как то это не круто )
Ну и снизить риски тоже.
А вот так, увольняться с работы где тебе платили ради кота в мешке и прохождения «испытательного срока» вместо «собеседования» — нет, спасибо.
Короче, смысл был в том, что собеседоваться можно параллельно работе, а проходить испытательный срок — нет. Поэтому лучше собеседоваться, чем проходить испытательный срок )
Тестовые задания нужны в двух случаях:
1) Кандидат врёт(тут не тестовое задание нужно, а испытательный срок)
2) Нужно сэкономить время специалистов компании за счет кандидата(тут надо менять подход к найму)
Вот и получается, что тестовое задание не нужно.
Если можно увеличить уверенность в том, что на новом рабочем месте всё будет хорошо — почему бы этого не сделать?
3. Нужно дополнительно убедиться что кандидат подходит.
Вот и получается, что я лучше сделаю тестовое задание (если у работодателя есть такое желание), чем уволюсь и пойду проходить испытательный срок в компанию, где мои навыки недостаточны по нужному направлению (возможно).
Потому что сидеть без работы совсем не хочется.
Вот только работник теряет стабильную работу и заработок который у него был, ради того что бы начать проходить «испытательный срок» тут. А работодатель в этом плане ничего не теряет — как была у него вакансия до, так и останется.
ЗЫ: да и потеря одного сотрудника, которому толком ещё ничего не заплатили и который толком ещё ничего не сделал для компании не сравнится с потерей заработка полностью для работника.
Так что риски несоизмеримы.
Работодатель обычно теряет больше времени на испытательный срок, чем работник.
Работник получает за испытательный срок деньги.
ЗЫ: да и работник, в общем то, не сложа руки сидит в этом время и деньги им заработаны )
Но это, в общем то, не важно по двум причинам:
1. Сотрудника берут обычно на вакансию, а не на замену кому то, т.е. от того что человек уйдёт фирма вернётся к предыдущему состоянию, а не худшему чем было.
2. Деньги заплаченные работнику вряд ли представляют угрозу благосостоянию фирмы.
В то же время работник:
1. Теряет работу которую имел и после ухода с испытательного срока остаётся в более плохом положении, чем был.
2. Без денег от работы одного работника у работника куда больше проблем чем у фирмы.
not_enough хочется верить, что больше чем платит ему )
В моём мире куда чаще фирмы берут на замену, чем на расширение. Стараются перехлестнуть уходящего и приходящего сотрудника, но не всегда получается: я вот за 2+ месяца объявил о своём уходе, вчера первый день на новом месте, а человека, который хоть частично меня заменит по текущим задачам готовы брать уже за большие деньги, но не получается. Вернее одного ношли, но не прошёл и первого дня испытательного срока.
И даже без учёта этого, всё равно к худшему возвращается: Те, кто сотрудника обучал, могли бы выполнять более полезные функции в это время. Сотрудник, которого обучили, но который не успел обучение окупить — прямые потери, выкинутые на ветер деньги. Да и на мотивации остальных может сказаться.
Чтобы выбрать себе работу по душе. А чтоб не переживать нужно иметь финансовую подушку.
Но, насколько я могу судить, у людей по большей части её нет.
А ещё лучше — иметь финансовую подушку и не тратить её когда можно её не тратить. И не сидеть безработным без необходимости. =)
ЗЫ: работу по душе можно выбирать и работая на работе которая не очень по душе, но которая кормит. Обычно — в этом и смысл )
Получал тестовые и из других мест. Где-то брался и решал, где-то не мог. Тестовое — это неплохо, потому как обе стороны могут оценить адекватность друг друга. Например стал решать тестовое одной конторы — а там не понятны условия задачи. Пишу на почту, а там ответ «как поняли, так и делайте?». В другом месте — «да, Вы все правильно поняли. А тут мы ждем от Вас это и вот это». Уже об HR сразу что-то понятно. Однозначно тестовые нужны, особенно в мегаполисах и тем, кто собрался в них переезжать.
Тут есть все необходимое время. Ты не нервничаешь, как при человеке. Можешь оценить адекватность. Не надо никуда ехать. Сплошные плюсы. А решать или нет — дело личное, которое показывает — хочешь тут поработать или нет.
Со стороны работодателя никогда не давал тестовых заданий. Это не порядочно.
У кого-нибудь было такое, что соглашались рассмотреть уже выполненное тестовое задание, на подобную вакансию для другой компании?
Было
Мы и гитхаб готовы рассмотреть с удовольствием, вместо тестового задания, если он у соискателя есть. Любой более-менее завершенный код из любого игрушечного проекта на выбор соискателя.
Что лучше в таком случае, сделать тестовое или всё же гитхаб? :)
Например свой гитахб github.com/Dzmitry1983 я бы своему работодателю не показал.
Как вы относитесь к гитхабу соискателя [...]
Я свой гитхаб стал чистить и поддерживать в нестыдном виде только после первых пары десятков подписчиков. Так что мы все понимаем, и никак оценивать грязное белье в запертых комнатах не станем.
Выберите один проект, за который не стыдно — хоть тестовое из прошлой жизни, хоть свой домашний проект на Идрисе. А если такого нет — вот тут лучше, наверное, все-таки сделать задание :)
Одно дело сделать одну задачу, даже пусть и на 5-6 часов, выложить её на гитхабе и пусть остальные смотрят и оценивают.
Но в процентах 90% я слышу только одно — вы все-таки решите нашу задачку. А чем ваша задача отличается от других? Вы особенные задачи даете? Или остальные дают тупые задачи, а вот ваша она одна единственная и неповторимая. Или вы можете оценить только свою задачу?
Ведь цель всех задач — посмотреть на ваш код, как вы мыслите.
Я не Бил Гейтс, чтобы меня с руками отрывали.
От себя добавлю, что лучше бы, чтобы в тестовом задании был заложен технологический стек, по которому будут гонять на собеседовании. Таким образом получится, что решил тестовое задание и теорию просто освежил в памяти, к собесу готов; а если видишь, что не по плечу — чего-то не знаю, то сразу книжку в руки и дотягиваться; ну, а если не сам решил, то смыла идти на собес вообще нет. В таком случае тестовое при любом раскладе будет решено не зря.
Адекватные люди дают тестовое задание именно для того, чтобы вообще не разговаривать о программировании на собеседовании. После успешно выполненного ТЗ контора гораздо сильнее заинтересована в соискателе, чем наоборот, поэтому весь разговор будет о том, как убедить человека с нами поработать, и почему он именно об этом всю жизнь мечтал.
А так у меня был пример — пришла на собеседование, стали рассказывать что за проект и как работают и вот на этом этапе я поняла, что это не то, что мне нужно. Это хорошо, что не нужно было делать ТЗ. А так получилось бы зря потраченное время.
А я вообще не соглашаюсь ни на какие собеседования, кроме обеда с CTO; вон полный гитхаб кода, смотрите, если вы вдруг про меня каким-то окольным путем узнали.
Но мы в этой ветке вроде бы не хедхантинг обсуждаем, а подачу на вакансию с улицы. И до того, как я посмотрю на написанный кандидатом код — нам вообще разговаривать не о чем.
Если так принципиально, то скажу "смотрите на гитхабе, там даже пара тестовых есть, могу предметно указать, на что стоит смотреть, если интересно а) как я пишу код без ограничений, как минимум на стиль кода, не заботясь о том, будет ли код понятен кому-то кроме меня через несколько лет и б) где я коммитил в опен-сорс проекты, соблюдая их стайл-гайды."
Ну а так, многие хантинг начинают по схеме "1. есть интересная вакансия, дайте резюме 2. Теперь тествовое сделайте, и если нам понравится, то 4 уровня собеседований"
Мне лично подойдет любой код, на каком угодно языке (у нас недавно соискатель на Идрисе выпендрился, но ожидаемо не осилил все сделать как надо, причем на каком-нибудь Хаскеле, я думаю, сумел бы). Есть готовый — отлично; нет — не беда, вот вам ТЗ.
Но о чем можно спрашивать кандидата после ТЗ — я ХЗ :)
И так же все понятно. Либо теперь я очень хочу, чтобы мы работали вместе, и сделаю все, чтобы это стало обоюдным желанием, — либо зачем нам всем тратить зря время?
Вариант — вы посмотрели мой код на гитхабе, но он вам особо не помог, просто потому что нет сложных задач. так, какие-то выводы вы сделали, типа того, что в каждом репозитории код в одном стиле написан, соблюдает вские там принципы и использует паттерны к месту без фанатизма, решает вроде как поставленную задачу и даже какие-то неочевидные граничные случаи отрабатывает, которых в задаче нет.
Но вот проблема — задача слишком простая. Вас не устраивают такие задачи для проверки, может алгоритмов хитрых нет, может нет примеров работы со внешними сервисами, может архитектурные навыки по ней не проверить и т. п.
В общем "красных флагов" для вас нет, но и сказать "нужно брать, он тестовом уже порешал половину наших проблем на продакшене, к которым мы даже не знали с какой стороны подойти" вы не можете. Вы предложите мне ТЗ? А зачем мне его делать, если я про вашу компанию и конкретную позицию знаю только что-то вроде "лидеры рынка в узком сегменте, требуется работник работу работать, требования: куча абреввиатур, предлагаем деньги, отпуска и больничные", а другие хотя бы о компании расскажут без тестового, а может и офер сделают даже.
Ну раз уж вы меня спрашиваете — я от своего имени и отвечаю.
Я работаю в компании, которую знают все как минимум в нашем стеке в двухмиллионном городе. Это не совсем случай ноунейма. Ну и так-то я про компанию и вакансию с удовольствием расскажу до всякого вообще кода — только спросите.
Ну и я все равно считаю, что толковый разработчик либо покажет то, чего мне хватит за глаза для вынесения вердикта, либо сделает ТЗ, если в гитхабе ничего такого, чтобы прям «блеснуть» нет.
Я недавно общался с коллегой из конкурентов, он мне рассказал про их ТЗ, я его просто из любопытства решил :) Мы потом сравнили наши решения и пришли к заключению, что нас брать ну никак нельзя: примерно в ста местах можно было лучше (он проверял мое, я его решение).
Очень, кстати, отрезвляющий, получился эксперимент.
Ну и так-то я про компанию и вакансию с удовольствием расскажу до всякого вообще кода — только спросите.
И до того, как я посмотрю на написанный кандидатом код — нам вообще разговаривать не о чем.
Как будто разные люди пишут. :) Бывает
Я про то, что прежде чем делать ТЗ, мне хочется узнать, а хочется ли мне попасть на конкретную позицию, чем она интересна для меня, какие задачи я буду решать, с кем вместе как в непосредственной команде, так и в целом по проекту, в каком окружении (имеется в виду авторитарном, демократическом и т. п.), кто непосредственный начальник будет, какие возможности роста вообще и какие возможности занять его место в частности :)
И известность компании или проекта, глобальная или локальная, тут на… дцатом месте.
Я в своё время делал эксперимент такой: сделал ТЗ, дал ребятам из команды, посмотрел на результат — по нему я бы их отсеял до собеса. А так нормально работают.
Как будто разные люди пишут. :) Бывает
Я имел в виду «предметно разговаривать на технические темы, выяснять уровень компетенций». Потрещать про то, как у нас круто — меня уговаривать не нужно.
хочется узнать, а хочется ли мне попасть на конкретную позицию, [+++]
Приходите к нам на митап, который собирает самых сильных разработчиков в стеке в городе, возьмите меня за пуговицу, попросите экскурсию по офису, задайте любые вопросы, пригласите в бар, наконец.
сделал ТЗ, дал ребятам из команды, посмотрел на результат — по нему я бы их отсеял до собеса. А так нормально работают.
Определите «нормально», пожалуйста. У нас те, кто приходит через ТЗ ко мне, все идут рано или поздно в mission critical. Во фронте, например, все гораздо лояльнее — там одной ошибкой контору разорить не удастся.
Я имел в виду «предметно разговаривать на технические темы, выяснять уровень компетенций». Потрещать про то, как у нас круто — меня уговаривать не нужно.
Ну вот конфликт у меня с рекрутерами на тему ТЗ обычно возникает, когда они требуют выполнить ТЗ до того, как кто-то из технического менеджмента расскажет мне как у них круто. Ну или из обычного менеджмента, если обсуждаемая позиция является высшей из технических у них. Обычно такой разговор предполагается у них как последний этап рекрутинга. А без него я, как кажется и вы, не вижу смысла выяснять технические компетенции друг друга.
Приходите к нам на митап, который собирает самых сильных разработчиков в стеке в городе, возьмите меня за пуговицу, попросите экскурсию по офису, задайте любые вопросы, пригласите в бар, наконец.
Считаю такое целенаправленное поведение на конференциях, митапах и т. п. неэтичным со своей стороны, даже когда активно ищу работу.
Определите «нормально», пожалуйста.
Не разоряют контору :) В том числе при работе с автоматическими исходящими безнал переводами. В целом сделал вывод, что плохой из меня составитель и/или анализатор ТЗ.
А без него я, как кажется и вы, не вижу смысла выяснять технические компетенции друг друга.
Разумеется. Это нам в первую очередь нужно, чтобы кандидат прямо хотел выполнить ТЗ вчера, а не соискателям, и я прекрасно это понимаю. Потому что если есть устремление — то и ТЗ будет совсем иначе сделано, с огоньком и ответственностью. Где-то тут, возможно, кстати, кроется причина невысоких результатов ваших коллег — люди не любят делать бессмысленные вещи.
Считаю такое целенаправленное поведение на конференциях, митапах и т. п. неэтичным со своей стороны, даже когда активно ищу работу.
Опа. Это почему? Повторюсь еще раз: условный вы условным нам можете быть нужны гораздо больше, чем наоборот (а в идеале все стороны очень хотят, даже если пока про это не знают). Так что я лично считаю эту заморочку вредной. Да какого черта, вообще, я на некоторые конференции вообще езжу только за тем, чтобы ко мне подошли расспросить про то, как у нас.
Я обычно на конференции или митапы хожу для обмена опытом. Иногда, чисто случайно, для хантинга. :) Ну, на конфу давно записался, а время наступило и у нас вакансия как раз открыта. Услышал, что кто-то работу ищет — предложил. Или раз было, лет 5 назад, зашёл разговор на афтерпати про деплои и т. п., я рассказал как мы докер используем так, что под каждую ветку полный енв поднимается со своими доменами типа (admin|app|shop).task-\d+.dev.example.com, один сказал завистливо что-то типа "везёт вам, разрешают, а у нас консерваторы и перестраховщики", я ему что-то вроде "мы сами себе разрешаем, больше некому", он что-то вроде "вот бы к вам попасть", а я ему "вот, апплайсяс" и сылку на вакансию. Год вместе проработали, потом я ушёл.
В целом собес есть собес. Оглядываясь назад я понимаю, что это все равно было какой-то опыт. Опыт всегда хорош вне зависимости от результата. Я понял, где нужно было подтянуться и что я знаю, а что нет. И волноваться меньше нужно(+20 к
Правда было обидно, что пришлось ехать из другого города и результата не вышло.
С опытом я уже перестал относиться к собеседованию как к экзамену, а стал именно как к беседе с коллегами по цеху. Если они настаивают на формате "вопросы здесь задаю я", то могу без сожалений просто прервать такую "беседу": "Спасибо за уделенное время, но ваша вакансия мне уже не интересна".
Но тут можно делать скидку — если собеседуют тебя вроде обычные программисты, то может по другому они просто не умеют, их так собеседовали всю жизнь и они так же — классическое "у нас так принято". А вот если в таком ключе проводит собес твой потенциальный начальник, то опыт подсказывает, что даже если пройдёшь, то в итоге всё равно "не сошлись характерами" в среднесрочной перспективе.
Говорим про тестовые задания: несколько историй и опрос