Test project manager: Exemple de întrebări
De ce întrebări generic PM eșuează
Cele mai multe echipe de angajare pun project manager-ilor aceleași cinci întrebări: „Spune-mi despre un proiect dificil," „Cum gestionezi scope creep," „Descrie procesul tău de planning." Fiecare candidat are un răspuns repetat. Nimeni nu află nimic.
Evaluare PM efectivă cere candidaților să rezolve o problemă mică, să raționeze asupra compromisurilor și să explice luarea deciziilor – nu să recite narațiuni din trecut. Acest articol arată modelele de întrebări care funcționează, ce revelă răspunsurile și cum le notezi.
Modelul 1: Problema scenariu (work sample)
Dă candidatului un scenariu realist în 30 de minute. Scrie 1–2 pagini de răspuns. Asta suprafață gândire mai repede decât o conversație de 60 de minute.
Exemplu: Calendar accelerat
Compania ta s-a angajat să lanseze o funcționalitate SaaS în Q3. E 1 mai. Roadmap-ul arată 800 de ore de lucru rămas (dev, QA, design). Echipa are cinci ingineri plus tine. Tocmai ai aflat că clientul care a condus angajamentul s-ar putea să nu reînnoiască decât dacă funcționalitatea e live până pe 15 august. Ce faci?
Scrie abordarea în 2 minute. Numește:
- Ce informații ai aduna mai întâi (și de la cine)
- Opțiunile tale principale (3+) și compromisul pentru fiecare
- Recomandarea ta
- Un risc major pe care l-ai reduce imediat
Ce asta revelă
Răspunsuri cu semnal înalt fac trei lucruri:
- Recunoaște necunoscute mai întâi. „Înainte să decid, trebuie să știu: Estima de 800 ore e întemeiată pe story points sau ghicire? Avem capacitate QA? Data de 15 august e hard sau soft?"
- Numește opțiuni și compromisuri explicit. „Opțiune A: angajează contractori (ramp mai rapid, risc onboarding, risc cultură). Opțiune B: descope funcționalități (lipsă așteptări client, s-ar putea să nu conteze pentru reînnoire). Opțiune C: workstream-uri paralele (complexitate, risc merge)."
- Recomandă o opțiune cu rațional. „Aș descope trei funcționalități non-core și aș rula design-engineering paralel, pentru că onboarding contractorilor acum adaugă 3 săptămâni, dar putem livra valoare core până pe 15 august dacă engineering-ul începe săptămâna asta."
Răspunsuri cu semnal scăzut:
- Vorbesc peste constrângeri („Aș comunica cu stakeholder-ii")
- Numesc opțiuni fără compromisuri („Am putea angaja contractori sau descope")
- Hedging fără recomandare („Depinde de confortul echipei cu debt tehnic")
Modelul 2: Problema de prioritizare
Dă o backlog de 10–15 articole cu informații incomplete. Cere candidatului să le claseze și să apere top 3.
Exemplu: Criza roadmap
Produsul tău are cinci cereri active:
- A: Funcționalitate conformitate (necesară pentru vertical nou, potențial $200K ARR, 6 săptămâni build)
- B: Redesign dashboard (durere internă, îmbunătățește retenție cu 5%, 8 săptămâni)
- C: API pentru integrări (trei clienți întreabă, 4 săptămâni, deblochează upsell)
- D: Optimizare performance (timp load mobil e lent, afectează experiență utilizator, 3 săptămâni)
- E: Bug raportat client în export (afectează 2% din utilizatori power, 1 săptămână)
Ai 6 săptămâni capacitate echipă. Clasează top trei și explică de ce.
Ce asta revelă
Gândire cu semnal înalt:
- Distinge importanță (conformitate, creștere) de urgență (bug-ul).
- Cuantifică impact unde e posibil („C deblochează 3 clienți, aia e rough $20K+ ARR").
- Recunoaște compromisuri („B e durere dar livra impact venit mai scăzut decât A sau C").
- Face o decizie cu raționament („Aș face A + C + parte din D dacă putem paraleliza design. B și E așteaptă pentru că nu sunt revenue-driven").
Gândire cu semnal scăzut:
- Fac totul sau nu pot alege („Putem face A și B dacă deprioritizez D").
- Prioritizează emoție peste logică („B e durere echipei mele").
- Listează categorii MoSCoW fără a alege („A e Must Have, B e Should Have").
Modelul 3: Întrebarea risk-și-mitigation
Descrie un proiect real. Cere candidatului să identifice trei riscuri și cum ar reduce fiecare.
Exemplu: Dependența între echipe
Expediez un redesign de plată pe trei echipe: echipa ta (4 ingineri, 6 săptămâni), echipa de date (trebuie să instrumenteze events noi, spun 4 săptămâni) și echipa de conformitate (trebuie să audită toate schimbările, de obicei durează 2 săptămâni). Toate trei fluxuri sunt în paralel. Data de lansare hard e 8 săptămâni. Numește trei riscuri și o mitigare concretă pentru fiecare.
Ce asta revelă
Răspunsuri cu semnal înalt identifică:
- Risc dependență: „Instrumentarea de date e pe cale critică. Dacă alunecă o săptămână, lovim deadline-ul lansării. Mitigare: Aș asigna o legătură la standup-ul lor, aș bloca schema până la săptămâna 3, aș face revizuiri dependență săptămânale."
- Risc comunicare: „Conformitate pare o poartă la final. Dacă nu-i implicăm devreme, ei vor semnala probleme în săptămâna 7. Mitigare: Aș avea-i revizuiți designul în săptămâna 1, participă la revizuiri tehnice și fac un audit pilot de o funcționalitate în săptămâna 5."
- Risc scop: „Echipele s-ar putea interpreta 'redesign plată' diferit. O echipă ar putea adăuga funcționalități pe care alții nu le planifică. Mitigare: Aș scrie o one-pager definind scop, aș obține sign-off de la toți trei lead-i, aș bloca."
Răspunsuri cu semnal scăzut:
- „Riscul principal e să-mi pierd deadline-ul" (reafirmă constrângere, nu insightful).
- „Avem nevoie de comunicare bună" (adevărat dar nu concret).
- Numesc riscuri dar nu mitigare reală („Am putea depăși" – ok, dar ce faci?).
Rubrică de notare (4 dimensiuni)
| Dimensiune | Semnal înalt | Semnal scăzut |
|---|---|---|
| Framing problemă | Pune întrebări de clarificare; separă constrângeri de necunoscute | Acceptă valoare nominală; presupune toată informația e dată |
| Generare opțiuni | Numește 3+ opțiuni cu compromisuri explicit | Listează opțiuni fără compromisuri sau alege prima opțiune |
| Raționament decizie | Apără recomandare cu logică legată de rezultat business | Hedging; raționează din proces („facem X") nu impact |
| Conștientizare risc | Identifică 2+ riscuri non-obvious cu mitigare concretă | Pierde dependențe; mitigări sunt vagi („comunică mai mult") |
Notează fiecare 1 (scăzut) la 5 (înalt). PM puternic notează 4+ pe toate patru. PM mediu notează 3–4; sub-mediu e 2–3.
Când să folosești fiecare model
- Scenariu (work sample): Ecran prim, asincron, 30 min. Filtrează pentru viteză și claritate luării decizii.
- Prioritizare: Rund doi, live, 20 min. Testează judecată sub constrângeri.
- Risc mitigare: Rund final sau interviu structurat, live, 15 min. Testează adâncime domeniu și gândire de sisteme.
Stivuiește-le în această ordine: work sample, apoi prioritizare, apoi interviu risc. Împreună costă 90 de minute și suprafață mai mult din ce contează: viteză, judecată și adâncime.
Greșeli comune când rulezi aceste teste
Greșeala 1: Acceptare răspunsuri vagi. Dacă spun „Aș îmbunătăți comunicare," întreabă „Cum, specific? Cine vorbește cu cine? Când?"
Greșeala 2: Pun scenariu dar nu-i cer să-l apere. Un răspuns scris e un început, dar o debrief de 10 minute unde dai înapoi („Și dacă deadline-ul e cu adevărat hard?") revelă cum gândesc sub presiune.
Greșeala 3: Notare pe plăcere în loc de semnal. Un candidat s-ar putea fi sociabil și totuși hedging fiecare decizie. Ancorez rubrica ta la comportament observabil, nu confort.
Cum se compară cu interviuri PM tradiționale
Interviuri PM tradiționale pun întrebări comportamentale ancorat la experiență anterioară. Work sample-uri + probleme scenariu cere candidaților să rezolve probleme acum. Ambele contează, dar dacă faci doar una, work sample-ul e semnal mai înalt pentru jobul zilei de zi.
Următorul: Cum să evaluezi project manager-i la scară
Dacă construiești proces de PM hiring de la zero, începe cu modelul work sample (problema scenariu) ca ecran prim, apoi folosește celelalte două modele în runde live. ClarityHire poate administra și nota ambele pentru a asigura consecvență pe candidați.