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

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

Це все про досвід і зрілість девелопера, такі люди цінуються і їх треба вміти правильно розуміти на інтерв’ю.

Якшо у тебе фіговий тікет або відверто галімий пріоритет, то винен будеш не ти, але продукт не взлетить. В команді девелопер має розуміти business value того, шо він робить в скоупі всього продукту і в межах команди.

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

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

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

Стосовно погрішностей то вони будуть завжди, але краще це будуть погрішності в академічних знаннях, ніж в якостях людини як потенційного члена команди.
Чіткі питання теж можна задавати, але в контексті розмови про досвід (навіть досвід навчання). Я не знаю як ще оцінити якості людини крім розмови про її досвід і моделювання реальних ситуацій. Бо якщо все інтервʼю буде складатися з академічних питань то є наступні ризики:
1. Кандидат може просто вивчити відповіді на питання. Так, можна уточнюючими питаннями перевірити, але можна і провтикати.
2. Кандидат може розуміти топік з практики, але не знати його академічного оформлення, чим завалити питання. (Памʼятаю як мене вперше про BOM запитали і я на секунду відчув себе дуже тупим).
3. Тільки кейси з досвіду або модельовані кейси + невеликий сеанс кодінгу показують як людина думає і як буде поводитись разом з іншими людьми. З дуже примітивного прикладу — можна найняти крутого спеціаліста по хардскілам, який не буде нічого робити без тікета в джирі, бо його так навчили, чи не зможе оцінити потреби бізнесу в критичний момент коли зненацка колега захворів і треба на місці порізати скоуп шоб хоч якесь велью було.

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

не меняет ничего

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

задаешь вопросы не связанные с чем-то общеизвестным, еще и в качестве арбитра накатываешь свое мнение. объективностью такое собеседование и не пахнет

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

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

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

Ні. Мати план з топіками, які треба перевірити це не те саме, що слідувати йому покроково. Краще коли кандидат розказує про свій досвід, а не відповідає на чіткі питання. Додаткові питання мають бути дотичними до кейсів з його досвіду стосовно: можна питати про уявні проблеми в контексті його кейсів, його розуміння власних помилок і т.д. Тобто інтервʼю як жива розмова, а не питання типу «шо таке О в SOLID?», «які типи даних є в JS?».

Якшо співбесідувач не профан, то у нього є план, по якому він НЕ слідує. Вганяти співбесідуваного в рамки плану це погана ідея, так йому важко розкритися.
В ідеалі співбесідувач має знати куди повинен вписатися кандидат, співбесідувати внікуди можна, але по нормальному це забере мінімум 3 години.

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

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

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

Туди ж it-rex.com.ua
Але їх нема на DOU

Взагалі не показник. Малі контори можуть не видавати техніку і платити нормальні зарплати.

strong middle на 6К

капєц

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

Шютка защітана

Писав коментар, коли тега ще не було :)

Думаю, варто додати в заголовок і теги що стаття стосується Java.
А стаття виглядає гарно.