Як оцінити Flutter-розробника без коду

Код ви перевірити не можете — перевіряйте рішення

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

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

Ось що питати.

Просіть лістинги, а не репозиторії

Профіль на GitHub доводить, що людина пише код. Живий лістинг в App Store і Google Play доводить, що вона щось закінчила, пройшла ревʼю і розібралася з тим, що не є програмуванням: декларації приватності, віковий рейтинг, скриншоти, шлях видалення даних.

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

Чотири питання і що показують відповіді

1. «Який менеджмент стану використовуєте і чому не інші?»

Шукати треба не назву. Шукати треба причину, привʼязану до контексту — щось на кшталт *Bloc для великих застосунків із багатьма розробниками, бо межі явні; Riverpod коли граф менший і церемонії не варті того.* Ми використовуємо обидва саме за цим поділом.

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

2. «Що відбувається у вашому застосунку, коли зникає мережа?»

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

3. «Як ви дізнаєтесь, що в продакшні щось зламалось?»

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

4. «Покажіть рішення, у якому ви помилились і яке довелось відкотити.»

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

Червоні прапорці, які варто сприймати серйозно

• Немає CI. Якщо збірки роблять на чиємусь ноутбуці, релізи залежать від того ноутбука і тієї людини.
• Тести «потім». «Потім» не настає. Повне покриття не потрібне, але нуль на проєкті будь-якого розміру — це рішення, а не випадковість.
• Жодних питань про ваш бізнес. Інженер, який не питає, хто цим користуватиметься і що вважати успіхом, збудує рівно те, що ви написали, включно з тим, що було помилкою.
• Фіксована ціна до скоупінгу. Впевнена цифра без discovery — це цифра, яка зміниться; питання лише, до підписання чи після — ось що припускає реальний термін.

Найдешевший тест із усіх

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

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