дякую за статтю!

Sealed when statements

— ще з Kotlin 1.7 є;

Sealed interfaces

— ще з Kotlin 1.5 точно були;
Всі решта пункти так чи інашке не нововедення 2.0.
Не дуже розумію чому стаття прив’язана саме до релізу 2.0 і не було показано жодної фічі з 2.0, але все ж щось нове дізнався для себе)

DI руками і без код гену? Тоді який сенс з такого DI?:)

Імхо писати ці тести важче, ніж користуватися компайм-тайм перевіркою дагера

Тобто чуваків, які по-приколу ходять на співбесіду треба відсіяти, а от чувака, що «професійно проходить співбесіди» десь піврочку поговнокодить у вас на проекті ми відсіювати не плануємо :)

Для цього є trial period.

А от про лайфкодінг, то він перевіряє не якість коду людини, а вміння комунікувати :)

+

Оця вимога при лайфкодінгу суттєво додає помилок при відборі.

теж +, все попереднє було про тестові завдання. На лайвкодингу критерії оцінювання мають бути радикально спрощені. Ну і я на лайвкодинг ніколи не даю щось складніше ніж  fun isAnagram(first: String, second: String): Boolean , де є безліч варіантів вирішення, але якщо кандидат не може зробити хоч би перебором, то мені такого колеги не треба.

То варто трохи набратись багатого досвіду :)

«Батя, я стараюсь» :)

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

100%, тому я вказую кандидатові, що хочу від коду:
1) Щоб працював:)
2) Тестабіліті;
3) Правильний напрямок залежностей (clean architecture, словом);
4) Розуміння того, як працює Kotlin/Java, Android і обрані бібліотеки. Шукаю в коді типові помилки в роботі з ними.

вейт фор іт ... випробувальний термін

Тут повністю згоден, але це вже навряд по темі.

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

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

Але тут скоріше за все різниця в визначеннях поняття «погано».
Що ви туди вкладаєте?

Відповідно відсутність попередніх факторів.

А по резюме «розробник Android із багатим досвідом у галузі» цього зробити не може?

Без оцінки коду на лайвкодинку або тестовому? Ні.

Ваші поради корисні для відсіву потому на ентрілевер вакансії.

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

1) А ви знаєте який імідж у Аджакс в професійних колах? Пошукайте на доу теми та коментарі :)

Haters gonna hate:) Людей, які хочуть тут працювати вистачає, щоб обирати серед найбільш вмотивованих.

2) Знову аргументація з позиції сили/сатусу і оцінка свого часу ціннішого за час майбутнього колеги

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

Питання не в об’ємі «воронки», а в тому кого вона відсіює

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

Знову ж таки, я повністю згоден з вашими понітами у вашому контексті, але не усі вони мають сенс в моєму контектсі.

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

мобайл буде можна за 1-1.5 лекго

комусь легко, комусь — ні)

dou.ua/...​signment-for-job-seekers (стаття ще з доковідних часів)

прочитав, дякую, для мене тестове це ще й відсів умніків, які просто хочуть по-приколу походити по технічним співбесідам.