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

Non è una cattiva domanda, tuttavia personalmente non la descriverei in modo abbastanza simile.

Inizierei chiedendo del team di sviluppo e dei loro processi, e cerco di raccogliere da solo ciò che è strong e debole su di loro. È difficile dare una buona serie di domande da porre perché sarebbero diverse a seconda delle risposte fornite, del tipo di posizione per cui si sta candidando e di cosa si apprezza di più in un team di sviluppo.

Il miglior consiglio che posso darti è quello di cercare di mantenere le domande che suonano più come una conversazione, e meno come un interrogatorio. Inoltre, pianifica un elenco di cose che ti interessa scoprire in anticipo.

Non dirlo in questo modo. Tutti odiano la domanda "punti forti e deboli" falsi (IMHO). Non è necessario girarlo e usarlo di nuovo.

Domande molto migliori e più autentiche che ottengono le stesse informazioni sarebbero le seguenti:

• Parlami della storia della tua squadra, come hai iniziato, da dove vengono i membri del team? Dove hanno fatto i precedenti membri del team vai 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 raccontarmi il ciclo di vita di un progetto su cui ha lavorato questa squadra? Come è iniziato e finito? Qual è la relazione del team con gli stakeholder, 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'idea di come funziona con quella squadra. Queste sono una comoda opportunità per il gestore assumente di descrivere veramente i pro / contro dell'ambiente di lavoro. È anche facile rilevare una risposta fasulla a tali domande che indicherebbe che c'è qualcosa che è nascosto.

Non so quanto sia prezioso chiedere, perché assumendo te (e forse altre persone), stanno cambiando la dinamica della squadra. Hanno chiaramente identificato alcune debolezze attuali, che si tratti di una mancanza di una particolare abilità o semplicemente della necessità che un altro sviluppatore svolga il lavoro e stiano cercando di correggere questa debolezza. Non appena aggiungono la persona o le persone al team, le dinamiche sono cambiate e la loro risposta potrebbe o non potrebbe essere più valida.

Probabilmente sarebbe più interessante chiedere informazioni sulle attuali pratiche del team e sui miglioramenti dei processi desiderati. Dove il team è ora in termini di come viene svolto il lavoro probabilmente non cambierà drasticamente tra l'intervista e la tua potenziale data di inizio (a meno che la tua data di inizio sia di diversi mesi) e chiedendo miglioramenti desiderati a processi, metodologie e strumenti potrebbe darti l'opportunità di indicare che potresti avere le competenze o le conoscenze per aiutare con questi sforzi.

Sì, ci sono più che pochi 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 chiedendo a qualcuno in HR questa domanda, potrebbero avere poca idea di cosa sia una risposta legittima. Persino il manager potrebbe non sapere se la squadra è ancora relativamente nuova e le cose non sono così conosciute in termini di dinamiche sociali e di risultati. L'altra parte è quanto sei preparato per la ginnastica linguistica che potresti iniziare con questa domanda perché c'è più di una piccola possibilità che una risposta sia così carica di parole d'ordine o vaga che ha poco valore se non sai come seguire con alcune domande più difficili. Ad esempio, se affermano di cooperare e fornire buoni risultati per una forza, sei pronto a interrogare ulteriormente?

D'altra parte, sarei più tentato di chiedere un po 'di storia della squadra:

• Da quanto tempo è unita questa squadra?
• Chi ha quanti anni qui?
• Quali ruoli tendono a giocare le varie persone in genere?

Sarebbe molto più utile per me della domanda che potrebbe essere percepita come piuttosto caricata nella mia mente. Mentre posso ammirare lo sforzo, mi chiedo quanto bene ogni azienda abbia studiato le dinamiche del team per trovare i loro punti di forza e stile al punto da poterli rivelare.

Il commento di chiederlo alla persona senza sapere quanto bene rispondono entra in quella "ginnastica linguistica" che menziono sopra perché posso facilmente prevedere qualcuno che affermi qualcosa di simile a "Assumiamo solo il meglio qui" o qualcos'altro questa è una formula per una risposta che richiederebbe un po 'di sondaggio per scoprire che 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 siano ostilità nascoste o che la squadra sia davvero un gruppo di persone mature che lavorano bene insieme.

Piuttosto che chiedere la debolezza, vorrei ribadire che la domanda è: "Qual è la più grande sfida del tuo team di sviluppo?" in modo che non sia considerato qualcuno intenzionalmente in grado di creare problemi, ma piuttosto di cercare di capire come viene vista la squadra.

Ad un certo punto, dovrebbero almeno essere rivolti al positivo se vogliono incoraggiarti ad unirti al team. Ogni responsabile della qualità / team leader dovrebbe porsi questa domanda su base giornaliera. Nessuno e niente è perfetto. Non è probabile che tu continui a fare ciò che funziona se non riesci a riconoscerlo.

Se trovano questa offensiva o non ritengono che sia il tuo posto per fare queste domande, potresti non volere il lavoro. Qualsiasi avversione alla domanda potrebbe essere un segno di insicurezza o almeno di scarsa comunicazione.

Personalmente, mi piacciono le persone che attaccano i problemi a testa alta perché sono disposti a riconoscerli (non è il punto 1 di 12?).

Spesso ci sono problemi al di fuori del controllo del leader: budget, codice legacy, dimensioni del personale, persone buone lasciano lavori più remunerativi, la natura del lavoro significa che gli sviluppatori devono ospitare membri del team in fusi orari diversi, gestione ha alcune tendenze di micro-gestione, politiche aziendali come codice di abbigliamento, orari d'ufficio, ecc. Ognuno di questi può avere un impatto negativo o limitare un team.

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

Ha lo scopo di ottenere lo stesso tipo di informazioni, ma in modo positivo e ottimista. In posti fantastici dove lavorare, scoprirai che spesso il tuo intervistatore inizierà a diffondere tutte le informazioni che desideri davvero conoscere per prendere una decisione!

Trovo 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 di farsi un'opinione su se stessi non è così facile da dire come una domanda su come la loro risposta agli eventi abbia portato a un risultato. Questo tipo di domande sono note come domande comportamentali e si basano sull'idea che il comportamento passato è il miglior predittore di comportamento futuro.

Quando si preparano domande di tipo comportamentale, un modo comune per modellarle è usando il metodo STAR, il che significa che la domanda è strutturata in modo tale da condurre le discussioni a una situazione specifica, compito, azione e risultato della situazione in discussione .

Ad esempio, "Da quando sono entrato nel team, qual è stato il maggior successo del team, cosa ne ha creato l'opportunità, quali azioni del team hanno avuto il maggiore impatto sul realizzarlo e quale è stato l'effetto di questo successo sull'azienda ? "

Penso che sia una bella domanda, anche se lo farei in modo un po 'diverso. In passato, ho fatto domande come:

• Quali sono le maggiori sfide tecniche nel tuo negozio?
• Com'è la portata / diffusione degli skillset nella tua squadra?
• Quanto è problematico il siloing nel tuo negozio?

Queste domande ti aiutano a esporre indirettamente le informazioni su come funziona il team. Le sfide tecniche rivelano l'atteggiamento della squadra nei confronti della (nuova) tecnologia. Range-in-skillsets rivela il background professionale all'interno del team. Siloing rivela problemi di proprietà del codice e di ego.