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

За рекомендацією однієї розумної людини починаю статтю з метаданих: автор статті CTO з 15-річним комерційним досвідом (програміста, тех-, тімліда, СТО) в ІТ. Протягом кар’єри відвідав десятки співбесід у ролі кандидата та сотні в ролі інтерв’юера. А сама стаття буде цікавою всім, хто хоче уникнути помилок на співбесіді та отримати офер.

З метаданими покінчили, тепер перейдемо до статті :)

Ілюстрація Марії Рибак

Як отримати такий бажаний офер

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

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

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

Всі відвідані мною співбесіди закінчувались одним з трьох способів:

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

Перші два пункти виходять за тему статті, зосередимось на третьому. Як схилити це «якщо» у ваш бік?

Як збільшити шанси на те, щоб вас запросили в нову компанію. Поради

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

Почнемо з початку співбесіди. А точніше, перенесімо його на 10 хв, бо я застряг в заторі.

Не запізнюйтесь на співбесіду. Приходьте на 5 хв раніше онсайт і на 2 хв раніше онлайн.

Якщо ви запізнились — просіть вибачення. Якщо ви прийшли на хвилину пізніше — просіть вибачення. Вам це нічого не коштує, у 90% випадків це нічого не змінить, бо інтерв’юер такого короткого запізнення не помітить. Але в 10% випадків вам попадеться педант, який має на співбесіду рівно 42 хвилини і в якого всі питання, час на фідбек, графік роботи після співбесіди і взагалі все життя розписане похвилинно. А ви зіпсували йому настрій, бо він мав рівно о 6-й дитину з садка забрати, а тепер запізниться. Просіть вибачення, це не важко. А краще не запізнюйтеся.

На бекенд/фулстек інтерв’ю я часто ставлю питання із SQL — «яка різниця між LEFT JOIN та OUTER JOIN». Багато кандидатів, побачивши, здавалося б, шаблонне питання, починають розписувати різницю між LEFT JOIN та INNER JOIN. І тільки найуважніші та найдосвідченіші бачать, що це питання «із зірочкою» і відповідають, що різниці немає і питання некоректне, бо LEFT є одним з типів OUTER JOIN.

Уважно слухайте питання, які вам ставлять.

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

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

Не відгукуйтеся погано про попередніх роботодавців.

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

Під час JS-інтерв’ю я часто запитую про глобальний об’єкт Proxy. Менш досвідчені програмісти впевнено починають розповідати про http proxy, особливо настирні навіть після кількох уточнень, що «мене цікавить глобальний об’єкт JS Proxy, а не http proxy», продовжують, що жодних інших proxy в JS немає, вони точно знають, бо багато разів його не використовували.

Не бійтеся відповісти «я не знаю».

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

Одного дня був кандидат, який «не має жодних питань, у вас з профілю на ДОУ все зрозуміло». Він казав, що хоче змінити роботу, бо йому «не підходять процеси й команда в поточній компанії». Єдина думка, яка виникає: а звідки ти можеш знати, які в нас процеси? Ти ж про це навіть не питав. Очевидно, кандидат прийшов поспілкуватися без наміру міняти роботу. Бо людина, яка справді розглядає варіант зміни роботи, яка хоче в новій компанії пропрацювати хоча б рік-два (бо кандидати, які й року не збираються в нас працювати, нам не потрібні), не може не цікавитися, де пройдуть наступні два роки її життя.

Ставте питання інтерв’юеру.

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

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

Не відволікайтеся на дзвінки/меседжі під час інтерв’ю.

Всі ми одне одного поважаємо. Коли зустрічаємося з друзями, кладемо телефони екраном вниз, щоб вони не псували спілкування. Намагайтеся всі свої справи вирішити до інтерв’ю, щоб у процесі вас не відривали ні доставка піци, ні робота, ні кіт/собака. Компанія-інтерв’юер вже витратила на вас багато часу і грошей — на обробку резюме, 1–2 розмови з рекрутером, час всіх, хто прийшов на співбесіду, не змушуйте їх витрачати його ще даремно.

Наступні два без практичних кейсів, бо «я не маю доступу до свого GitHub-акаунту, всі проєкти під NDA, пет-проєктів у мене немає, я ніяк не можу показати приклад свого коду» (а не тому, що в мене гамн*код). Підготуйте собі один репозиторій з гарним кодом, щоб його показувати на інтерв’ю.

Читайте топ-10 запитань на інтерв’ю для цієї позиції від Google.

Перед інтерв’ю гуглимо «top interview questions» і читаємо перші 2–3 лінки. Здебільшого там є тільки найочевидніші питання, проте багато кандидатів навіть на них не знають відповіді. Це просто, займає 10 хвилин, але може дати відчутну перевагу над іншими кандидатами.

Намагайтеся правильно зрозуміти питання і не бійтеся перепитати.

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

Кандидат на позицію ПМ написав у резюме інформацію про те, що він має PMI-сертифікат. Звичайно ж, ми перевірили. Коли імені кандидата в базі PMI не знайшлось, ми написали лист в PMI. Ми навіть перепитали в кандидата на співбесіді, чи він не міняв ім’я/прізвище і чи здавав сертифікат в Україні. Коли ми попросили його надати лінк на сертифікат або хоча б файл сертифікату, він не зміг. Звичайно ж, про джоб-офер не могло бути й мови. А здавалося б, один рядочок в резюме, хто це помітить...

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

Не обманюйте на інтерв’ю.

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

Кандидат мав 9 років досвіду і зарплатні побажання стронг джуна. Такі випадки завжди сумнівні, але я вирішив спробувати. На співбесіді чоловік на всі питання відповідав 1–2 словами. Навіть на питання «що таке редюсер і як він має працювати» (співбесіда була з React) сказав «функція» і більше пояснювати не хотів. Точно, лаконічно, водночас ні краплі не пояснює, чи він знає, що таке той редюсер. Після уточнювальних запитань вдалося зрозуміти, що він таки знав концепцію. Очевидно, що перше застереження, яке виникло в мене як в інтерв’юера — кандидат буде аналогічно поводитись під час роботи й буде мовчати про труднощі, навіть коли буде їх бачити.

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

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

Tl;dr

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

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

👍НравитсяПонравилось24
В избранноеВ избранном8
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

І ще є три питання, які багатьох кандидатів цікавлять:

1) Як ви ставитеся до live coding на співбесіді?
2) Чи даєте ви тестові завдання кандидатам і як відреагуєте, якщо кандидат попросить заплатити за них?
3) Чи вважаєте ви, що потрібно обов’язково включати камеру на онлайн-співбесіді?

1. Використовував декілька разів. Стикався з ситуацією, коли на написання 2 інпутів і кнопки, яка рахує їх суму(без валідацій, стилів і т п) в «сіньйора» йшло 50 хв. Але зазвичай не роблю live coding, бо воно займає забагато часу
2. Ні, тільки деколи для джунів/трейні. Якщо кандидат просить — оплачуємо.
3. Не обов’язково. Але мені особисто приємніше спілкуватися, коли я бачу співрозмовника

Перед інтерв’ю гуглимо «top interview questions» і читаємо перші 2–3 лінки. Здебільшого там є тільки найочевидніші питання, проте багато кандидатів навіть на них не знають відповіді. Це просто, займає 10 хвилин, але може дати відчутну перевагу над іншими кандидатами.

Можете поділитися 1-2 очевидними питаннями, на які практично не дає правильної відповіді?

Наприклад, питання про key в react. Багато хто каже, що туди треба ставити індекси масиву, хоча навіть дефолтне налаштування eslint це підсвічує, як warning.

Не обманюйте на інтерв’ю.

Не пробуйте брехати/перемудровувати інтерв’юера.

Цікаво, а як ви визначаєте різницю між продуманим обманом і незнанням?
Наприклад, написала людина в резюме, що у неї English upper-intermediate, тому що дійсно так думала, чи у неї колись такий рівень був.
А ви перевірили її рівень, і виявився Pre-intermediate. І ви відразу починається її звинувачувати в обмані?

Да, это явный обман. Можно ошибиться на 1 уровень, но на 2 уровня — это уже перебор.

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

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

Даремно ви не взяли такого кандидата. Адже він просто незамінний для будь-якого складного проекту:

1) Нестандартне мислення
2) Вміє побудувати роботу в команді
3) Готовий до небезпеки і не боїться ризикувати

Цікаво почути думку автора на таке питання. Який підхід він застосовує на співбесіді — питання з чекліста або імпровізація?

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

а бекенд/фулстек інтерв’ю я часто ставлю питання із SQL — «яка різниця між LEFT JOIN та OUTER JOIN»

Скільки разів мене питали про SQL, але такі тривіальні питання ніколи не чув. Може бути вони є релевантними для джуна або інтерна.

Мне одному кажется, что советы полная LLlляпа?

Проблема в том, что люди искренне веруют в полезность этих советов

На бекенд/фулстек інтерв’ю я часто ставлю питання із SQL — «яка різниця між LEFT JOIN та OUTER JOIN». Багато кандидатів, побачивши, здавалося б, шаблонне питання, починають розписувати різницю між LEFT JOIN та INNER JOIN. І тільки найуважніші та найдосвідченіші бачать, що це питання «із зірочкою» і відповідають, що різниці немає і питання некоректне, бо LEFT є одним з типів OUTER JOIN.

Різніця насправді є, як є різниця між рибою й оселедцем: кожний оселедець — риба, але не кожна риба — оселедець. Так само й тут: кожен LEFT JOIN є OUTER JOIN, але не кожен OUTER JOIN є LEFT JOIN. Але навіщо так питати в форматі співбесіди? Що цим перевіряється: уважність чи розуміння кандидата що таке OUTER JOIN?

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

Абсолютно, 1000% согласен.
Интервьюеру (ещё раз повторюсь, я прособесил много кандидатов, в какое-то время даже занимал позицию штатного интервьюевера QA автоматизаторов от Middle и выше в 1 из компаний в параллели с основным проектом) важно понять, умеет ли кандидат думать и как, а не ответ «по книжке». Из моих вопросов ну мож % 20 — это вопросы на знание, остальные — вопросы «на подумать», на них нет правильного ответа, всё зависит от того, как и чем кандидат будет аргументировать своё решение задачи. Если кандидат дошёл до половины и запоролся — я подскажу. Но если он 5 мин думал и не сказал ничего — это жирный минус.

А вот интересно, в каком нибудь сферическом США в вакууме реально будет промутить практику обвинения в dumb-shaming? Т.е. отказали соискателю на собесе — все — фиксируется факт угнетения, суд, осуждения компании в медиа и пострижка кеша на компенсации морального ущерба?

Автор CTO, потому он так формулирует мысли: готовьтесь, переспрашивайте, чтобы увеличить шансы....
хотя в конечном итоге доволен должен остаться конечный бенефициар труда разработчика, а то потом какой-то хитрый карась подготовится и таки просочиться в команду, а там выясниться что он «На собесе Лев Толстой, ну а в деле ... простой»

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

Не бійтеся відповісти «я не знаю».

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

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

Я думаю что автор имел в виду когда человек отвечает примрено так:
«Честно говоря я не знаю, но давайте подумаем логически как я это представляю/как бы я это делал»

Может это автор и имел ввиду, но в текущая формулировка очень напрягла

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

Хтось неуважно читав 😁

«я не знаю, але думаю, що...»

Автор так і порадив — казати, що ти не знаєш (якщо ти не знаєш), але думаєш, що може так і так (тут генерація). Малось на увазі, якщо ти гадки не маєш, скільки буде 2+2 — не варто вгадувати і казати 89. Наскільки я правильно зрозумів, звичайно)

Пусть компания переспрашивает, им же надо

Не. Им нечего не надо. Говорю как человек, прособеседовавший без преувеличения сотни кандидатов. Не знаешь? На выход. Следующий!
Мне проще откинуть парочку годных чуваков (хотя я честно стараюсь расслабить на собесе какими-то шутками и т.д., показать, что я не кусаюсь и я не делаю выводы по 1 вопросу), чем потратить своё проектное время на обучение тех, кто не способен вытянуть требования проекта. Потери моего времени на собесе = 1..1.5 часа. Потери времени на попытку обучить чувака тому, что он физически не способен понять из-за ограничений знаний / интеллекта / подберите на свой вкус могут быть до 1 месяца. Полтора часа vs месяц — выбор очевиден.

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

Неверно. Я не говорю о какой-нить специфике типа «чем отличается имплементация join в Oracle vs MySQL» — это не проблема. Но если кандидат не способен написать базовый запрос при условии необходимости использовать SQL на проекте — мне проще найти того, кто знает, нежели доучивать этого без гарантии результата. И дороже будет потратить на него месяц, чтобы узнать, что он не хочет / не может с ним работать в принципе.

а если у него ещё и рейт выше вообще обидно

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

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

Я — нанять себе в проект толкового чувака, соответствующего по знаниям требованиям проекта. Simple as this. На моё мнение пофиг не будет, патамуша именно мне с ним работать потом. Ну и я ж не hr, я ж техническую часть провожу ) Никто не возьмёт в проект кандидата, который не имеет необходимых знаний / навыков. Если бы было пофиг — зачем техническую часть вообще проводить?
Ты несёшь какой-то бред. Ни разу не видел проект, чтобы брали кого попало, несмотря на риджект по техсобесу. Обычно манагерское после этого даже не проводят. Видел, когда брали типа «на грани» или «возьмите лучшего из последних 5, на других нет времени», но даже в этом случае критерием отбора будет именно впечатление на собесе.
Хотя не, видел. В проектах, которые мы от индусов забирали. Вот там как раз создаётся впечатление, что они именно так и подбирают, в пофиге на технические скиллы. Мож у тебя оттуда опыт?

Меня смущает пункт «я не знаю», что это будет за интервью если отвечать только на те вопросы, которые знаешь наверняка?
Не знать что-то совершенно нормально, особенно учитывая что вы никогда в этой компании/команде не работали и не обладаете тем же перечнем знаний и глубиной понимания технологий конкретного проекта или направления, как любой заонбордженный работник. Но фраза «я не знаю» триггерит интервьювера, и он ставит тебе жирные минусы за каждую такую фразу.
В свою очередь, порассуждать как это могло бы работать, или «не сталкивался, но если бы столкнулся, то делал бы так:» и описать ход мыслей — поможет интервьюеру понять как ты мыслишь, и сказать о кандидате куда больше чем просто знание сухого факта/инстурмента.

«Я не знаю» и замолчал > минус.

«Я не знаю, алэ судя по тому, что есть, можно предположить...» > ай маладца, не сдавайся.

отвечать только на те вопросы, которые знаешь наверняка

Там

«я не знаю, але думаю, що...»

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

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

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

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

камон
— я не знаю що таке «GraphQL» та як він працює
— я не знаю конкретно як проходить SYC/SYC-ACK/ACK (наче щось з каунтером повязане).
— я не знаю як (і навіщо) праюцє Монга

це нормально не знати, на інтервю вимірюють `depth and breadth` а не чи знаєш ти go map internals.

В универе всегда говорили, что лучше заменить «я не знаю» на «я затрудняюсь дать ответ». Хз в чем магия, но звучит лучше.

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

Однако есть несколько ньюансов, которые хотелось бы осветить

Не відволікайтеся на дзвінки/меседжі під час інтерв’ю

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

Одно из моих самых ужасных собеседований началось с предложения написать алгоритм обхода дерева в ширину (точнее задачка была на этот алгоритм), пока интервьюер проверит мои тесты (были первым этапом с HR). Я мягко намекнул, что знаю алгоритм, но не буду его писать (ибо затруднялся вспомнить да и на позицию TL он был неактуальным). На что интевьюер скривил кислую мину, начал собеседовать меня. Отвлекаясь постоянно на чат в вайбере. Узрев ближе к концу мое охуевание, он превентивно спросил — а какой мессенджер используется у вас на проекте?
По итогу оффер я получил, но принципиально отказался работать с этим человеком. Более того, меня несколько раз собеседовали в эту компанию на должности выше, и первым вопросом было будет ли Древовидный Вайбераст на собеседовании.

Не відгукуйтеся погано про попередніх роботодавців.

С одной стороны да, но с другой возникнет разумный вопрос «если все так хорошо, почему же Вы уходите на самом деле?»

яка різниця між LEFT JOIN та OUTER JOIN

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

ТО ВТОРОЙ — просто мрак в стиле подъебок старых пердунов с военной кафедры «сколько полос у тебя на тельняшке — 50 — аа, дурак! Две — белая и синяя»

Мозг — один из самых ресурсоемких человеческих органов. И это НОРМАЛЬНО, что человеческий организм оптимизирует количество размышлений путем использования шаблонов. И подъебка «ты пропустил OUTER» не говорит ни о чем, кроме того, что интервьер «такой молодец» что ее придумал.

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

гораздо адекватней спросить про прошлые проекты, какие задачи решал и на основании каких факторов делал выбор в пользу того или ионого подхода

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

Это показывает как кандидат думает и какие факторы учитывает. И 99.(9)% задач в целом похожие.

если гражданин ищет новое место работы, то, вероятно

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

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

Если честно сказать, что ваше, тоже самое, что и наше, но у вас я хочу +500-1000?

если все так хорошо, почему же Вы уходите на самом деле?

можна пояснити об’єктивні причини. Коли є конкретика легше стати на бік кандидата. Коли тільки емоції — на бік роботодавця.

проход по чеклисту и подъебка.

1. Чекліст є у всіх. Навіть, якщо тільки в голові.
2. В жодному разі. Коли кандидат відразу не розуміє питання, я наголошую, що тут є різниця. Але кандидати і далі народжують якийсь міфічний OUTER JOIN, схожий на сплав FULL OUTER JOIN і ще якоїсь матері. Цитата з одного інтерв’ю: «OUTER JOIN це коли записів нема ні в лівій, ні в правій таблиці». В той же час, всі сіньйори правильно відповідають на питання

Чекліст є у всіх. Навіть, якщо тільки в голові.

отучайтесь говорить за всех ©

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

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

2 пива этому господину!
Это сразу показывает 2 вещи:
1. Интервьюеру пох на результат интервью. А значит, компании пох, будуте вы тут или там.
2. Интервьюер настолько перегружен задачами, что не может выделить 1..1.5 часа на интервью. Либо плохой тайм-менеджмент интервьюера (который лицо компании), либо плохой тайм-менеджмент компании в целом и я не хочу выяснять, что из 2-х вариантов хуже. Надо будет оч постараться, чтобы переломить моё мнение о компании.

«если все так хорошо, почему же Вы уходите на самом деле?»

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

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

Тыщщу раз согласен!
Это откровенно тупой вопрос. Я могу сотни подобных вопросов придумать на QA собес из серии «в чём разница между функциональным и smoke тестированием» — но задам я их только в 1 случае: если захочу обоснованно завалить кандидата по каким-то своим причинам (например, уже есть кандидат, готовый принять оффер, который меня устраивает, но сверху мне напаривают пачку тех, кто мне не нужен из разряда «глянь, они дешевле, мож подойдут»).

Або прийти з офером до поточного роботодавця і просити, щоб зрівняли.

Розпишите детальніше?
Чому це речення перекреслене? Невже, так не можна робити?

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

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

і можуть щось додатково насипати

например задач в джиру

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