Рецепт адекватної співбесіди, або Викиньте у смітник свої запитання

Привіт, я Вова. В android-розробці 6-й рік. За цей час провів кілька десятків співбесід та пре-скрінів, як і до себе в команду, так і в паралельні команди в компанії, допомагаю людям шукати їхніх перших android-розробників. Але пишу я цю статтю зараз не тому, що сам раніше проводив погані співбесіди, а тому що зрозумів, що на ринку найму України багато компаній проводять технічну співбесіду, після якої не хочеться йти до них працювати. І цим текстом я хочу підняти рівень співбесід в Україні. Приклади будуть з android-світу, але загальні рекомендації будуть без прив’язки до спеціалізації.

Для кого ця стаття

Для людей, які проводять співбесіди. Мої поради допоможуть вам виділятися на фоні інших співбесід. Кандидати часто спілкуються з кількома компаніями одночасно. Це позитивно вплине на бренд роботодавця, і за рахунок цього з кожним разом до вас будуть приходити все більш кваліфіковані кадри.

Всі не мають рації, а я Д’артаньян, який вам все розкаже

Усі матеріали, які є щодо співбесід для android-розробників в Інтернеті, це повна фігня. Це звучить доволі жорстоко, але так і є, причому англомовний Інтернет не є виключенням. Усі статті, які я бачив, — це просто список питань, на які кандидат має вивчити відповіді. Причому багато з цих питань явно відстали від індустрії на роки, ви потрапите на них виключно тому, що в Google ці посилання мають велику «вагу». Моя рекомендація — припиніть питати людей по списку, питайте тільки те, що потрібно вашій команді, приділіть багато часу system design (якщо це треба вашій команді).

Наприклад, стандартне запитання в усіх списках — це життєвий цикл activity/fragment. Останній рік я працюю в команді, яка не використовує ні fragment, ні activity, тому я не буду нічого запитувати в кандидата з цієї теми. Звичайно, більшість android-розробників знає життєві цикли, але якщо команда, в яку йде кандидат, не використовує фрагменти/актівіті — ці знання не мають значення.

Встановіть правила гри

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

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

На початку співбесіди варто озвучити кандидату «правила» співбесіди, для прикладу:

  1. В нас не можна казати: «Тому що так правильно».
  2. В нас не можна апелювати до авторитетів.
  3. В нас кожну свою думку треба підтверджувати аргументами.
  4. Аргументом може бути особистий досвід кандидата на попередніх проєктах.
  5. Нам важливо, що ти думаєш, а не те, що думають автори якихось статей чи книг.

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

Перестаньте запитувати в людей константні значення з java stdlib. Думаю, тут нічого пояснювати не треба. Якщо в вашій роботі важливо їх знати, включіть їх в welcome pack для вашої команди, нехай на ноутбуці, який компанія відправить кандидату, буде на робочому столі файл з усіма потрібними константами. Константи — це лише приклад, сюди можна віднести сигнатури методів чи деталі імплементації бібліотеки.

Не питайте теорію

В теперішньому проєкті є багато роботи з потоками і синхронізацією даних між потоками. Та ми дійшли висновку, що ніяких питань з теорії synchronized, mutex ми ставити не будемо. Ми просто ставимо перед кандидатом задачі, які вирішуємо щодня, і питаємо, як би він їх вирішував. З цього ми вже розуміємо, чи знає кандидат, як працювати з потоками. Що ж робити, якщо в вашому проєкті немає обробки даних на різних потоках, а запитати про race condition хочеться? Відповідь тут тільки одна: стримуйте своє «хочеться».

Не питайте те, що не потрібно

Не треба питати те, що у вас не використовується, це стосується і ширини, і глибини питань. Для прикладу: нормально запитати кандидата про TextView та форматування тексту, якщо це використовується в проєкті, але немає ніякого сенсу питати деталі імплементації RTL, якщо проєкт його не підтримує. Може бути винятком, коли кандидат — цікава людина, і вам просто цікаво порушити тему глибше. Я все кажу кандидату прямим текстом: «Ми це не використовуємо, мені просто цікаво, що ти думаєш на тему...», і далі порушуємо цікаві питання щодо теми.

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

Ви не FAANG

Звісно, рівнятися на кращих — це правильно, але не треба їх копіювати. Це виглядає, наче діти на YouTube граються в телевізор. Тільки компанія з тисячею девелоперів грається в Google. Перестаньте робити інтерв’ю, як у Netflix. Зрозумійте одну просту річ: Facebook бере людей з тих, хто хоче в Facebook, а ви — з тих, хто залишився на ринку. Вхідна воронка цих компаній дозволяє їм поставити практично будь-які умови на вхід. Тому викидаємо питання про червоно-чорні дерева, якщо вони у вас не використовуються.

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

Ще один великий мінус — ставити запитання про алгоритми. До вас може прийти людина, яка займається олімпіадним програмуванням, і, скоріш за все, сильніша за вас у цій темі. І резюме вас від цього не захистить, я, наприклад, ніде не вказую, що брав участь в АСМ-ІСРС, просто тому, що це немає ніякого стосунку до роботи.

Отже, основна думка: кількість інженерів, які хочуть в FAANG і при цьому просто добре роблять прикладні задачі, настільки велика, що ці компанії вимушені додавати запитання про алгоритми. У вашому випадку немає такої високої якості вхідної воронки кандидатів, тому перестаньте питати алгоритми, які вам не потрібні.

Візьміть з собою друга

Не йдіть на інтерв’ю один, беріть ще когось із команди. Це треба з наступних причин.

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

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

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

Bus factor. У певний момент ви можете сісти в автобус і поїхати у відпустку. А якість інтерв’ю не повинна впасти під час вашої відсутності, і цього не станеться, якщо є людина, яка провела з вами багато інтерв’ю. Можна підготувати кількох таких людей, що ще збільшить bus factor, але це вже залежить від розміру команди.

З мінімальним числом кандидатів все зрозуміло. А що з максимальним? Не треба брати на інтерв’ю половину компанії. Як мінімум, це дивно і психологічно дискомфортно. Максимум — це два інженери, які питають, і один, який слухає. Той, хто слухає, виключно, щоб послухати, як ви проводите інтерв’ю, і важливо кандидату одразу сказати, що ми готуємо нову людину, яка буде в майбутньому проводити інтерв’ю, тому він буде просто слухати, усі ми маємо вчитися. Адекватний кандидат це зрозуміє. Важливо, що ця людина дійсно має мовчати/бути на mute весь час інтерв’ю.

Питання від кандидата

Тут наче все просто. Але є один момент: просто дати можливість поставити кандидату запитання — це не те, що треба. Тому що кандидат не Ванга і не знає, як написаний ваш проєкт. Тут краще коротко переказати ReadMe проєкту.

Мій приклад

Наша команда пише продукт, який називається SportsBook. Команда розробляє бібліотеку, яку інша команда інтегрує в додаток. Бібліотека включає як UI, так і усю роботу з даними і бізнес-логіку продукту. Для socket використовуємо OkHttp, для rest — retrofit, dependency injection пишемо руками, ViewModel, там, де UI на compose, використовуємо гуглові, там, де старі view, використовуємо самописні, вони такі ж, але дозволяється працювати з view як з самостійним елементом.

В нас є своя кодогенерація, тому що в нас свій формат спілкування з back-end і, відповідно, самописні бібліотеки для серіалізації даних. Для dataflow раніше використовувалося самописне рішення, схоже на RxJava, зараз в процесі переходу на Flow. Для збору використовуємо Gradle. Стек для тестів — juint 5 та mockk.

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

Рецепт

Один етап на дві години. Для когось це мало, для когось — багато. Як на мене, це мало, але і мало який кандидат витримає більше. А робити два технічних етапи реалії ринку вам не дозволять: нагадую, ви — не FAANG.

1. Попросіть кандидата розказати про його досвід. Скоріш за все у розповіді кандидата буде цікавий проєкт або цікава вам технологія. Уточніть усі моменти, які вас цікавлять з досвіду кандидата. Це дасть розуміння, наскільки кандидат брав активну участь у розробці того, про що він говорить.

2. Задача. Я просто описую дуже спрощену версію продукту та NFR (в нашому випадку — швидкість доставки інформації і економія трафіку) і прошу кандидата описати, як він бачить розробку цього продукту. Спочатку — в загальному плані, потім переходимо до деталей реалізації UI та роботи з даними. Тут важливий момент, що в нашій задачі немає бізнес-логіки, не треба думати, що кандидат буде знати ваш домен. В моментах, де ми знаємо, які проблеми виникнуть, ми питаємо кандидата, як би він їх вирішив. Тут ми і дізнаємось, чи вміє кандидат вирішувати проблеми race condition, і при цьому ми не ставимо питання в лоб: «Що так mutex?», тому що мені мало того, що кандидат знає, що таке mutex, я хочу, щоб він сам сказав, що його тут треба використати.

3. Переказуємо ReadMe проєкт. І відповідаємо на запитання кандидата.

Короткі висновки

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

Посилання:

Обговорення теми співбесід в подкасті Android Story

Тред в Twitter про кількість людей на співбесіді

👍ПодобаєтьсяСподобалось28
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Цікавий підхід, але як на мене, то зовсім не підходить для продуктової компанії, хоча ви стверджуєте протилежне. Аргументувати довго, тому наведу приклад:

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

Проблема того що на проекті використовується не правильний інструмент, в вашому прикладі блокнот а не IDE, немає вирішуватися співбесідами :)

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

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

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

обращаться к законам Ньютона

обрати внимание ты сам пишешь «обращаться к законам» они просто называются имярек это вовсе не есть «обращаться к самому авторитету личности имярек»

вместе с тем классические законы имярек более чем практически применимые в классической механике могут быть «притянуты в качестве авторитета» и в других сферах и вот тут уже это начинает работать как именно «апеллировать к авторитету» при чём здесь 2 медали № 1 это «авторитет как авторитет» и № 2 это «авторитет так ведь других нет»

ЗЫ: на последнюю тему есть не менее классический анекдот за блох

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

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

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

потому что при ссылках на умных дядек происходит очень конкретная формулировка «мение тов. имярек» (к) (тм) и ключевое слово здесь _мнение_

они на то и умные

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

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

(Я .Net Interview performer-2021 на N-iX)

Ну це звучить сильно страшно, тому вирішив написати варіант пом’якше :)

Та трохи чорногуморно, але й життєво, бо тоді досвід ніхто не спланував передати.

По этой логике я на собесах должен был у фронтов из верстки спрашивать только флексы с дивами. И большинство бы по такому принципу прошло, не зная ни что там было до CSS3/HTML5 ни собственно их в полном объеме.

Хотя изначально посыл статьи был правильный — спрашивать нужно по стеку проекта, а не тупо топ-10 вопросов по профе.

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

Вы паттернами с ООП кого собеседовать собрались, выпускников го-айти?

Раздел HTML/CSS у всех фронтов я спрашиваю. Вы даже не представляете сколько людей на нем поплыло с претензией на синьйоров (и особенно фул-стеков). Просто потому что CSS3 забыли, а HTML5 так и не читали (кроме тегов header/tooter).

понятие движка

Какого движка, если почти все проекты сейчас сводятся з «забрать json, положить в redux и порендерить когда надо»?

А толку спрашивать с человека больше, если он не знает как подвинуть квадрат на 10 пикселей, а потом из этого квадрата сделать круг.

А генералы быстрее всех разбирают-собирают калаш... Боже мой, и эти люди кого-то собеседуют...

Генералы быстрее всех разбирают и собирают дачи.

Пропоную ще кращий варіант: берете п′ятьох кандидатів та босса, що грає роль кандидата. Зачиняєте в одній кімнаті,...

Якщо хтось не дивився метод Грьонхольма в театрі, дуже рекомендую. Але спочатку дізнайтеся, хто ставить (можете тізер глянути чи іншу гру акторів), бо це геніальна п′єса, яку досить легко спаскудити поганою грою. В цій п′єсі нема дурнів. Навпаки, найрозумніші люди, і одного з них мають обрати. Справедливістю там звісно ж і не пахне, тому так важливо грати розумну роль, а не підказувати глядачу наступний хід.

Спойлити не буду. Фіналочка там нетипова, частково відкрита (дозволяє додумати), але точно не те що варто піддивлятися, бо тоді буде нецікаво.

Для лінивих є кіноверсія. Як на мене, в театрі воно ефектніше.
PS. Метод — справжній, він реально існує, і є ефективним.

Вітаю з досягненням піку Данінга-Крюгера. Далі вам обирати — вниз чи вгору. Шлях вгору нічим не обмежений :)

Dependency inversion пишемо руками...
Там точно про inversion, а не injection?

Не точно :) дякую поправлю

А вообще со всем согласен. Спасибо за статью.

Файна стаття. Саме те чого й бракує переважній більшості місцевих компаній.
Навіть доколупатись нема до чого :)

Класна стаття, багато по темі. Як людина яка провела 100+ інтервю і брала участь в процесі створення інтервю в Atlassian, поділюсь своїм досвідом (можливо це не актуально для України).

Я б оцінював технічне знання кандидата за 3 напрямками:
— Coding
— Technical Knowledge
— Problem Solving / System Design

Coding — тут є декілька підходів, мені найбільше подобаються:
— live coding, простенька програма в якій щось не працює (можна оцінити як кандидат пише код, підхід до пошуку багів, написання тестів, робота з IDE)
— pull request review, надати кандидати перевірити ваш заздалегіть підготовлений pull request (можна оцінити наскільки уважно кандидати перевіряє код, які і скільки коментарів напише)

Technical Knowledge — це звичайний Q/A по технічній частині (теорія), дає зрозуміти експертизу кандидата в доменній області. Зазвичай на одне і те ж запитання Junior, Middle, та Sr. дадуть різні відповіді (менш та більш розгорнуті). Також це дасть зрозуміти чи варто переходити до етапу Problem Solving / System Design.

Problem Solving / System Design — схожий підхід який описаний в статті (задача) але не звязаний з конкретним проектом (наприклад розробити бібліотеку по відправці логів чи аналітики), бо оцінити відповідь на базі проекту який у вас є буде важко. Проектів може бути багато, є простіші а є складніші, виходить оцінка кандадатів буде не справедливою.

Одна з найбльших проблем в інтервю процесах inconsistent interview experience.


When it comes to interviewing, don’t trust your gut. More often than not, your gut reaction isn’t a product of hidden wisdom.

Rather, it’s a result of unacknowledged biases that can lead you to overlook strong candidates who might not line up with your expectations.

Instead, aim to create an interview process that’s as structured and consistent as possible so that people can showcase their skills and highlight their experiences.

Then, let the data help you decide how to move forward.

Laszlo Bock, author of Work Rules

Laszlo Bock was Google’s Senior Vice President of People Operations, responsible for attracting, developing, retaining and delighting «Googlers.»

Повністю згідний, але на це треба більше ніж дві години, а реалії сучасно ринку вам не доводять витрачати більше часу кандидата

Coding — тут є декілька підходів, мені найбільше подобаються

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

Стаття могла б бути непогана, якби не оце:

І цим текстом я хочу підняти рівень співбесід в Україні.

бо написано дуже специфічно як для андроїда так і для паріматча

Підняти рівень, знаходячись в паріматчі можна хіба що до рівня «хуцпа». В Україні це цілком профітний рівень, навіть по морді не б′ють поки що.

В нас не можна апелювати до авторитетів.

Че

В вас є проблеми з цим пунктом ? Так в мене на інтерв’ю не можна сказати так правильно тому що так написано на заборі.

Так цеж правильно, людина должна розбиратись у всьому сама

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

Блин то я дурак и читать не умею, все верно

В вас є проблеми з цим пунктом ? Так в мене на інтерв’ю не можна сказати так правильно тому що так написано на заборі.

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

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

Мені не потрібні аргументи які мене переконають , тому що тоді це буде інтерв’ю не на програміста а на людину яку вміє спорити

Ще раз

джуни-мідли не завжди мають достатньо досвіду і теоретичних знань

Чим людина має аргументувати свою позицію не маючи досвіду і __глибоких__ теоретичних знань? Це нас повертає до рівня аргументації в статті.
А ще сперечатись — це не ціль, а інструмент для вибору оптимального рішення (принамні в нетоксичних колективах)

мені цікаво на співбесіді побачити хід думок, тому я забороняю апелювати до авторитета

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

джуни-мідли

та хай Блог милує, які ще джуни-мідли

Є речі в яких нормально розбирається 10-100-1000 людей у всьому світі, згадай наприклад епопєю з openssl та Debian. Там жеж тако само полізли в код бо знали як буде луччє, сініори наверно всі були

Аргументи від авторитета мають місце, навіть в академічній науці, але вони визнавались найслабкішими ще в древньому Римі.
Здається, більше 2х тисяч років з тих пір минуло, але проблема тільки поглибилась. Корінь в тому що людина не може бути професіоналом геть у всьому : їй елементарно не вистачить часу її життя. Тому людина змушена покладатися на думку експертів у тих областях знань, де вона такою не є. І сліпо покладаючись на думку такого есперта без жодних аргументів, чи то на думку простої більшості людей (це теж аргумент від авторитета більшості) — ви й потрапляєте у дану пастку.
А ось (далеко неповний) перелік факапів авторитетів: habr.com/ru/post/556354

Таки справа у тому, які авторітети і в чому. Якщо «не можна писати геттер, тому що великий Джонс заборонив», це одне. А якщо «Intel наводить статистику, що 95% програм недооптимізовані в рази», чи треба перевіряти самому?
Прошу визначити, де саме у вас проходить межа між цими варіантами.

апелювати до авторитетів

а потім

так написано на заборі

То якщо вам вернакулярна заборна графіка — авторитет, то може пошукайте деінде?

Правильний пункт, не зважайте на беззмістовні вигуки з кущів.

Не йдіть на інтерв’ю один, беріть ще когось із команди.

А краще 3-4. Обожнюю gang-bang interview. Зовсім нема стресу.

Сарказм я вловив :), но для все атаки я уточню що далі я говорю що два це не тільки мінімум але й максимум людей які щось говорять з сторони компанії

це два інженери, які питають, і один, який слухає

. Можливо на фоні ще рекрутер, який провів інтро і так і залишився на мьюті. Ця парадигма досить швидко розростається по моєму досвіду.

А краще 3-4. Обожнюю gang-bang interview. Зовсім нема стресу.

Є велика різниця 2 чи 3-4.
— 2 дає можливість почути альтернативну думку. Також не створюється балаган.
— 3-4. Якщо питати будуть всі, то це по 15-30 хв на людину, тобно 1-3 запитання. Складно зробити висновок на основи такого об’єму інформації. Тому часто говорить 1, а інші просто кивають.

А якщо НУЛЬ? Так, якщо кількість створює проблеми, можна зробити нуль. Можна навіть −1 зробити, але то вже треба мати специфічні навички, щоб так підлаштовувати.

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

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

Проблема в тому що нічого не зміниться, насправді. Основна причина в тому, що за час співбесіди визначити на скільки ти будеш нервувати через роботу з конкретною людиною не можливо. Ну не можна повністю пізнати сторонню людину за 40 хвилин-1.5 години.
В ідеалі для цього є випробувальний період, але там буде багато складношів, особливо якщо це галера.
А так буде ще й спеціаліст, якого можна звинувачувати. Win-win)))
І головне за це не доплачують, тому краще делегувати. Та і люди відчувають себе важливими, будуть менше вимагати підняття зарплати. Потрійний win.
Соррі, колись і я йшов твоїм шляхом, але потім стріла розуміння прострелила мені коліно.

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

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

В продуктових компаніях як правило так і є, но коментар слушний для аустсорсу такий план не спрацює

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

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

що за рабська психологія? «компанії підійде, на інший проект...». чи підійде інженеру така компанія

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

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

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

Чи підійде професіоналу, компанія з добре організованими, системними процесами?

це про сраний єрат?

Епат — як один з варіантів.
Власне, якщо глянути на претензії до епаму, то вони не стільки про процеси, скільки про гроші (а це індивідуальна тема).

Стаття зводиться до попсової мантри:
Запитуйте тільки те що треба на проекті.

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

Так одна з цілей було пояснити що ця «попсова думка» правильна :)

Так одна з цілей було пояснити що ця «попсова думка» правильна :)

1) У вас не вийшло — відсутня аргументація, а є лише ваші твердження.
2) У вас не могло вийти, бо думка неправильна в загальному випадку, а є лише паттерном для ситуації, яку я описав вище.
Спроба поділити на продукт/аутсорс взагалі видає людину з досить малим досвідом (хоча за 6 років наче мало б набратись досвіду). Простий приклад співбесіди «не в свою команду» в продукті — треба найняти команду якій передадуть частину роботи або на новий напрямок.
Ще очевидний пробіл — це найм джунів, який часто плутають з аутсорс моделлю (бо аутсорс наймає більше джунів ніж продукт), власне частково з цього і прийшли до нас «списки запитань», а в ФААНГи алгоритмічні задачі (але там складніший логічний ланцюжок).
Можна ще наводити купу прикладів і типові рішення для них, але це тема для статті, а не для коментаря.

Що було б для вас аргументом ?

Що було б для вас аргументом ?

Ой-вей. В універі не навчили писати статті та наукові роботи?

Ось з вікіпедії:
У логіці — істинне судження, за допомогою якого в процесі логічного доведення встановлюється істинність тези. Основними видами аргументу є: очевидні положення, аксіоми, факти, закони науки, визначення понять і т. ін.

Тільки не пробуйте прикладами (що є в статті) тверджень підміняти поняття з визначення.

Могли бы вы описать свой опыт проведения интервью, для сравнения?

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

UPD.
Якщо ваш коментар з серії «сначала добейся», то 56 інтерв’ю за останні 2 роки, + десь 10 внутрішні, + десь до 100 за минулі роки (точно не рахував)

да да, 7 лет и 8 компаний ))) тру синьйор детектед )

Так а шо на місці сидіти еслі десь платять лучьше? Дайте людині достойну зарплату і всі будуть спокійно роботать

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

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

ну пол года идет только понимание как устроен проект

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

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