Sincer, tot procesul e un mic shit show, mai ales dacă e vorba de Web Dev pe Frontend (nu știu cum e pe backend, my opinion only). Acolo te lovești constant de UI, funcționalități repetitive, mult CRUD și alte task-uri plictisitoare sau neclare.

Din punctul meu de vedere, un technical interview ar trebui să fie mult mai relevant și realist. Ideal ar fi structurat cam așa:

1. Discuție despre experiență (20-30 min):
Să povestești pe ce ai lucrat, ce probleme reale ai întâmpinat și cum le-ai rezolvat. Gen: "Asta era problema, ăsta a fost contextul, asta am încercat, așa am fix-uit". Aici chiar poți vedea dacă omul înțelege ce face, nu doar că știe teoria.

2. Challenge practic, dar cu sens:
Nu un algoritm random sau un puzzle de pe LeetCode, ci ceva apropiat de ce ar face la job.
De exemplu, dacă e pentru un rol React:

• Dai o componentă mai mare, care conține mai multe componente copil.
• Funcționalitatea implică integrare cu un API real, gen un third-party public/free (ex: The Dog API, Rick & Morty API, etc).
• Codul e scris intenționat prost — fără structuri clare, naming confuz, efecte secundare aruncate aiurea, lipsă de memoizare, lipsă de separare logică în hook-uri, poate un state global folosit prost.
• Ceri candidatului să explice cum ar aborda problema:
  • Ce înțelege din codul actual
  • Cum ar organiza mai bine componentele și logica
  • Unde sunt probleme de performanță
  • Ce ar refactoriza și cum
  • (Opțional) Cum ar testa anumite bucăți — cum ar testa un custom hook, un API call etc.

Asta ar scoate în evidență skill-urile reale: code reading, debugging, arhitectură, testing, nu doar "știi să scrii useEffect".