... per ogni ora in cui svolgo le mie responsabilità tecniche, quanti minuti immaginano avrei speso per svolgere attività amministrative, come implementazioni di babysitter, documentazione, riunioni non tecniche ecc.

L'idea alla base della tua domanda è ragionevole e ho preso in molte interviste nel corso degli anni. Non ho mai reagito male alla domanda né è stata ricevuta male quando l'ho posta.

Ma il modo in cui la tua frase la tua domanda mi farebbe certamente reagire male se ti intervistassi per un posizione tecnica in cui le tue responsabilità includevano implementazioni e documentazione, ad esempio. In pratica hai appena detto che non consideri queste attività importanti o parte della tua responsabilità tecnica.

Mi hai praticamente detto che:

1. Quello che considerare importante e ciò che considero importante non sono la stessa cosa.
2. Se è quello che ti aspetti, non mi adatterò alla cultura aziendale qui.
3. Potrei fare il lavoro tu chiedimi ma non lo tratterò mai con lo stesso rispetto e diligenza con cui faccio le cose che considero divertenti ed eccitanti.

Come ho detto nei miei commenti: il come chiedi è importante anche. E in questo caso il come ti avrebbe impedito di andare avanti nel processo.

Semplicemente chiedendo "Quanto tempo viene speso per attività non legate al lavoro?" ti aprirebbe la porta per porre domande più dirette e dirette senza ribaltare la mano.

Chiedo sempre "Com'è la giornata media del programmatore medio?" Ricevo spesso risposte scherzose, come "Cos'è una giornata media?" In questi casi, vado più in dettaglio.

Ma ecco la chiave, penso: metto sempre in chiaro che mi aspetto che ci sarà un po 'di tempo non di programmazione, e non ho problemi con questo. Quando dici "per ogni ora che passo a programmare, quanti minuti ..." stai dando l'impressione di avere un problema con quei minuti, di risentirti, che quello che vuoi veramente sentire è "zero".

Cerca di parlare su una scala più ampia e di mettere altre attività alla pari con la programmazione.

"In una settimana media, quale percentuale mi aspetto di spendere: programmazione, riunioni con altri sviluppatori, in riunioni con clienti o product manager, lavorando con un designer, svolgendo attività amministrative, ricerche, ecc. "

Sicuramente puoi (e dovresti) chiedere informazioni sulla metodologia di sviluppo utilizzata che dovrebbe dirti molto su quanto sovraccarico dovresti aspettarti.

Anziché chiedere quanto tempo ci si aspetterebbe di dedicare alle implementazioni di babysitter, è opportuno chiedere informazioni sul sistema di gestione delle build. Se l'intervistatore afferma di avere un sistema che crea e distribuisce automaticamente in produzione ogni giorno senza tempi di inattività, puoi essere abbastanza sicuro che non passerai molto tempo a gestire le distribuzioni. Se l'intervistatore prevede più sforzi manuali e coordina gli sforzi degli esseri umani in diversi gruppi, trascorrerai molto più tempo sulle distribuzioni.

Invece di chiedere quanto tempo spenderesti per scrivere la documentazione, chiederesti informazioni sull'approccio dell'organizzazione allo sviluppo del software. Se eseguono lo sviluppo tradizionale a cascata, ti aspetteresti che molto più tempo venga speso dagli sviluppatori per scrivere la documentazione (e molto più tempo sarebbe speso per scrivere i requisiti per gli sviluppatori). Se hanno un approccio più agile, ti aspetteresti meno tempo da dedicare alla generazione della documentazione (anche se, ovviamente, ciò significa anche che i requisiti che ottieni tenderanno ad essere meno dettagliati perché l'approccio presume che le cose cambieranno). / p>

Allo stesso modo, puoi chiedere come tengono traccia dei bug, come tengono traccia dei requisiti, come vengono testati, come danno la priorità agli elementi, ecc. Più è manuale il processo e più processo c'è, più tempo dovresti aspettarsi di spendere facendo compiti non tecnici.

Parlando del processo di sviluppo del software, generalmente dimostri di essere uno sviluppatore impegnato e generalmente rendi difficile per l'intervistatore (intenzionalmente o accidentalmente) fuorviarti. La maggior parte delle persone non ha un'idea veramente precisa di ciò su cui effettivamente trascorre il tempo nel corso della giornata - molte attività minori finiscono per ingoiare frazioni molto più grandi della giornata - quindi è difficile per la maggior parte delle persone indovinare con precisione su quanto tempo si impiega a lavorare sulle build. Questo è doppiamente vero quando le persone che intervistano sono manager che non svolgono queste attività da soli. È facile per i manager credere che un processo di costruzione sia relativamente fluido quando, in realtà, implica un sacco di interventi manuali, semplicemente perché nessuno porta l'inefficienza alla loro attenzione. Parlare del processo di sviluppo del software, tuttavia, tende ad essere molto più semplice poiché è molto più trasparente. È improbabile che un manager non sia a conoscenza, ad esempio, della riunione quotidiana in piedi se è quello che usa il team o che il manager non sarebbe in grado di descrivere almeno in generale come vengono pianificate e distribuite le versioni.

Se chiederlo direttamente non è consigliato, come faresti per estrarre tali informazioni in modo da raccogliere pregiudizi nei miei confronti e ridurre le mie possibilità di essere assunto.

Tutti gli sviluppatori di software dovranno svolgere queste attività. Mi spiace, ma dovrai svolgere un lavoro che non è codifica /

Detto questo, puoi chiedere cose come:

• "Qual è il tuo approccio sviluppare un'architettura di livello superiore ma nuova? " Questo fornisce informazioni sul numero di riunioni di brainstorming / pianificazione che avrai.
• "Come viene mantenuto il codice esistente?" Questo permette di capire quale documentazione viene creata come parte del processo, ed è facile chiedersi a questo proposito
• "Qual è il processo per la distribuzione di nuovo codice / revisioni?" Viene coinvolto lo sviluppatore in questo processo ..
• "Quanto sono coinvolti gli sviluppatori di software nella ricerca delle esigenze dei clienti e nello sviluppo delle specifiche?" Informazioni dettagliate su quanto tempo dedicherai all'ambito, al brainstorming delle funzionalità, ecc.
• "Come monitori i bug / le funzionalità del software da sviluppare?" Aiuta a fornire informazioni dettagliate sulla documentazione / monitoraggio dei problemi.
• "Qual è la parte che ti piace di meno del tuo lavoro?" Quando viene chiesto ad altri sviluppatori, può essere incredibilmente perspicace in quanto questa è spesso la parte meno preferita dagli sviluppatori.

Queste domande, poste in una combinazione, ti daranno molto chiaramente una risposta alla tua domanda . Si noti inoltre che mentre la maggior parte di queste domande sono specifiche del software, l'idea generale si applica a quasi tutti i lavori, ma piuttosto che software / codice si sostituisce semplicemente qualsiasi prodotto su cui si lavora (materiale di marketing, widget, ecc.) Nelle domande.

In sostanza, quello che vorrei scoprire è: per ogni ora in cui svolgo le mie responsabilità tecniche, quanti minuti immaginano avrei speso per svolgere attività amministrative, come implementazioni di babysitter, documentazione, riunioni non tecniche ecc. .

Probabilmente prima mi chiedo se l'azienda dispone o meno di processi formali che consentano questo tipo di contabilità. Se l'organizzazione è una start-up, potrebbe esserci una mentalità da cowboy in cui questo tipo di monitoraggio non viene eseguito e quindi potresti avere uno sguardo potenzialmente vuoto.

Ti rendi conto che "fare da babysitter implementazioni "e" documentazione "possono essere considerate tecniche dal punto di vista della gestione, anche se non da altri sviluppatori, giusto? Ci sono problemi di comunicazione qui oltre a prestare attenzione al tuo vocabolario qui.

Devi chiedere esempi per vedere quanto sono dettagliati i requisiti della documentazione e confrontarli con altre posizioni che hai ricoperto. Quanto "tempo" dovrai dedicare a loro dipenderà dalle tue capacità di scrittura.

È più importante valutare le loro percezioni sulla quantità di tempo che gli sviluppatori trascorrono attualmente in quest'area. Pensano che abbia bisogno di miglioramenti? Sono aperti alla ricerca di strumenti per rendere il processo più automatizzato?

Ogni programmatore preferirebbe scrivere codice piuttosto che fare qualsiasi altra cosa. Lo ottengono. Quello che non vogliono è qualcuno che mostri una tale avversione nei suoi confronti che potrebbe essere difficile lavorarci e riluttante a fare il lavoro sporco. Concentrati maggiormente sulla ricerca del loro stile di gestione per vedere se sono disponibili a fare miglioramenti in quest'area.

Direi che è opportuno porre questa domanda sul ruolo.

Il colloquio è un processo a due vie, in cui l'azienda impara a conoscere te, le tue capacità e se pensa che ti adatterai al team. Il secondo è ottenere informazioni sul lavoro che ci si aspetta da svolgere e sull'ambiente (sia fisico che digitale) in cui ci si aspetta che lavoriate.

Molte persone suggeriscono di porre una domanda come questa suggerirebbe intervistatore che "vuoi solo fare quello che vuoi" e qualsiasi altra cosa è un peso aggiunto alla tua lotta quotidiana.

Sono d'accordo e in disaccordo, stai dando questa impressione ad alcuni intervistatori, ma allo stesso tempo tempo se stai cercando un lavoro che abbia una bassa impronta burocratica, sei perfettamente autorizzato a tenerne conto nel tuo processo decisionale.

Alla fine della giornata ci sono molte domande inappropriate da porre. Non penso che questo sia uno di questi perché la tua felicità è un fattore importante nella tua produttività in un lavoro. Fai solo attenzione che COME lo chiedi è di reale importanza.

Se lo consideri una seccatura, una lotta quotidiana, un peso aggiunto, è probabile che tu venga visto in una luce negativa.

È tutta una questione di positività, vuoi dare l'impressione che darai il massimo, che lavorerai con l'azienda e non contro di essa!

Come altri hanno detto, salterei le parole "impronta burocratica organizzativa". Sembra elegante e intelligente, ma potrebbe facilmente sembrare malizioso. I manager che ti stanno intervistando potrebbero benissimo essere i responsabili dell '"impronta burocratica organizzativa" e hanno fatto qualunque burocrazia (potenzialmente orribile) per un motivo che consideravano un valore sufficiente per giustificare il tempo di tutti. Potrebbero persino essere orgogliosi di questo lavoro e vederlo come un vero valore aggiunto per l'azienda, quindi riassumere tutto come la burocrazia (che ha una connotazione negativa in sé e per sé) non è probabile che ti conquisti. I colleghi singoli collaboratori potrebbero trovarla una frase divertente e intelligente - certamente tutti noi abbiamo dovuto soffermarci su un mucchio di burocrazia abbastanza grande da essere un'impronta fatta dall'abominevole pupazzo di neve, ma quando sei il pupazzo di neve, potresti non trovare è divertente.

Sembra che le tue maggiori preoccupazioni siano nel tempo speso su cose che chiamerei "mitigazione del rischio" a livello di singolo collaboratore. Riunioni, documentazione e verifica della distribuzione cercano di mitigare gli errori che si verificano tra gli altri membri del progetto quando le persone non riescono a comunicare chiaramente su una parte importante del lavoro.

Mi piacciono molte delle risposte fornite da altri poster, qui, e sono restio a ripetere questi molti buoni esempi, quindi mi limiterò a sottolineare che ci sono alcune strategie di base:

• Domande sulla giornata nella vita : entra nei dettagli delle attività che ti aspetti di svolgere e della suddivisione del lavoro in un dato giorno, settimana, fase può essere. Parla dei processi, parla di particolari aree di interesse del progetto, parla delle dinamiche del team, parla degli strumenti e dei processi che utilizzano per rendere più veloce il lavoro meccanico e ripetibile.

• Che cosa ci interessa di più delle Domande : settori diversi hanno driver diversi. Il governo, la difesa e l'assistenza sanitaria spesso hanno fattori di qualità molto forti: passerai molto tempo a documentare il codice in modo che qualcun altro possa mantenerlo senza rovinare le cose, molto tempo a testare e controllare che tutto funzioni, molto tempo ad assicurarti che le specifiche siano chiare e che le distribuzioni siano eseguite correttamente. In un sistema critico per la vita, non fare errori è più importante che ottenere una funzione extra. Nell'e-commerce, nei social media e in altri prodotti in uno spazio di funzionalità molto competitivo, ottenere rapidamente qualcosa sul mercato è il nome del gioco. C'è garanzia di qualità, ma se arriva il momento critico, lo porteranno sul mercato, anche se qualcosa di minore (come la documentazione) non viene fatto. Quindi, chiedi quali sono le priorità dell'azienda e come si collegano al modo in cui lavoreresti come sviluppatore.

• Domande sulla cultura aziendale : è una dittatura? Una cultura del consenso? un piccolo gruppo di illuminati che gestisce l'attività? Come vengono prese le decisioni, come vengono risolti i problemi, perché e quando si tengono riunioni formali? Il modo in cui l'organizzazione pianifica per andare avanti e superare gli ostacoli influenzerà notevolmente il numero di riunioni e la produttività di tali riunioni.

Chiederei in realtà un mix di tutti e tre in una data intervista, e sceglierei tra loro in base all'intervistatore: sia il suo stile personale, sia il suo posto nell'organizzazione sarebbero fattori. I manager sono più propensi a essere in grado di rispondere alle domande "che cosa ci interessa" in modo più chiaro e succinto. I singoli contributori possono essere più accurati alle domande del "giorno della vita". Spesso trovo che il rappresentante delle risorse umane sia migliore di quanto si pensi alle domande sulla "cultura aziendale" perché vede il team dall'esterno guardare dentro. Ma questo non significa che dovresti limitare rigorosamente l'obiettivo delle tue domande. Ad esempio, può essere MOLTO indicativo se il singolo collaboratore e il manager non sono molto d'accordo su nessuna di queste domande, in particolare su "ciò che ci interessa", se il team sta lavorando da un punto di vista e la direzione vede un altro che stai cercando a un team che potrebbe essere diretto verso un atterraggio di fortuna per altri motivi oltre a Death by Paperwork.

Nel tempo, ho sviluppato un senso parlando con gli altri nel mio settore di dove i miei tipi di lavoro preferiti arrivano nel regno delle "impronte burocratiche dell'organizzazione": mi piacciono le sfide di tipo overhead ad alto rischio, alta complessità, alto costo, alto burocratico ... ma mi rendo anche conto di quanto più velocemente i miei colleghi di altri settori si muovono ... nel tempo, il mio Il senso generale è stato che nella maggior parte dei casi i concorrenti di un settore opereranno in modo molto simile, quindi se so come funziona uno, posso fare alcune generalizzazioni sul successivo e entrare nei dettagli abbastanza rapidamente.