Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Как проводить собеседование, чтобы все остались довольны. Чек-лист для интервьюера

Всем привет! Меня зовут Макс Даниленко, и сейчас я на позиции Head of Java Center of Excellence в компании Intellias. Кроме всего прочего, занимаюсь тут усовершенствованием процесса найма Java-специалистов. В Intellias есть программа сертификации интервьюеров, в её рамках я и составил свод правил и рекомендаций по проведению собеседования. Хочу поделиться своими разработками с комьюнити. Возможно, кому-то пригодится. Итак, погнали!

Иллюстрация Алины Самолюк

Каких целей я пытался добиться:

  1. Сделать собеседование менее стрессовым мероприятием как для кандидата, так и для интервьюера.
  2. Помочь кандидатам понять свои слабые и сильные стороны и как развиваться дальше в ІТ.
  3. Показать, что компания ценит людей и время, которое кандидаты потратили на интервью.

Зачем нужна программа сертификации интервьюера

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

  1. Повысить качество проводимых интервью. Хотя на DOU процент плохих отзывов об Intellias очень мал, это не значит, что сам процесс найма идеален.
  2. Стандартизировать процесс интервью. Так мы уменьшим время, потраченное на одного кандидата, и сможем гарантировать определенный минимальный уровень качества.
  3. Предоставить качественный фидбэк кандидату. А так как он еще и содержит список учебных материалов, можно помочь таким образом специалисту закрыть пробелы в знаниях и продвигаться по карьерной лестнице.
  4. Маркетинг. Да, как ни странно, это именно он. Поскольку первое, с чем сталкиваются соискатели — это рекрутмент-отдел и интервьюеры. Поэтому для Intellias интервью — часть маркетинговой стратегии, позволяющая рассказать о преимуществах компании и на деле продемонстрировать эффективность процессов.
  5. Упростить взаимодействие рекрутмент-отдела с экспертами по интервью.

Техническая подготовка

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

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

Камера. Начинаем интервью с включенной камерой. Первое — так легче кандидатам: они видят, что общаются с реальным человеком. Второй момент: интервью — это в первую очередь знакомство. И на наше мнение, кроме всего прочего, влияет мимика человека в кадре.

Если у вас в комнате бегают дети или идет съемка порнофильма — поставьте себе виртуальный фон. Сейчас это умеют делать все программы.

Уберите лишний шум. Для шумоподавления можно использовать krisp или любое другое программное обеспечение. Zoom, Google Meet и MsTeams имеют встроенную функциональность для этого.

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

Если вам проще проводить интервью без камеры, спросите у кандидата, не будет ли он против, если вы ее выключите. Почему камера не обязательна и даже может быть вредна на интервью, можно почитать в статьях «Науковці пояснили, чому люди відчувають Zoom-втому від постійних відеодзвінків та що з цим робити» и Nonverbal Overload: A Theoretical Argument for the Causes of Zoom Fatigue.

Проверить интернет-соединение: оно должно быть хорошим и стабильным. Я оказался не готов к таким проблемам. Мой провайдер выдавал всего 100 Мбит/с, а Wi-Fi роутер работал только на частоте 2,4 ГГц. Все бытовые приборы, телефоны и телевизоры, которым нужен интернет, были подключены к одной частоте. Качество связи было таким плохим, что я использовал 4G для видеозвонков. Сменил интернет-провайдера на такого, который мог выдать 1000 Мбит/с, и купил двухканальный роутер. Этот роутер работает на частоте 5,0 ГГц и 2,4 ГГц. На частоту 5,0 ГГц подключен мой рабочий ноутбук, а все остальные устройства — на 2,4 ГГц.

Ознакомиться с матрицей компетенции. Для чего это нужно? Чтобы понимать, какие требования предъявляются к кандидатам на разные уровни. Если не успеете ознакомиться — не так уж страшно, потому что в фидбэк-форме уже есть матрица компетенции.

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

Подготовка к конкретному интервью

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

Возьмем простой пример вакансии, где нет упоминания о популярных в мире Java фреймворках, таких как Spring и Hibernate. Если их нет в описании, то и спрашивать об этом на интервью не стоит. И наоборот, если в требованиях указано знание Kafka и TDD-практик, то интервью должно строиться вокруг них.

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

Интервью

1. Включите камеру и попросите соискателя сделать то же самое.

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

3. Представьтесь. Расскажите немного о себе. Например, меня зовут Даниленко Максим, я занимаю должность тимлида на проекте XYZ.

4. Расскажите о плане интервью и сколько оно займет времени. Например: собеседование будет занимать 1 час, мы поговорим про алгоритмы, Core Java, Spring и Hibernate.

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

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

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

7. Необязательно: можно пройтись по CV и задать по нему вопросы. Поговорить про то, кем видит себя человек на проекте. Какая у него была роль на предыдущих местах. Но этот пункт больше подходит для менеджеров, чтобы оценить софт скилы кандидата.

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

9. Тайминг: следите за временем. Интервью не должны превышать 90 минут. Желательно тратить на него не более 60 минут. Важно оценивать и то, за какое время кандидат правильно ответит. Если вы выясняли сложность такой структуры данных, как Map, более 30 минут, а кандидат пришел на вакансию Senior — это явный показатель, что специалист плавает в этом вопросе и что можно идти дальше.

10. Если хотите дать задачку на Java или SQL, не стоит заставлять человека писать ее в блокноте. Пусть это будет его IDE, к которой он привык и комфортно себя чувствует. Специалисту необязательно шарить экран. В IntelliJ IDEA, например, можно использовать фичу code with me.

Если даете задачу и ее нужно будет решать в IDE, не стоит тратить время человека и свое на создание проекта, настройку и написание тестов. Заранее сделайте на GitHub проект вместе с тестами и перед (или на) интервью попросите человека скачать его. Это сэкономит всем участникам время.

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

После интервью

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

Если человек не прошел (обычно это происходит из-за незнания каких-то тем), напишите ему, что нужно прочитать, чтобы в следующий раз все получилось. Например, кандидат не ответил на вопрос по executionServices. Так и напишите, что ответ можно найти в книге Java Concurrency in Practice, глава такая-то. Можете еще какие-то дополнительные статьи кинуть. И не забудьте похвалить там, где человек хорошо отвечал.

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

Выводы

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

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

Мне бы хотелось узнать о правилах или хороших практиках, которые есть в других компаниях. Было бы прикольно увидеть их в комментах. Пишите :)

Полезные ссылки

  1. Как проводить и проходить собеседование в IT: краткий курс молодого бойца.
  2. Алгоритм проведения IT-собеседования.
  3. Как превратиться в суперзвезду Zoom-звонков за 15 минут.
  4. Не нужно включать камеру.
  5. И еще про камеру.
  6. Экспорт с MSteams календаря в Google.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось16
До обраногоВ обраному10
LinkedIn

Схожі статті




219 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Как проводить собеседование, чтобы все остались довольны.

Удалённо. И в строго оговоренное время. А там хоть водку пейте на собесе, главное результат.

Да, есть еще староверы в губерниях)

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

Тут с просьбой все к нему, чтоб их решать сомненье:
«Пожалуй, — говорят, — возьми на час терпенье,
Чтобы Квартет в порядок наш привесть:
И ноты есть у нас, и инструменты есть;
Скажи лишь, как нам сесть!»

Проверить интернет-соединение

Скорее понять как работает сеть и что такое протоколы WiFi и что значат циферки 100 и 1000 в буклете провайдера.

хороший совет, а как им пользоваться?

ООО это же так сложно:))) google.gik-team.com/...​=что такое протоколы WiFi

Можно прям вот с первой ссылки начинать читать.

Да и как им пользоваться вашим советом, а?
Технически и теоретически для звонков 100 Мбит/с и Wi-Fi роутера на частоте 2,4 ГГц более чем достаточно. Я даже так скажу должно хватить и 20 Мбит/с!
Просто написал свою историю, что простых знаний и теории не достаточно и лучше проверить
Вообще статья не об провайдерах или роутерах, жаль что вы обратили внимаине именно на это

Смешно конечно, ну да ладно. Собственно ваша статья приблизительно также воспринимается. Если для улучшения видео связи вам нужно сменить провайдера и 10 кратное увеличение скорости сети внутри провайдера. То для улучшения качества найма найдо сменить рекрутера на более мощного зачем разбираться в тонкостях. Как определить более мощного ну кончено прочитать рекламу на сайте HR агентства, именно так это и работает.

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

Да, я не разобрался, и вообще лох в этом вопросе. Но я и не хотел тратить кучу времени на это.

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

Если мы наймем, хоть 10 новых рекрутеров, это не повлияет на качество интервью

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

Так и не ответили на вопрос, как ваш комментарий поможет мне или другим читателям?
какие пути решения вы видите?

Тайминг: следите за временем. Интервью не должны превышать 90 минут. Желательно тратить на него не более 60 минут

У мене одна з перших технічних співбесід зайняла 3 години, причому це було ввечері, після роботи, так що закінчили ми годин в 10.
Зараз я впевнений в тому, що технічна співбесіда має займати 40-45 хвилин, не більше. Мета співбесіди — зрозуміти, підходить людина чи ні, а точніше відповідає тим навичкам/досвіду, які є в CV.
Так до речі роблять зарубіжні фахівці. А у нас люблять тримати по 1.5 — 2 години, влаштовуючи іспити.

Мета співбесіди — зрозуміти, підходить людина чи ні,
а точніше відповідає тим навичкам/досвіду, які є в CV.

Ось це досить неефективна стратегія пов’язувати перше і друге. Резюме — це «маркетинговий матеріал», одна з його важливих задач — пройти фільтр рекрутерів, а для цього часто вказують речі які просто «були на проекті» (хоча людина з ними реально не працювала)

Так до речі роблять зарубіжні фахівці.

«Спіймати людина на брехні в резюме» таке зустрічав лише у наших або в західних конторах в яких культуру визначають вихідці з постсовка.

А у нас люблять тримати по 1.5 — 2 години, влаштовуючи іспити.

1.5-2 години — це якраз нормальний час, особливо якщо у кандидата цікавий досвід і є про що поговорити. 30-60 хв — це якщо розумієш, що людина не підходить.
Якраз в «західні контори» люблять поговорити 4+ годин, а у нас таке здебільшого в «стартапах», які надивились на західні контори.

Ось це досить неефективна стратегія пов’язувати перше і друге. Резюме — це «маркетинговий матеріал», одна з його важливих задач — пройти фільтр рекрутерів, а для цього часто вказують речі які просто «були на проекті» (хоча людина з ними реально не працювала)

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

«Спіймати людина на брехні в резюме» таке зустрічав лише у наших або в західних конторах в яких культуру визначають вихідці з постсовка.

1. Человек идёт на тех. лида.
2. Пишет себе MongoDB в технологии.
3. Пишет, что был архитектором на проекте, где была MongoDB.
4. На вопрос, почему выбрали MongoDB, отвечает, что когда пришёл, базу уже выбрала команда.
5. На вопрос, а чем MongoDB отличается от SQL баз в работе, и какие мысли насчёт SQL/NoSQL, отвечает... «я не знаю».
Но мы его отфутболили, потому что «совки» — оооок). Пусть лучше я буду «совком», но с балаболами в резюме оставлю «честь» работать другим. Понятно, что уровень может быть разным, и это нормально, но если человек реально «мимо проходил» и тупо вписывает технологии из проекта, то, если я могу это проверить, мои собеседования такие кадры не проходили и проходить не будут. Как можно быть готовым брать на себя риск возможного вранья (а такие кейсы — именно оно самое, как бы кому-то не хотелось подать его под другим соусом), мне понять сложно, честно говоря.

1. Человек идёт на тех. лида.
2. Пишет себе MongoDB в технологии.
3. Пишет, что был архитектором на проекте, где была MongoDB.
4. На вопрос, почему выбрали MongoDB, отвечает, что когда пришёл, базу уже выбрала команда.
5. На вопрос, а чем MongoDB отличается от SQL баз в работе, и какие мысли насчёт SQL/NoSQL, отвечает... «я не знаю».
Но мы его отфутболили, потому что «совки» — оооок)

1) А де тут ви спіймали на брехні? Тут просто приклад некомпетентності — архітектор не розуміє трейдофи тієї чи іншої технології (5). Що саме ви тут спростували? Те що людина має (якийсь) досвід з монго? Чи те що вона займала позицію архітектора (нагадую, що вам явно сказли, що вибір був зроблений вже до приходу людини в команду)?
2) «Постсовок» тут — це територія колишнього СРСР.

Чи те що вона займала позицію архітектора (нагадую, що вам явно сказли, що вибір був зроблений вже до приходу людини в команду)?

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

Он занимал позицию тех лида и написал, что сделал там архитектуру.
был архитектором на проекте

Але тут ви написали інше :)

Очевидно, что этот человек банально не архитектил там ничего и пришёл на всё готовое, если даже такие решения уже были приняты.

На різних стадіях проекту, архітектор може/має можливість приймати різні рішення. Наприклад, переїзд з монго на реляційну СКБД після виходу в прод може бути просто невиправданим з економічної точки зору.

Я не знаю яка була конкретно в вашому випадку ситуація. Але брехні я поки не побачив.
Те що у нас техліди і архітектори не шарять різницю РСКБД і НоСКЛ (або ставлять рівність між НоСКЛ і МонгоДБ) — це хоч і сумна, але трохи інша історія.

На різних стадіях проекту, архітектор може/має можливість приймати різні рішення. Наприклад, переїзд з монго на реляційну СКБД після виходу в прод може бути просто невиправданим з економічної точки зору.

Да, но в основном это касается только проектов определённого уровня. То есть, если под новые фичи или нагрузки требуется прям менять архитектуру, и человек делал миграцию от новой к старой, это можно понять под фразой «сделал архитектуру». Но не текучку а-ля решить, как лучше всего сделать фичу, даже если это подразумевает что-то вроде «прикрутили Redis». Потому что «сделать архитектуру» — это как минимум low-level design. Т.к. у меня был кандидат, который говорил про «архитектуру микросервиса», и когда я спросил, а в чём состояли архитектурные задачи в случае отдельного микросервиса, человек сказал что-то вроде «ну, есть же сюлюшен архитектура, а есть — аппликейшен». Таким макаром и я, будучи Strong Middle’ом, мигрировал обособленный кусок монолита в микросервис, и параллельно переписывал его практически полностью, но называть это «архитектурой» как-то язык не поворачивается даже...

Проверить интернет-соединение: оно должно быть хорошим и стабильным. Я оказался не готов к таким проблемам. Мой провайдер выдавал всего 100 Мбит/с, а Wi-Fi роутер работал только на частоте 2,4 ГГц. Все бытовые приборы, телефоны и телевизоры, которым нужен интернет, были подключены к одной частоте. Качество связи было таким плохим, что я использовал 4G для видеозвонков. Сменил интернет-провайдера на такого, который мог выдать 1000 Мбит/с, и купил двухканальный роутер. Этот роутер работает на частоте 5,0 ГГц и 2,4 ГГц. На частоту 5,0 ГГц подключен мой рабочий ноутбук, а все остальные устройства — на 2,4 ГГц.

Вы там собеседования в 4К проводите параллельно качая торренты? Интертелекомовский CDMA-модем (мой резерв) без проблем выдает хорошую картинку в конфе даже на 100 человек в Google Meet. Единственное реальное требование к соединению — чтобы не обрывалось.

нет, проблема была на стороне провайдера и моего WIFI роутера. Воспринимайте это как художественное преувеличение

Интервью не должны превышать 90 минут. Желательно тратить на него не более 60 минут.

У меня последнее интервью с украинскими собеседователями длилось 3 часа

видимо вы сказали, что Крым русский)

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

О, це улюблена штука в великих компаніях, не буду їх називати, коли рекрутер просто тупо 2 години задає питання по списку і звіряє з тими відповідями, які у нього написані.

После того еще было 3-дневное тестовое задание фулстек

Это выглядит очень и очень странно. Хотелось бы узнать, какая была мотивация у ребят, почему они именно так ищут сотрудника?

Требования кастомера такие(помимо основного собеса). Потом еще было кодинг интервью с кастомером, третий этап.

После того еще было 3-дневное тестовое задание фулстек
Требования кастомера такие(помимо основного собеса)

Зустрічав такі штуки, але у випадку, коли кандидат вже працював в компанії (нашій) і кастомер хотів ДЗ, але тоді людина була на бенчі і ДЗ оплачувалось, як робочий час.

Да, это был переход внутри компании. Но я не была на бенче и тестовое попросили сделать на выходных.

Но я не была на бенче и тестовое попросили сделать на выходных.

Чудова причина змінити не лише проект, а й компанію :)

В итоге так и получилось. Пока тут шли собесы за собесами, знакомые, с которыми я раньше работала, позвали. Го к нам, говори сумму. Колебалась я аж 5 минут.

О, це улюблена штука в великих компаніях, не буду їх називати, коли рекрутер просто тупо 2 години задає питання по списку і звіряє з тими відповідями, які у нього написані.

А якшо йде по списку але не тупо, наприклад скiпає зайвi та задає додатковi, якщо не впевнен або навпаки щось цiкаве почув?
Звiряє не з вiдповiдями iз списку а згiдно того, як це працює, особливо якщо кандидат може показати бiльш знаннь по цьому питанню нiж интервьювер?

10. Если хотите дать задачку на Java или SQL, не стоит заставлять человека писать ее в блокноте.

Чому? Може привести приклади задач, які ви даєте?
Я стараюсь давати такі задачі для яких блокнота достатньо.

Если даете задачу и ее нужно будет решать в IDE, не стоит тратить время человека и свое на создание проекта, настройку

Тут проблема якраз з ІДЕ — сетап проекту може займати більше часу ніж сам кодінг. Ваш преконфигурований проект теж може довго відкриватись, оскільки на домашній машині не завжди є все необхідне, ви можете витратити купу часу на скачування залежностей.

и написание тестов. Заранее сделайте на GitHub проект вместе с тестам

Якщо людина працює по ТДД, то «ваші» тести їй будуть більше заважати.
Якщо не фанатик (саме таке закінчення :) ) ТДД, то як ви перевірите чи здатна/готова людина ті тести писати. Знову ж для задачі «в блокноті», можна просто попросити озвучити тестові сценарії.

Чому? Може привести приклади задач, які ви даєте?
Я стараюсь давати такі задачі для яких блокнота достатньо.

Дело в том, что вы можете быть очень скиловым, и вам хватит блокнота для решения любой задачи. Смотри человек испытывает стресс + задача будет не стандартной, а скорее всего на алгоритмы и структуры данных, а это значит не такая, какую девы решают каждый день, плюс писать код не в привычной IDE, а блокноте. И того у на 3 фактора которые мешают человеку показать себя на все 100%. Что мы можем сделать? Убрать или минимизировать какой-то фактор. Я предложил убрать блокнот и дать IDE. Еще момент, если условие задачи не написано где-то, то оно чуть-чуть меняется от кандидата к кандидату. У меня было, когда в логической задачи пропускалось важное условие, и кандидат не мог ее решить.(( А так вы раз создали проект, написали про условие, которое будет одно для всех. И увидите насколько улучшиться результат.

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

Ось це проблема яку треба вирішувати. А не додавати ІДЕ.

И того у на 3 фактора которые мешают человеку показать себя на все 100%

Я побичив лише стрес. Які ще 2? І ІДЕ не допоможе ніяк вирішити цю проблему, кандилат буде просто тупити в своїй же ІДЕ. Наприклад, у мене мак, але я звик програмувати на роботі під віндою і тому не завжди попадаю по хоткеях (а це бісить).

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

І це і є результат. Якщо людина пропускає вимоги — це величезна проблема. І не треба тут списувати на стрес, бо так само людина пропустить вимогу у розмові з замовником, якщо для неї інтерв’ю — стрес.

Ось це проблема яку треба вирішувати. А не додавати ІДЕ.

заставить всех девов вместо работы делать кучу ненужных тасок?)) Да это действительно поможет продукту продаваться лучше)

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

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

Что касается IDE, то как у вас в блокноте будет работать автодополнение или автоописания вызова функции?) или вы думаете что очередность параметров в каждой функции нужно на память помнить, особенно если человек пишет на нескольких языках?)

Вопрос немного не в тему, а куда делись дайджесты по java?

Меня зовут Макс Даниленко, и сейчас я на позиции Head of Java Center of Excellence в компании Intellias.

Engineering Manager
Company NameGlobalLogic Full-time
Dates EmployedApr 2021 — Present

Десь так

Певно стаття довго лежала в черзі. То не авторська проблема, а Доу.

Статья долго готовилась и проходила ревью на DOU

За последние полгода был на нескольких собезах и что удивило — камера включена была только у меня. Странные ощущения от таких собеседований.

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

Если вы идете работать в потогонку, то такой тест самое оно. Сразу показывет куда вы собственно ломитесь.

Клеток, связанных внутри.
Клеток, связанных внутри.
Повторите три раза.
Клеток, связанных внутри.
Клеток, связанных внутри.
Клеток, связанных внутри.

На этом все.
Хладнокровный Кей.
Можете пройти за бонусом.
Спасибо, сэр.

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

потому что они не людей нанимают, а покупают колбасу в магазе. Эта идея устарела еще дето в годах 80-90х но так как никто осбо не развивается то ее продолжают пихать дальше.
Как пример с опенспейсами которые 10 лет юзали, а потом типы сказали — минуточку, провели исследования(которые как выяснилось никто не проводил до этого) и доказали что опенспейс убивает производительность на 30%.

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

А якщо ні керівника, ні команди ще немає? Або керівник та наявна команда на стороні замовника?
Що робити коли людина не підходить на вакансію, на яку йде співбесіда, але поряд є команда, яка суперово матчиться з навичками і побажаннями кандидата?
Що робити, якщо «ідеальне співпадіння» знайдеться не зараз, а через декілька місяців?

Те що ви описали підходить, скоріше, для невеликих компаній зав’язаних на 1 продуктову команду.

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

Не может быть такого что нет руководителя.

Може. Треба зібрати команду до Х числа, щоб стартовати проект. Якщо немає всієї команди, ніхто з команди не потрібен.
Якщо ви спочатку шукаєте «керівника» (яких може бути декілька, наприклад тімлід і архітектор), а потім «керівник» шукає собі команду, то проект не встигне стартувати.

это адовый бред. Нанимать всегда надо сверху вниз а не наоборот. а иначе толпа проблем обеспечена.

От якраз, щоб це не перетворилось в «пекло» і сворюють процедури і усілякі «матриці компетентності», які збільшують вірогідність того, що найняті люди будуть видавати деяку гарантовану якість і у разі чого декого з них можна замінити без суттєвої втрати якості.
Тут важливо розуміти, що мова йде не про топ перформанс, а про «достатній рівень»

Если есть команда рядом то она его дальше и собеседует.

Що означає «поряд»? Поряд — це через тиждень.
Що означає «далі»? Задача якраз мінімізувати кількість співбесід. Щоб банално не проговорювати одні й ті самі питання з різними командами.

Може. Треба зібрати команду до Х числа, щоб стартовати проект. Якщо немає всієї команди, ніхто з команди не потрібен.
Якщо ви спочатку шукаєте «керівника» (яких може бути декілька, наприклад тімлід і архітектор), а потім «керівник» шукає собі команду, то проект не встигне стартувати.

Ну значит проект проебан с самого начала и норм люди туда не пойдут. Как вообще проходит найм млин если никто по ТЗ или биз требованиям не может вообще сказать кто и что надо?)
А если это типа по чьейто реокмендации то приходит начальник и видит что какойто олень уже про***л стек, люди наняты не те и проект вероятно уже в жопе.

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

От якраз, щоб це не перетворилось в «пекло» і сворюють процедури і усілякі «матриці компетентності», які збільшують вірогідність того, що найняті люди будуть видавати деяку гарантовану якість і у разі чого декого з них можна замінити без суттєвої втрати якості.
Тут важливо розуміти, що мова йде не про топ перформанс, а про «достатній рівень»

Ад, это когда люди не могущие делать что то без этого начинают это типа автоматизировать)
До автоматизации и оптимизации любого процесса, он уже должен работать нормально. А у вас он изначально проебан, и вы этот проеб предлагаете возвести в ранг. ОТлично просто)

Що означає «поряд»? Поряд — це через тиждень.
Що означає «далі»? Задача якраз мінімізувати кількість співбесід. Щоб банално не проговорювати одні й ті самі питання з різними командами.

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

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

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

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

вопрос не компаний а отношения к своей работе. Вот ты посмотри на любого.
Асфальт кладут в дождь -ибо пох. Приступников не ловят -ибо пох. Экономику не ростят — ибо пох.

вендор особой ответственности за результат не несет, а отвечает за «поставку кадров»

ибо пох.

99% людей в этой стране — ибо пох. Но все почемуто думаю что во всем веноваты только госдепы коих ну пару тыщ.

не (тільки)компанія співбесідує кандидата. кандидат співбесідує компанію, і для кандидата саме цей бік сівбесіди найважливіший. тому пісня про ідеальне співпадіння колись© потім і про «суперово матчиться» — нонсенс, спочатку кандидат дивиться/співбесідує керівника і команду, а оте усе інше — другорядне і на потім. нема керівника / нема проекту — немає сенсу і в співбесіді, вожді сидять на боці замовника — прекрасно, з ними і поговоримо.

кандидат співбесідує компанію

Угу, компанію, а не проект :)

нонсенс, спочатку кандидат дивиться/співбесідує керівника і команду, а оте усе інше — другорядне і на потім
вожді сидять на боці замовника — прекрасно, з ними і поговоримо.

То ви вважаєе, що контра має резикувати своїми грошима і репутацією випускаючи «чувака з завищеним ЧСВ» до своїх замовників? :)

Найм/зміна роботи — це складний процес. Кожна сторона закриває ті чи інші ризики. Наприклад:
— контора не хоче ризикувати своєю репутацією показуючи клієнтам неадеквата, або просто слабкого технічного спеца. Як це вирішити?
— проект — це круто, але проекти змінюються, а компанії не завжди, тому хотілось би зрозуміти культуру компанії, які люди там працюють. Як зрозуміти культуру компанії, якщо поговорив лише з «керівництвом» окремого проекту?

компанія ідентифікує кандидата, яких бажає пройти інтерв’ю із майбутнім керівником і командою, як "чувака з завищеним ЧСВ"©. ну-ну. в сраку таку компанію! :)

спочатку кандидат дивиться/співбесідує
в сраку таку компанію! :)

открою секрет. компания всега показывает девов заказчику) потому как тупо аутсорс уже вымер как движение. остался аутстаф и консалтинг разработка.
Иесли компания нанимает спеца конкретно для клиента то он обычно тоже участвует в собесе. иначе это крайне странно)

открою секрет. компания всега показывает девов заказчику)

Відкрию секрет: не завжди :)

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

Для новых проектов это почти не реально, когда команда набирается с 0. А так да, должен проводить интервью человек с проекта. Иногда кандидата смотрят 2 проекта. Старайтесь избегать в своей речи матов.

я покашто на этой странице исчо не выражался, однако мне несложно, вот, пожалуйста: «хуй». владение табуированной лексикой и уместное её применение позволяет легко отличить человека культурного от ханжеского глупца;)

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

так и мне с глупым ханжой не по пути;)

Ханжа и глупый — это не синонимы и не обязательно вместе, понял?

не понял. давай, объясняй. *попкорн бубльгум*

>

не понял

Мда. Такие тем более не нужны

где не нужны? ну похвали своё болото, ну пожалуйста.

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

отсылка к возрасту является адекватным аргументом? батенька, да ві сраный эйджист ;). люциферсофт — одна из исчезающе малого набора посудин, где возраст сотрудника не препятствует трудоустройству и спокойной работе. не позорь своё дупло.

да ві сраный эйджист ;)

- это тоже эджизм)

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

я хочу также описать здесь хорошую практику приёма в команду, какой я её вижу.

общение с кандидатом разделяется на три фазы.

фаза один: разговор с рекрутёром\хр, уже здесь фиксируется на какую должность, в какой проект и под чьё руководство ведёт маршрут кандидата. по обоюдному согласию проектов\должностей может быть больше одного, однако это должно быть оговорено и согласовано сразу, с указанием всех возможных деталей по каждому маршруту. также на этом этапе рекрутёр при необходимости может проверить знание языка. первый этап заканчивается фиксацией зарплатных ожиданий, кандидату нужно знать на что он собеседуется до начала потери времени на весь процесс. зп может быть оглашена в виде цифры или в виде вилки «не менее чем ххх нетто итого». договорённости, достигнутые на первом этапе, фиксируются писменно в электронном письме от рекрутёра (или любого другого уполномоченного лица) к кандидату.

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

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

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

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

Спасибо, очень крутое предложение! Надеюсь компании возьмут это себе на заметку.

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

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

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

я не ругаю. я глумлюсь :)

зачем?

Точнее это был риторический вопрос.

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

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

просто слово «невежда» можно написать по-разному. например, как «23-летний синиор в кавычках». или, скажем, «начальник пляжа», или может «senior angular 6.2.012 architect», это всё одно и то же, к возрасту объекта отношения не имеет, означает «невежда» :).

да везде разный, где то адекватный, а где то нет)

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

отсеять может только спец из области. Рекрутер вправе работать исключительно по его рекомендациям и не более. Если рекрутер начинает своевольничать его стоит бить палкой больно.

обычно первичный контроль общей адекватности плюс экспресс-проверка владения языком возлагается на рекрутёра и проводится за 10-15 минут по телефону или в онлайне. все британские рекрутёры© так делают :)

Это первичный контроль по тех скилам при масс-рекрутинге. Берут человека который в отличие от HR в состоянии оценить хардскилы на минимальном уровне, что можно проверить на первичном интервью. И только потом уже человек пойдет на собеседование на проект. Условно нужен Java EE а позвали Java Android или наоборот, вот тут и надо проверить. Такие «собеседования» это что то вроде холодных обзвонов клиентов которые делают «менеджеры по продажам».

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

Тут упор скорее на сохранение времени тех кто будет собеседовать. Если убрать скажем менеджера и тех.лида с проекта на неделю потому что они собеседуют людей прямо с рынка, с проектом будет беда скорее всего. Да они и заняты банально. И чем больше контора тем больше уровней воронки найма, в FANNG-ах вроде как до 4-х доходит. А оснащение сертификатом — это так менеджер который это ввел показывает на цыфрах что вот он сократил ошибки найма на столько то процентов потому что первичное собеседование проводят не рандомные балбесы, сами вчера нанятые — а подготовленные собеседователи с бумажкой что они не какашки. По кол-ву бумажек посчитают статистику и покажут руководству с добавлением мы сократили издержки на 25% «вот почему мне надо дать большую премию, повысить зарплату и сделать вице-президентом». :)

Статья не об этом. А о том, как сделать процесс интервью проще и приятнее для кандидата. А откуда вы знаете как проходит найм в компании Intellias? Если это были ваши предположения, то они не верны.

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

Очень негативно отношусь к написанию кода на интервью.
Вопервых это мало что скажет о человеке напишет он или нет. Во вторых это очень много скажет о спецах которые не в состоянии задать 1 каверзный вопрос и поддержать диалог. В третьих это делает интервью нереально долгими. И если таких интервью в 20 компаниях то это фулл тайм работа причем не оплачиваемая.

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

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

Лично у меня все собесы идут в виде беседы, я задаю вопрос, человек отвечает, я делюсь с ним своим мнением. Ну знаете как общаются нормальные живые люди, а не киборги которым на все пох. В итоге я за мин 5-10 уже понимаю интересн мне человек или нет. А главное понимаю сие всецело а не обрывками.
В итоге найм не тех людей у меня за 20 лет работы равен статистической ошибке.

«Как боженька смолвил» =)

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

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

Треба шукати правильні задачі (у мене таких 2-3).
Логіка проста: якщо людину навіть простий кодінг вибиває з колії, то треба дуже подумати, куди така людина потрібна.

Треба шукати правильні задачі (у мене таких 2-3).

У меня тоже есть задача на 10 минут, которую я задаю миддлам (при этом даже код можно не писать, если объяснить решение). Но Senior’ам и выше «простой» кодинг на интервью давать уже бессмысленно. Что Вам покажут у Senior’а 5 строк кода, чего нельзя спросить словами? Ну и сводить кодинг задачу в принципе к «кодингу задачи, которую даю лично я» — неправильно.

Что Вам покажут у Senior’а 5 строк кода, чего нельзя спросить словами?

Вміння кодити :) Є багато «Senior’ів», які класно заливають, але банально не здатні написати рекурсію або простий цикл. Ну і бомбардувати синьйора просто так питання про ікуалс/хешкод або іммутабельні об’єкти виглядає дивно. Ще кодінг задачі або задачі типу «які проблеми ви бачите в цьому коді» показують здатніть людини не просто завчити відповіді, а застосувати зання до прикладної задачі.

Ну и сводить кодинг задачу в принципе к «кодингу задачи, которую даю лично я» — неправильно.

Що саме неправильно? Я трохи не розумію ваше твердження. Якщо що я не стверджую загальності: не говрю, що якщо я знайшов, то і всі інші задачі хороші.
Ефективні кодінг задачі існують. За основу можна взяти деякі з літкоду. Отримаєте крутий інструмент, що вирішує купу базових моментів на співбесіді.

Ну откройте гитхаб да гляньте.. или разраб нанимающий гит читать не умеет?

Ну откройте гитхаб да гляньте.. или разраб нанимающий гит читать не умеет?

У професіоналів гітхаб часто пустий, бо на роботі кодінгу вистачає. Що робити в такому випадку?

***вые это профи) если чел не участвует в опенсорсе для меня он не дев впринципе. исключения лишь джуны.

Жесть, як грубо і суб’єктивно. Таких чєлів більшість і у них часто є дуже великій досвід і хороші скіли.

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

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

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

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

Чергова суб’єктивщина.

Кореляція між проактивністю на роботі і участю в аутсорс тусовці не є доведена. Навпаки, твій продукт може бути не таким цікавим, як аутсорс і дев буде робити на від’єбись, тільки шоб повернутися до тусовки. І навпаки, працівник може втягнутися в продукт, ставити правильні питання, розуміти пріоритети і бути технічно крутим. Крім того сайд продукти можуть бути не опубліковані з різних причин.

У тебе свої абсолютні погляди, але тільки сітхи все приводять в абсолют.

Чуть опечатався — звісно, опенсорс, а не аутсорс.

млин. доу сожрал комент(
Если разные уровни специалисты, и нести свет в массы одна из них. если он до нее не дорос, значит не профик.

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

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

І це теж твоя думка, приведена в абсолют.
Твоє діло чи спонукати працівників до публічності, але з такими вхідними фільтрами ти швидко впрешся в бак кадрів

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

У тебе достатня вибірка шоб знати з ким хочуть працювати люди? За свої заслуги багатьом достатньо грошей і визнання в межах компанії. Вчити публічності це добре, вимагати публічності при скрінінгу — так собі.

за 20 лет да. особенно среди норм девов и людей. Среди тех кого не брал не считал но мне на них откровенно пох.

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

За все время я хз скольких просмотрел и прособеседовал но реально дофига. так что для выборки хватает.

По-перше, не у всіх є час.
По-друге, і по роботі буває така запарка постійна, що не до open-sourcing.

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

А ви точно Solution Architect, що так думаєте?
Скільки я працював в комерційних проектах, ніколи вони не були open-source.

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

github.com/scylladb/scylla
github.com/kubernetes/kubernetes
github.com/hashicorp/terraform
github.com/google-research
github.com/google
github.com/NVIDIA
github.com/facebook

Список можно продолжать вечно.

А вот компании без пабликов мало кому интересны и мало что делают значимое в мире.

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

точно так же дев не может быть лидом без преподавания и выступления на конфах

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

Отакі опенсорсери-виступачі якраз і не завжди вміють програмувати :)

ну да.. куда уж Линусу до опытных неизвестных и секретных девов)

линус вроде как сначала накодил, а потом уже выступать стал

после того как выложил в опен сорс все)

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

Я могу задать очень простые задачи которые никто не решит, а потом скзаать — все ты не шаришь. и толку? мне нада человека нанять а не показать что я когото умнее(тем более что это не всегда так).

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

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

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

однажды я принимал участие в собеседовании, на котором кандидат в программисты не умел написать цикл for ггг, поэтому что-то предельно простое на пять строчек кода я бы всё-таки посмотрел, а то мало ли...

обычно такой и на вопрос не ответит)

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

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

Вміння кодити :) Є багато «Senior’ів», які класно заливають, але банально не здатні написати рекурсію або простий цикл. Ну і бомбардувати синьйора просто так питання про ікуалс/хешкод або іммутабельні об’єкти виглядає дивно. Ще кодінг задачі або задачі типу «які проблеми ви бачите в цьому коді» показують здатніть людини не просто завчити відповіді, а застосувати зання до прикладної задачі.

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

Є багато «Senior’ів», які класно заливають, але банально не здатні написати рекурсію або простий цикл.

То есть, это всё же было не в реальных условиях, а только на собеседовании?

То есть, это всё же было не в реальных условиях, а только на собеседовании?

Що для вас реальні умови?
Один випадок можу згадати, коли співбесіду проводили не ті хто звичайно, фідбек про кандидата «мі-мі-мі, супер спец, так багато всього знає», але довелось звільняти, бо на випробувальному виявилось, що він таки робить багато тривіальних помилок в коді, не пише тести (бо він же сеньйор), код пише в стилі спегетті.

Вы часто говорите о юз-кейсе «подсмотрел и пересказал, сам ничего не сможет»,

Де саме в це цитаті на яку ви відповідали? Відповідайте на те що написано, а не на те що хочете прочитати.

но, во-первых, всё подсмотреть нереально

Все не реально, але якщо замість реалізації бізнес функціональності ходити по конференціях і тд, то почуєш про багато чого :)

во-вторых, если он что-то подсмотрел и __понял__ на уровне тех

До тих хто зрозумів питань немає. Але вя якось просто замінили «пересказал» на «понял». Якщо людина вміє «заливати», то вона буде вести розмову не туди кудиви хочете, а туди де їй зручно, тому, щоб перевірити те що ви хочете треба буде:
— або зводити співбесіду до екзамену і не давати людині розповідати про свій досвід (так собі ідея :) )
— або ви не вийдете за рамки 1-2 години (теж не дуже крута опція)

Що для вас реальні умови?

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

Один випадок можу згадати, коли співбесіду проводили не ті хто звичайно, фідбек про кандидата «мі-мі-мі, супер спец, так багато всього знає», але довелось звільняти, бо на випробувальному виявилось, що він таки робить багато тривіальних помилок в коді, не пише тести (бо він же сеньйор), код пише в стилі спегетті.

Код конвенции, код ревью, контекст проекта?.. Это же не ему решать, писать или не писать тесты, потому что он сеньор)) Ни 5, ни 20 строк про спагетти, кстати, по определению не способны ничего сказать, поэтому в конкретном случае мы снова упираемся, как ни странно, в вопросы, а не в код.

Все не реально, але якщо замість реалізації бізнес функціональності ходити по конференціях і тд, то почуєш про багато чого :)

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

Якщо людина вміє «заливати», то вона буде вести розмову не туди кудиви хочете, а туди де їй зручно, тому, щоб перевірити те що ви хочете треба буде

Это уже проблема вопросов, которые задавать — они должны либо показывать, что человек с этим работал, либо что понимания будет достаточно. Любой вопрос, который начинается с теории, должен затрагивать и реализацию. Если большую часть собеседования проводить в стиле «расскажите о своём самом интересном проекте», то будут проблемы...

щоб перевірити те що ви хочете треба буде:
— або зводити співбесіду до екзамену і не давати людині розповідати про свій досвід (так собі ідея :) )
— або ви не вийдете за рамки 1-2 години (теж не дуже крута опція)

У меня, в основном, 60-75 минут, если кандидат проходит.

У меня, в основном, 60-75 минут, если кандидат проходит.

Скільки тем ви встигаєте проговорити? В мене був кандидат, який 30 хв заливав про мікросервіси, а потім не зміг нічого придумати на питання «Чим мікросервіс відрізняється від просто сервіса?»
Так ось такий «заливаха» в 60-75 хв розповість про 2-3 теми. А в мене навіть у джунів 5+ пунктів які треба перевірити.

Скільки тем ви встигаєте проговорити

Дефолтно для Senior+ в проекты на распределённые системы — 7 тем, до 20 вопросов. Подразумевается, что с ответами на одни вопросы получу заодно и ответы на часть других, поэтому «до 20». На некоторые вопросы человек может не знать ответа или почти не знать, поэтому углубляться смысла нет. Если времени не хватает, секьюрность приложения не спрашиваю.
Для миддлов убираю часть хай-левел вопросов, добавляю кодинг таск на 10 минут и больше спрашиваю вопросы уровнем ниже.
Для джуниоров этот перекос ещё больше.

В мене був кандидат, який 30 хв заливав про мікросервіси, а потім не зміг нічого придумати на питання "Чим мікросервіс відрізняється від просто сервіса

Либо слишком общий вопрос, либо нужно было его останавливать. У меня на микросервисы 4 вопроса: 1 более общий и 3 конкретных, минут за 20 их все можно проговорить. Люди по 40 минут доклады на конференции проводят, а тут 30 минут ответ на вопрос).

Люди по 40 минут доклады на конференции проводят, а тут 30 минут ответ на вопрос).

Тут питання ще важливо розуміти темп. Чувак говорив відносно повільно. На спроби ввічливо його зупинити відповідав щось типу «тут є один важливий момент».
І розповідав цікаво, от тільки в сухому залишку там фактично 0: у них були сервіси між якими була кафка (тоді її ще мало використовували).
Фактично «заткнути» йог вийшло лише питанням вище.

Либо слишком общий вопрос

Питання й було загальним «розкажіть про ваш досвід з мікросервісами в проекті Х».

до 20 вопросов
— або зводити співбесіду до екзамену і не давати людині розповідати про свій досвід (так собі ідея :) )
На спроби ввічливо його зупинити відповідав щось типу «тут є один важливий момент».

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

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

Ну, это всё-таки эдж-кейс,

Угу 30 хв — це дуже едж-кейс. Але навіть у вашому прикладі:
Якщо ми говоримо про «заливах».
20 питань. Полити води 5 хв — це вже 1.5+ години + переключення контексту + відповіді на питання кандидата і маємо:

— або ви не вийдете за рамки 1-2 години (теж не дуже крута опція)

Ніт, т.к. на некоторые вопросы ответ занимает 1-2 минуты (человек не очень в теме и дальше нет смысла спрашивать), а некоторые отвечаются по ходу дела вместе с другими ещё до того, как их задали. В итоге 60-75 минут достаточно.

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

Чем больше человек говорит тем больше можно понять кто он. нужно лшь правильно слушать

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

Ключевое — именно задавать параллельно вопросы и подводить к каким-то ситуациям. Просто слушать полчаса ответ на общий вопрос — нет смысла.

ну это уже проблема интервьювера если он не может нормально диалог строить

чем же интересно отличается сервис от микросервиса) хочу услышать)))

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

1) Код не відміняє питання, а лише є відправною точкою.
2) Диких гівнярів можна відсіяти вже на етапі кодингу. Є ті хто пише простий і зрозумілий код. Є ті хто ігнорує деякі вхідні вимоги, не продумує крайові випадки, дає незрозумілі імена метода і змінним.
3) Про тести теж можна зрозуміти по тих крайових випадках, про які подумав кандидат під час кодінг задачі.

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

По этой причине много плохих проектов, не следуют пирамиде тестирования( ИМХО много интеграционных тестов, говорят о проблемах на проекте

нет никакой пирамиды и паттернов. есть требования в каждом конретном случае и косты.
TDD увеличивает стоимость и уменьшает скорость разработки в 2-5 раз (в зависимости от качества тестов). Очень редкие компании могут позволить себе так тупить. А крупные проекты почти всегда перекладывают тестирование на пользователей для снижения костов. Тот же фб например.

Единственное что всегда покрывается тестами это фин операции. остальное допустимо проебать почти всегда.

Что вы думаете о принципе KISS? Может стоит и ему следовать?
И что главнее KISS или DRY?

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

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

вы ведь не будете писать что то типа lib1.sum(x)*lib2.abs(y)*lib3.dot(x,y) правда?

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

Например один из вопросов на моих собесах:
«У вас есть ММО игра, в ней играет 10М людей онлайн каждый день. Понятно один сервер не справиться, что сделать что бы маштабировать решение на Ное кол-во серверов. И продолжене вопроса. Как быть в случаях если очень много людей собереться в одном месте, например штурм какогото замка?»

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

робить багато тривіальних помилок в коді, не пише тести (бо він же сеньйор), код пише в стилі спегетті

якщо, наприклад, кодобаза проекту вже складається із 30-ти мегабайт монолітних спагетті, і ніяк не можна ізолювати точку входу в новий функціонал, то як не крутись, а на виході все одно будуть костилі із спагетті гівна і палок, така селяві... помилки виловлюються і виправляються на кодревю. чи писати тести і як ними покривати — це конвенція на рівні проекту (або навіть усієї посудини), не написав тести як треба — pull request rejected, та й усе.

якщо, наприклад,

От для чого ви це написали? Як ваші фантазії по ситуації про яку ви практично нічого не знаєте (знаєте лише оціночне судження одного з учасників), допомогають в утриманні дискусію у конструктивному руслі?

це інтернет, дєтка, тут ще й не таке можуть написати ;). з того що ти написав видно трошки дебільну© організацію процесів, де раптом можна писати спагеті без тестів. у випадку нормально організованих процесів поганий код не пройде ревю, а без належного покриття автоматична білд-система не дасть злити його із контролем версій.

з того що ти написав видно трошки дебільну© організацію процесів,

Не з того що я написав, а з того, що ви собі нафантазували :)

Наприклад:

у випадку нормально організованих процесів поганий код не пройде ревю

Де написано, що код пройшов рев’ю?

написано, що учасник команди з власного бажання не пише тести. від проекту, де така позиція в принципі можлива, можна очікувати любого трешу ;)
розгорну трохи відносно спагеті і іншого гінокоду. так, спагеті гівнокод існує. так, будь-хто з нас хоч раз (а може і не раз) осмислено писав такий код. але із сферичного факту в вакуумі «ааа, вася пупкін написав спагеті!!111» абсолютно нічого не випливає, бо потрібно розуміти контекст, в якому знаходився автор, може так виявитись, що представлене рішення проблеми єдино можливе або навіть геніальне.

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

Проблема не в кодинге. А в том что задачи даются не типичные для простого программиста и еще создаются условия не привычные, типа пиши в блокноте. Что может многих ввести в ступор и человек не покажет даже 30% своих возможностей. Задача интервью, найти подходящего кандидата и дать ему раскрыться на 100%, а не перепугать человека странными задачами.

мне вот недавно в интервью на должность Дата Архитектора в МЛ проект задали вопросы типа:
А напишите мне:
— функцию 2d convolution
— постройте график PR & ROC Curve
— и какойто алгоритм поиска ответов на графе, путем двойного прохода.

При этом все нада написать на чистом Python без использования сторонних либ типа даже Numpy.
На вопрос типа «давайте я вам просто обьясню логику работы», сказали — нет, пиши.
В итоге я как то с горем попалам написал, них не оптимизировано и в реале такое юзать нельзя.. не ну а что еще можно написать за 15 мин, я наизусть не помню как лучше развернуть массивы на ГПУ, что бы оно быстро посчиталось, да и не надо оно сейчас есть куча автогенераторов которые решают эту боль типа Halide
Причем идея типа была увидеть насколько я могу реализовывать пейперы с нуля в коде.
Хотя казалось бы а почему тогда не дать пейпер и не попросить его реализовать? а хрен его знает.

Причем веселье еще и в том что это вообще млин никак не относиться к той работе которую я должен был делать)

При этом собеседующий общался как робот по чеклисту.
И это одна из топ компаний США)

Да, совершенно верно! Мне было бы интересно услышать мотивацию задавать такие вопросы. Рекомендую всегда спрашивать зачем дают задачу и какие цели преследуются? проверить знание алгоритмов, паттернов или проверка качество написания кода.

ну вот у них была причина

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

Тока не ясно как согласуется задача и причина)

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

Ну и главное такие тестовые задания показывают лишь
естть опытный дев но который например не работал с фреймом о котором его спрашивают

Давайте визначимось з термінологією:
Кодінг задача — не є тестовим завданням. Кодінг задачі (правильно зроблені) не перевіряють знання фреймворку (максимум перевіряють знання стд бібліотеки).

---

На більшості інтерв’ю даю задачку на 5-20 строк коду. Тут звісно є складність — підібрати таку задачу, взяти шопопало з літкоду — результату не буде (в основному, бо ті задачі є тренувальними на якусь 1 техніку/підхід).

Очень негативно отношусь к написанию кода на интервью.
Вопервых это мало что скажет о человеке напишет он или нет.

Скаже. Якщо не здатен навіть вичавити з себе 5 строк коду — в ресайкл. Тут важливо розпізнати стрес і направити кандидата який зайшов в ступор. Як результат ще й перевіряємо як ви можете комунікувати між собою.

Во вторых это очень много скажет о спецах которые не в состоянии задать 1 каверзный вопрос и поддержать диалог.

Каверзне запитання — це погана практика для інтерв’ю, бо перевіряє просто співпадіння досвіду інтерв’юера і кандидата, а не знання кандидата.

В третьих это делает интервью нереально долгими. И если таких интервью в 20 компаниях то это фулл тайм работа причем не оплачиваемая.

1) Якщо кандидат не впав в ступор, то 10-20 хвилин кодінг задачі та розмови по результатам дають можливість закрити всі базові теми по мові програмування і сусідньому тулінгу (тестові фремворки, утіліти, тули для білда і тд). Якщо тупить, то може зайняти до 40 хв, але це все ще економніше тестового завдання додому і дає більше інформації про кандидати.
2) 20 компаній? Такий чувак має страждати — по явно не вміє пріоритезувати :)

В итоге я за мин 5-10 уже понимаю интересн мне человек или нет. А главное понимаю сие всецело а не обрывками.
В итоге найм не тех людей у меня за 20 лет работы равен статистической ошибке.

Так, уявлення про людину складається за перші 5-10 хв.
Проблема в іншому:
Ви вирішуєте задачу «не найняти неправильну людину» або ще гірше «найняти людину під себе». Така постановка не завжди корисна для компанії в яку ви співбесідуєте людину. Як сайдефект маємо ще й непрозорість відмови — через рік (або скоріше через місяць) ви не згадаєте чому відмовили тій чи іншій людині і не зможете пояснити менеджеру з сусіднього проекту чи варто брати того кандидата їм чи ні.

Конструктивніша позиція — «не пропустити гарного кандидата». І ось тут з’являється необхідність шкали оцінювання і усіляких матриць компетенцій.

Кодінг задача — не є тестовим завданням. Кодінг задачі (правильно зроблені) не перевіряють знання фреймворку (максимум перевіряють знання стд бібліотеки).

Они ничего кроме памяти не проверяют. увы. а заучивать на память путь в гавнокодеры.

На більшості інтерв’ю даю задачку на 5-20 строк коду. Тут звісно є складність — підібрати таку задачу, взяти шопопало з літкоду — результату не буде (в основному, бо ті задачі є тренувальними на якусь 1 техніку/підхід).

Задача в вакууме для проблемы в вакууме, когда нам например нада ТТС генератор на проекте писать. Отлично. что может пойти не так?)

Скаже. Якщо не здатен навіть вичавити з себе 5 строк коду — в ресайкл. Тут важливо розпізнати стрес і направити кандидата який зайшов в ступор. Як результат ще й перевіряємо як ви можете комунікувати між собою.

А зачем вообще на человека давить? или это жизненная позиция у всех на постсовке?
Мне вот лично нра с людьми просто говорить.

Каверзне запитання — це погана практика для інтерв’ю, бо перевіряє просто співпадіння досвіду інтерв’юера і кандидата, а не знання кандидата.

Отличная. просто нада знать что спрашивать. Ну простой пример «Я слышал что некоторые разрабы отключают сборщик мусора в Пайтон и вызывают его вручную, как по мне это хреновая идея так как не дает ему возможность адекватно собрать статистику для максимального освобождения ресурсво. А что думаете вы?» — и вот тут мы видим сразу работал ли человек в хайлоад или нет. Пару таки вопросов и картина понятна.
И данный подход подтвержден 20 годами моей работы. даже могу забиться с кемто.

1) Якщо кандидат не впав в ступор, то 10-20 хвилин кодінг задачі та розмови по результатам дають можливість закрити всі базові теми по мові програмування і сусідньому тулінгу (тестові фремворки, утіліти, тули для білда і тд). Якщо тупить, то може зайняти до 40 хв, але це все ще економніше тестового завдання додому і дає більше інформації про кандидати.
2) 20 компаній? Такий чувак має страждати — по явно не вміє пріоритезувати :)

1) пока вы будете изнемогать на этих чудо задачках мы уже будем бухать с моим новым сотрудником)
2) вы видимо слабо понимаете что такое торги)

Так, уявлення про людину складається за перші 5-10 хв.
Проблема в іншому:
Ви вирішуєте задачу «не найняти неправильну людину» або ще гірше «найняти людину під себе». Така постановка не завжди корисна для компанії в яку ви співбесідуєте людину. Як сайдефект маємо ще й непрозорість відмови — через рік (або скоріше через місяць) ви не згадаєте чому відмовили тій чи іншій людині і не зможете пояснити менеджеру з сусіднього проекту чи варто брати того кандидата їм чи ні.

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

Конструктивніша позиція — «не пропустити гарного кандидата». І ось тут з’являється необхідність шкали оцінювання і усіляких матриць компетенцій.

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

Они ничего кроме памяти не проверяют. увы. а заучивать на память путь в гавнокодеры.

Задача:
Дано
interface File {
String name();
List innerFiles();
boolean isDirectory();
}

Роздрукувати вхідний файл у вигляді дерева
root_name
-file1
-dir1
—file11
—file12
-file2
-file3
-dir2

---
Що ви тут запам’ятовувати зібрались?

а что вы тут смотреть собрались? особенно у синьера? лишь то что вы не сделали ДЗ и посему задаете ему тупые вопросы? я обычно на таком просто выключаю кол и иду общаться со следующей компанией.

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

лишь то что вы не сделали ДЗ и посему задаете ему тупые вопросы?

Ні. Тут багато чого перевіряється, наприклад вміння працювати з вимогами.

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

Угу, м...ків ця задачка теж круто відсіює :)

Ви так і не відповіли:

Що ви тут запам’ятовувати зібрались?
Ні. Тут багато чого перевіряється, наприклад вміння працювати з вимогами.

С какими требованиями? Вы серьезно?) у меня в работе требования на страниц 100-400 текста. а тут у вас три строчки и это типа опыт работы с требованиями?)
С таким же успехом вы можете попросить пописать на зажигалку и по этому понять насколько человек хорошо в тушении нефтяных вышек.

Утопическая экстраполяция просто)

Угу, м...ків ця задачка теж круто відсіює :)

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

Я уже молчу о том что бы иметь мужество сказать это в глаза)

Як можна сказати в очі шось істеричці яка

просто выключаю кол

?
По ІП вираховувати? :)

щетаю отлична задача шобы сразу отсеять школоло с рекурсиями ;)

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

Согласен. Просто есть люди которые задают задачи. И рекомендация для них.

негативно отношусь к написанию кода на интервью

No code no hire.

да госпаде дерзайте) ваше же время и ваш же ПР))

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

А тепер уявіть собі, що людина взяла звідкись класний прилизаний проект, ну може трохи поміняла і виклала до себе на github.com.
Ви що, будете нишпорити по всьому Інтернету в пошуках збігів? Так стопудово, що не будете і візьмете цього «умільця» до себе на роботу.

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

Например когда запускался letsenhance.io и сп***или чужой код выдав его за свой мне потребовалось буквально пару сек что бы понять что спиздженно. О чем даже статью написал. Которую ребята потом слезно молили удалить ибо она в топе выше их сайта весела))

Так что просто какойто код это вообще фигня) Ну а вообще найти в сети я могу очень многое помимо этого.

пару запросов в гугле и я уже понимаю звать мне человека на собес либо не стоит

Цей фільтр працює в обидва боки — не кожному підійде компанія в якій вимагають у вільний час пиляти якийсь опенсорц замість жити.

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

с человеком для которого выбранная им стезя просто обмен времени на бабло

Я свою «стезю» почав коли в програмуванні грошей ще не було і навіть паралельно працював на інших роботах щоб щось заробити. Так що мимо — займаюся тим, що приносить задоволення і в що вірю.

человек должен

Ніхто тобі нічого не винен. Ця спроба морально тиснути може і працює з новачками, але лише з ними.

стремиться к большему, творить

Я і прагну — заробляти більше роблячи більше і краще. Також не зрозуміло чому творити не можна в межах роботи і чому це має бути за безкоштовно.

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

Ніхто тобі нічого не винен.

так он не мне должен а себе. если хочет оставить какойто след в этом мире и прожить жизнь не просто так.

Но в целом это нереально обьяснить человеку что такое искусство если он этим не болеет, это как слепому обьяснять картину мира.

творчество это творчество, оно не подвласно рамкам

І тому ти наділяєш себе правами вирішувати, що є творчістю, а що ні? Зручно.

так он не мне должен а себе

Так він не винен взагалі.

если хочет оставить какойто след в этом мире

Прямо Македонський від укро-ІТ.

прожить жизнь не просто так

А іншого способу «не просто так» крім опенсорс замість життя нема?

нереально обьяснить человеку что такое искусство если он этим не болеет

Покажи приклади свого мистецтва яким ти хворієш — вірші, музику, малюнки, чи що ти там робиш щоб лиши слід в цьому світі.

это как слепому обьяснять картину мира

Цей пафос буде переконливим хіба для мрійливих 13-річних задротів.

І тому ти наділяєш себе правами вирішувати, що є творчістю, а що ні? Зручно.

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

Так він не винен взагалі.

Ну в таком случае диван + телек его судьба. раз развитие и рост у него не к месту.

Прямо Македонський від укро-ІТ.

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

А іншого способу «не просто так» крім опенсорс замість життя нема?

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

Покажи приклади свого мистецтва яким ти хворієш — вірші, музику, малюнки, чи що ти там робиш щоб лиши слід в цьому світі.

medium.com/...​t-from-linux-a5bd2f36d3ad
github.com/creotiv/hdrnet-pytorch
learnml.today
www.patreon.com/uah
promisto.socialboost.com.ua/ideas/view/482
500px.com/...​dreynikishaev?view=photos
medium.com/...​-recognition-c031eac726f9
medium.com/...​n-and-opencv-166937911660
www.slideshare.net/anikishaev

Цей пафос буде переконливим хіба для мрійливих 13-річних задротів.

Тогда обьясните как вы слепому которы никогда не видел обьясните что такое солнуе, небо, горы, голые девушки) И посмотрим дотягиваете ли вы до 13летнего по вашим же меркам

я говорю что творить по будильнику увы нельзя

А я кажу що можна.

если посмотреть на деятелей искусства то я еще не видел ни одного который «так уже 6 часов, все прекращаю творить»

В реальності люди які займаються мистецтвом працюють за розкладом, мають плани, цілі та способи перевірки якості зробленого.

диван + телек его судьба. раз развитие и рост у него не к месту

Опенсорс замість життя ніяк не стосується «розвитку і росту».

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

Або не світові проблеми, або займатися чимось іншим, або взагалі нічим.

Но это п****ц как сложнее чем работать в той сфере в которой ты разбираешся

Життя має приносити задоволення, а тому треба займатися тим, що приносить задоволення, або взагалі нічим якщо саме це додає щастя у житті.

500px.com/...​dreynikishaev?view=photos

Для мене лише ось це творчість, все інше — робота інженера.

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

З якою ціллю треба пояснювати? Бо це не складно насправді. Скажімо Сонце — зірка навколо якої обертається в тому числі наша планета. І так далі.

дотягиваете ли вы до 13летнего по вашим же меркам

Я їх перетягую, бо цей пафос про «людина винна <тут підставити вигадки будь-кого, кому людина щось винна>» на мене вже не діє дуже давно.

З якою ціллю треба пояснювати? Бо це не складно насправді. Скажімо Сонце — зірка навколо якої обертається в тому числі наша планета. І так далі.

Этим можно подытожить весь наш спор.

Життя має приносити задоволення, а тому треба займатися тим, що приносить задоволення, або взагалі нічим якщо саме це додає щастя у житті.

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

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

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

Вам почемуто кажеться что сидеть и ничего не делать это удовольствие.

Тобі чомусь здається, що мені так здається.

А насправді я знову і знову повторюю, що пиляти опенсорс замість просто жити — задоволення для небагатьох і якість його сумнівна.

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

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

А сидеть на диване и них не делать это не удовольствие это пытка для мыслящего существа.

За скільки ти пробігаєш 10 км і що робиш щоб це час був швидше за 30 хвилин? Як нічого — любиш сидіти на дивані і нічого не робити?

Это как сравнивать дрочу и секс.

І опенсорс тут що?

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

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

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

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

Но проблема в том что это не более чем иллюзия счастья.

А вот теперь внимание вопрос, только сперва уточнение.
У нас только одна жизнь, и после нее ничего нет. А теперь поясни чем иллюзия счастья отличается от счастья. Вот аргументативно?

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

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

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

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

А у вас в команде точно есть куда развиваться?
После сеньора, куда дальше? Сколько позиций тимлидов в команде? Одна или две?
А то все говорят развивайся, а потом оказывается что для поднятия ЗП проще уйти в другую компанию.

И вообще, обычно на работе нужно работать, а развиваться — это хороший бонус.

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

На співбесіді питають зазвичай те, що важливо компанії чи проекту. Якщо не просять писати код, значить написання коду для цієї позиції не важливе. Правило підтверджене моїм досвідом,

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

Написание кода никогда не было главным где либо. Главным всегда есть клиент, продукт, профит. А код не более чем один из инструментов. И тут вопрос, компания хочет роста профита или написание кода? Это как «вам шашечки или ехать?»

Якщо питають про те, що не потрібне потім в роботі, то це погане інтерв’ю в незалежності від імені компанії.

это к сожалению довольно типичный кейс(

І це конкретно кейс не розуміння того, що перевіряють в процесі інтерв’ю і як «неправильний процес» гугла дає їм можливість наймати найкращих і вигравати у конкурентів.

Це неоднозначне питання.
Якщо у вас співбесіда проходить в форматі питання/відповідь, то може виявитися, що кандидат підкований в теорії, а на практиці не те що плаває, просто дуже багато думає або пише поганий код, або йому потрібно постійно лізти в Google для підказки.
так що написання коду дуже багато чого показує.

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

А вот нанимать тупоголового кодера — это 100% потеря денег и времени.

Ви не зрозуміли мене.
За що ви платите співробітникові в компанії? За те, наскільки ефективно він працює (це ж самі рядки коду) або за те, що він круто розбирається?

Это сложный вопрос, часто не понятно за что платят человеку.

а зачем смотреть за что ему платят. нада смотреть на ROI. в плюс отлично в минус плохо. все.

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

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

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

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

остальные пункты всецело поддерживаю

он должн нравиться тем с кем он будет работать. если он людям не заходит то пох какой он там спец. Ну простой пример. Есть кул спец.. и тут оказывается что он за Путина. Будете брать?

Я с вами согласен. Но когда один член команды сказал, а давайте нанимать не крутых людей, а крутых специалистов) Еще мое мнение изменила книга про netflix «Никаких Правил».

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

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

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

уже лет 100 ни один специалист даже уровня Лейбница или Эйнштейна нихреа сам не сделает.

Бьярн Страуструп и Линус Торвальдс всё же сделали сами. Можно тут ещё вспомнить и Стива Джобса со Стивом Возняком...

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

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

ну канешь.. он такой прям так и вижу как в биографии пишет «меня какието два гопника отп***или».. после такого репутация конечно же не упала бы))

прям так и вижу как в биографии пишет «меня какието два гопника отп***или»

Ояма в своїй книзі так і написав як його два гопніка в Гарлемі загнали в якісь руїни і вирубили та обібрали. І нічого — міфічна особистість, створив найбільшу в світі організацію бойових мистецтв яка в найкращі роки кількістю учасників та грошей могла посперечатися з найпопулярнішими олімпійськими видами спорту.

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

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

Когда то проходил собес в гугл.. задавали кучу всего.. реально пипец сложно. А потом я занимался какойто убогой хренью. Вопрос.. зачем были эти сложности при найме?) ответ простой — мы так для всех делаем. Сразу вспоминается СССР и то что все люди одинаковы..

Я ходила на собес в Револют. Написала код, потом тесты, получила фидбек, что они ожидали тесты, а потом код. Осталась в недоумении. Позиция была backend developer, что-то там за тестировщика-автоматизатора сильно не писали. И в Гугл тоже ходила, задачка была легкая, но я с трудом распарсила самого интервьюера, у меня был поляк. Самые классные интервьюеры для меня это в Майкрософте. Очень было приятное впечатление от общения.

С револют порешали, там походу чето перепутали, как оказалось делать рхитектуру в коде на коленке не надо.

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

Підписатись на коментарі