È una cattiva idea chiedere a un intervistatore qual è la più grande forza e debolezza del proprio team di sviluppo? [chiuso]

Mi chiedevo se questa fosse una buona domanda da porre a un possibile datore di lavoro quando intervista per una posizione di sviluppatore:

Qual è la più grande forza e debolezza del tuo team di sviluppo?

Riceviamo tutti questa domanda quando siamo in un'intervista, quindi perché non chiedere loro in cambio? Penso che sia un'ottima domanda perché potremmo scoprire la squadra e come questa forza o debolezza potrebbe influenzarci, ma non voglio infastidire l'intervistatore.

C'è qualche svantaggio nel porre questa domanda quando intervista per una posizione di sviluppatore?

Non è una cattiva domanda, tuttavia personalmente non la definirei così.

Comincerei chiedendo del team di sviluppo e dei loro processi, e proverei a raccogliere da solo ciò che è forte e debole di loro. È difficile fare una serie di domande da porre perché sarebbero diverse a seconda delle risposte fornite, del tipo di posizione per cui ti stai candidando e di ciò che apprezzi di più in un team di sviluppo.

Il miglior consiglio che posso darti è di provare a far sembrare le domande più simili a una conversazione e meno a un interrogatorio. Inoltre, pianifica un elenco di cose che ti interessano scoprire in anticipo.

Non esprimerlo in questo modo. Tutti odiano la domanda "punti di forza e di debolezza" fasulli (IMHO). Non è necessario capovolgerlo e riutilizzarlo.

Le domande molto migliori e più autentiche che arrivano alle stesse informazioni sarebbero le seguenti:

• Raccontami la storia della tua squadra, come hai iniziato, da dove provengono i membri della squadra? Dove sono andati i membri precedenti del team quando se ne sono andati?

• Perché stai cercando di riempire la posizione x?

• Quali sono le sfide più difficili che tu e il tuo team affrontate lavorando qui?

• Puoi guidarmi attraverso il ciclo di vita di un progetto su cui questo team ha lavorato? Come è iniziato e finito? Qual è la relazione del team con le parti interessate, i tester (se presenti), le operazioni (se presenti) e la manutenzione?

• Quando le cose vanno male, come risponde la tua squadra? Puoi parlarmi dell'ultima / attuale / più grande crisi?

Avere una risposta a queste domande aiuta a dare un quadro di com'è lavorare con quella squadra. Queste sono un'opportunità comoda per il responsabile delle assunzioni per descrivere realmente i pro / contro dell'ambiente di lavoro. È anche facile rilevare una risposta fasulla a tali domande che indicherebbero che c'è qualcosa che viene nascosto.

Non so quanto sia prezioso chiedere, perché assumendo te (e possibilmente altre persone), stanno cambiando la dinamica della squadra. Hanno chiaramente identificato qualche debolezza attuale, sia che si tratti di una mancanza di una particolare abilità o solo della necessità che un altro sviluppatore esegua il lavoro e stanno cercando di risolvere tale debolezza. Non appena aggiungono la persona o le persone al team, le dinamiche sono cambiate e la loro risposta potrebbe o non potrebbe più essere valida.

Probabilmente sarebbe più perspicace chiedere informazioni sulle pratiche attuali del team e sui desiderati miglioramenti del processo. Dove si trova ora il team in termini di come il lavoro viene svolto, probabilmente non cambierà drasticamente tra il colloquio e la tua potenziale data di inizio (a meno che la data di inizio non sia di diversi mesi scaduta) e chieda i miglioramenti desiderati per processi, metodologie e strumenti potrebbe darti l'opportunità di indicare che potresti avere le capacità o le conoscenze per aiutarti con questi sforzi.

Sì, ci sono più di alcuni aspetti negativi nel porre questa domanda. Prima di tutto, quanto bene la persona che stai chiedendo ha davvero la capacità di rispondere a questa domanda? Se stai ponendo questa domanda a qualcuno nelle risorse umane, potrebbe non avere idea di quale sia una risposta legittima qui. Anche il manager potrebbe non sapere se il team è ancora relativamente nuovo e le cose non sono così conosciute in termini di dinamiche sociali e risultati. L'altro lato è quanto sei preparato per la ginnastica linguistica che potresti iniziare con questa domanda in quanto c'è più che una leggera possibilità che una risposta sia così carica di parole d'ordine o vaga che abbia poco valore a meno che tu non sappia come dare seguito con alcune domande più difficili da colpire. Ad esempio, se affermano di cooperare e di fornire buoni risultati, siete pronti a interrogarlo ulteriormente?

D'altro canto, sarei più tentato di chiedere un po 'di storia della squadra:

• Da quanto tempo questa squadra è insieme?
• Chi ha quanti anni qui?
• Quali ruoli tendono a svolgere di solito le varie persone?

Sarebbe molto più utile per la mia mente rispetto alla domanda che può essere percepita come piuttosto caricata nella mia mente. Mentre posso ammirare lo sforzo, mi chiedo quanto bene ogni azienda avrebbe studiato le dinamiche del team per trovare i loro punti di forza e il loro stile al punto da essere in grado di rivelarli.

Il commento sul chiedere questo alla persona senza sapere quanto bene rispondono entra in quella "ginnastica linguistica" di cui sopra, in quanto posso facilmente prevedere qualcuno che affermi qualcosa di simile a "Assumiamo solo il meglio qui" o qualcos'altro che è bollente per una risposta che richiederebbe qualche sondaggio per scoprire la risposta era solo qualcuno che cercava di essere educato piuttosto che offrire una risposta accurata. Un'altra risposta generica sarebbe che "tutti vanno così d'accordo" che ci si potrebbe chiedere se ci sono ostilità nascoste o se il team è davvero un gruppo di persone mature che lavorano bene insieme.

Invece di chiedere debolezza, ribadirei la domanda "Qual è la più grande sfida del tuo team di sviluppo?" in modo che non si pensi che qualcuno stia intenzionalmente provando a creare problemi, ma piuttosto a cercare di capire meglio come viene vista la squadra.

Ad un certo punto, avrebbero dovuto almeno indirizzare il positivo se volessero incoraggiarti a far parte del team. Qualsiasi responsabile della qualità / team leader dovrebbe porre questa domanda quotidianamente. Nessuno e niente è perfetto. Probabilmente non continuerai a fare ciò che funziona se non riesci a riconoscerlo.

Se lo trovano offensivo o non si sente che è il posto giusto per porre tali domande, potresti non voler il lavoro. Qualsiasi avversione alla domanda potrebbe essere un segno di insicurezza o almeno di scarsa comunicazione.

Personalmente, mi piacciono le persone che attaccano direttamente i problemi perché sono disposte a riconoscerli (non è il passaggio 1 di 12?).

Spesso, ci sono problemi che sfuggono al controllo del leader: budget, codice legacy, dimensioni del personale, persone buone partono per lavori con retribuzioni più elevate, la natura del lavoro significa che gli sviluppatori devono accogliere i membri del team in diversi fusi orari, i dirigenti hanno tendenze di micro-gestione, politiche a livello aziendale come codice di abbigliamento, orari di ufficio, ecc. Ognuno di questi può avere un impatto negativo o limitare una squadra.

Una delle mie domande di borsa per il mio possibile futuro datore di lavoro è "perché ti piace lavorare per la tua azienda?"

Mira a ottenere lo stesso tipo di informazioni, ma in modo positivo e ottimista. In ottimi posti di lavoro, scoprirai che spesso il tuo intervistatore inizierà a sgorgare tutti i tipi di informazioni fantastiche che vuoi davvero sapere per prendere la tua decisione!

Trovo che sia una domanda davvero strana. Che tipo di risposta o informazione ti aspetteresti?

Se ti stai candidando per una posizione di sviluppo, mi aspetto che tu chieda di più sugli aspetti tecnici. Ad esempio, "quali metodologie stai utilizzando?", "Quali strumenti stai utilizzando?", Ecc.

Chiedere a una squadra la propria opinione su se stessi non è così probabile come dire come una domanda su come la loro risposta agli eventi abbia portato a un risultato. Questo tipo di domande sono conosciute come domande comportamentali e si basano sull'idea che il comportamento passato è il miglior predittore del comportamento futuro.

Quando si preparano domande di tipo comportamentale, un modo comune per modellarle è utilizzare il metodo STAR, il che significa che la domanda è strutturata in modo tale da condurre le discussioni verso una situazione, un'attività, un'azione e un risultato specifici della situazione in discussione.

Ad esempio, "Da quando è entrato a far parte del team, qual è stato il maggior successo del team, che cosa ne ha creato l'opportunità, quali azioni del team hanno avuto il maggiore impatto nel realizzarlo e quali sono stati gli effetti di questo successo sull'azienda?"

Penso che sia un'ottima domanda, anche se la farei in modo un po 'diverso. In passato, ho posto domande come:

• Quali sono le maggiori sfide tecniche nel tuo negozio?
• Come va la gamma / diffusione nelle skillset della tua squadra?
• Quanto è problematico risolvere il problema nel tuo negozio?

Queste domande ti aiutano a esporre indirettamente informazioni sul funzionamento del team. Le sfide tecniche rivelano l'atteggiamento del team nei confronti della (nuova) tecnologia. Range-in-skillset rivela il background professionale all'interno del team. Il silosing rivela problemi di proprietà del codice e ego.