È saggio chiedere delle decisioni di progettazione prese su un prodotto durante un colloquio? [chiuso]

Personalmente, trovo che intervistare le persone sia tanto estenuante e stressante quanto essere intervistato. Ma è perché sono d'accordo con te sul fatto che il processo dell'intervista è uno scambio a due vie.

Non mi interessa quanto sei bravo, non voglio assumerti se non sarai felice a lavorare lì. È un gioco costoso da giocare. Quindi voglio rispondere a tutte le preoccupazioni che potresti avere e mostrarti il team e il prodotto così come sono, in modo da poter prendere una decisione informata.

Quando cerco un lavoro, voglio lavorare con qualcuno che condivide questo atteggiamento. E, anche se sospetto di conoscere le risposte alle domande, chiederò loro solo di vedere la reazione. L'aggressività non è mai un segno di qualcuno a suo agio in una situazione.

Non giaccio in un'intervista, da entrambi i lati della scrivania, perché poi pensano di assumere qualcuno di diverso / andare a lavorare in un posto diverso. E mi aspetto lo stesso in cambio, dalla persona dall'altra parte dell'intervista.

Sfortunatamente, ciò significa che occasionalmente mi imbatto in interviste come quella che hai descritto. Sono esperienze orribili? Sì. Vengo fuori da lì sapendo esattamente dove l'intervista è andata storta? Sì.

Ma sono molto sicuro che ogni orribile esperienza sarebbe stata notevolmente peggiore se avessi ottenuto il lavoro o assunto la persona sbagliata? Diavolo sì.

Sì, va bene chiedere se sei sinceramente curioso e se la risposta è importante. Penso che chiedere ti mostri che c'è più di un modo per fare le cose, e mostra che sei interessato a come è stato scritto il software.

Detto questo, devi stare molto attento a come pronuncia la domanda, e doppiamente attento a come continui la conversazione. È facile imbattersi in sfide impegnative. L'ultima cosa che vuoi è che l'intervistatore creda che tu pensi di essere più intelligente di loro. Se sei sinceramente curioso, chiedi. Se pensi di aver fatto una scelta sbagliata, tieni la bocca chiusa.

Se fossi stato nella situazione descritta nella domanda, invece di uscire avrei potuto dire qualcosa del tipo "oh sì, sono d'accordo che la primavera non è sicuramente la soluzione giusta per tutto. Grazie per avermi fatto sapere qualcosa su la tua architettura! Sono sempre alla ricerca di informazioni su come scegliere gli strumenti giusti ". (però, la tua domanda è strana - chiedi perché hanno scelto la primavera, e l'hanno scelta perché era non la fine di tutto?)

Come qualcuno che intervista spesso le persone, personalmente accolgo con favore una discussione sul perché sono state fatte particolari scelte tecnologiche o di design, cosa faremmo ora diversamente se avessimo il lusso delle risorse o avessimo iniziato un nuovo progetto. Generalmente lo vedo come un segno di qualcuno a cui importa del proprio mestiere e, a meno che i loro dogmi e i nostri non fossero compatibili, probabilmente valuterò quel candidato più di qualcuno che risponda con competenza a domande tecniche.

Attualmente sto lavorando a un progetto per un cliente che ha un'eredità di alcune decisioni architettoniche ben intenzionate ma attuate male, e candidati che esprimono curiosità per il mondo così com'è, e il percorso in avanti come lo vediamo noi, di solito sono i tipi di persone con cui vorremmo lavorare. Vogliamo persone che siano in grado di fare la debita diligenza e la convalida sulle decisioni di progettazione e implementazione del nostro team. Generalmente apprezziamo le persone che portano qualcosa sul tavolo che non abbiamo o non ne hanno abbastanza.

Quando sono stato candidato in un'intervista, prendo qualsiasi segno di ostilità o di difesa quando questi tipi di discussioni si presentano come un brutto segno, in quanto un'organizzazione che non è in grado di auto-esaminare è solitamente anche in un processo tecnologico e che sono incapaci e probabilmente non disposti a uscire. Se non vedo la motivazione per il miglioramento continuo della squadra esistente, ci sono buone probabilità che non sarò felice lì.

Se sono entrato e hanno detto, "Sì, abbiamo questa app legacy che non siamo felici di mantenere ma porta ancora entrate sufficienti per coprire tutti i nostri stipendi, e vogliamo rendere il codice base più gestibile rifattorizzando i punti di dolore, o migrando il componente x alla tecnologia y "o" abbiamo scelto la tecnologia come tecnologia overb perché avevamo più esperienza e la tecnologia b era ancora agli inizi quando abbiamo iniziato, siamo aperti a cambiare ma è un processo lento e non siamo nella posizione di buttare fuori la nostra base di codice esistente ", posso credere che sarà un'esperienza migliore per me che se ascoltassi" Sì, siamo bloccati su Borland C ++ Builder versione 6 e gli sviluppatori non sono Sono stati autorizzati a prendere decisioni tecniche perché sono già state fatte dal fratello del CEO, che ha dormito con un venditore Oracle una volta e ha deciso che tutto lo sviluppo futuro sarà fatto usando i servizi web Java 1.4, Oracle ERP e un frontend in Borland C ++ usando componenti di GUI di terze parti per lo più interrotte e noi Piuttosto, spendere $ 60.000 al mese per colmare le lacune per impedire ai clienti di saltare la nave piuttosto che rivedere qualsiasi decisione e apportare miglioramenti permanenti che potrebbero portare nuove entrate se saremo fortunati. Non scuotere la barca, cosa c'è che non va in te. "

Supponendo che ti trovi in un'area con altri lavori tecnologici, o che sei disposto a trasferirti, probabilmente hai il lusso di scegliere. Nessun concerto è perfetto, ma tu vuoi lavorare con persone che vogliono lavorare con te. (Mi interessa di più delle scelte tecnologiche specifiche la maggior parte delle volte.) Se qualcosa ha un cattivo odore, probabilmente lo è.

Quindi sì, chiedilo. Maggiore è la curiosità nei confronti della nostra attività, del nostro processo e del nostro design, più seriamente sono propenso a candidarmi. Ma io non lavoro in un negozio di Blub, quindi non posso dire se ti aiuterà a ottenere un lavoro da Blub. Posso solo dire che potrebbe funzionare per te se vuoi lavorare con altre persone a cui interessa il loro mestiere.

Question: Is it a good idea to probe on architectural choices taken in an interview? If not, why?

È assolutamente soddisfacente, lo considererei un aspetto positivo.

Se il tuo intervistatore non può gestirlo, dice molto su di loro, non su di te.

Sarei preoccupato se un giovane non fosse interessato alle decisioni di design, mostrerebbe una mancanza di curiosità / interesse per l'argomento e non mostrerebbe alcun desiderio di migliorarsi.

Sono del parere che sia essenziale . Ho lavorato a troppi lavori con decisioni di design insensate perché nessuno sapeva fare meglio, non gli importava di imparare, o c'era un mandato da parte della direzione per usare qualsiasi cosa l'amministratore delegato leggesse in una rivista / visto online / qualcuno digli che era la "prossima grande cosa" senza alcuna considerazione delle alternative. Questi lavori erano tutti posti miserabili per lavorare.

Non devi necessariamente criticare una decisione di progettazione a meno che non sia qualcosa che sputa di buon senso o suoni come matti, ma è normale mettere in discussione cose che sembrano "spente" per scoprire se c'è una ragione legacy o è emerso qualcosa che ha facilitato l'utilizzo di un approccio non ortodosso.

Fare domande come questa ha anche l'effetto di misurare l'interesse dell'azienda per il miglioramento e la competenza. Come ha detto qualcun altro sopra, è una cosa se ottieni una risposta del tipo (non so Java ma uso .NET, quindi userò esempi .NET) Quando abbiamo scritto l'app non c'erano ORM maturi, quindi abbiamo usato stored procedure con un livello gateway dati. Ci piacerebbe passare a Entity Framework in futuro e un'altra cosa interamente per ottenere una risposta come Utilizziamo solo stored procedure. Entity Framework sembra spaventoso e potrebbe richiedere un lavoro di refactoring, e non possiamo refactoring nulla perché l'amministratore delegato ha una lista di nuove funzionalità su cui vuole che lavoriamo, e se passiamo il tempo a guardare Entity Framework ci licenzierà per perdere tempo . Uno indica la comprensione e il desiderio di migliorare, l'altro indica un ambiente mediocre nel migliore dei casi in cui ognuno fa il minimo indispensabile per perlustrare.

Una società che si è offesa quando ha messo in discussione le proprie decisioni o ha voluto discutere perché ha scelto di usare il Prodotto A invece del Prodotto B sta giocando la propria mano e sta mostrando che non vogliono un pensatore libero ma un drone che non vuole domanda, e le probabilità sono che non è il tipo di azienda per cui uno sviluppatore competente vuole lavorare.

risposta: è una buona idea chiedere informazioni sul processo decisionale architettonico. Ma devi stare attento a come fai queste domande.

In poche parole: dovresti chiedere " come hai scelto la tecnologia X rispetto alla tecnologia Y? ".

Vuoi esprimerlo in un modo per comunicare che sei generalmente interessato al processo decisionale all'interno del team. Nessuno vorrà esaminare tutte le decisioni legacy che la compagnia ha mai fatto con un candidato.

Quando chiedi " Perché hai scelto la tecnologia X rispetto alla tecnologia Y? ", potrebbe non essere d'accordo con la loro decisione (che è ok ... ma può essere considerata ostile) o che vuoi vantarti di quanto sai sulle tecnologie in questione (cosa che sarebbe seccante per chiunque), nonostante le tue buone intenzioni.

Sono appassionato di chiedere a un intervistatore di parlarmi di una decisione progettuale fallita che hanno preso e di cosa è stato fatto dopo. Questo ti dà alcune buone informazioni:

1. Se il capo non può ammettere alcun errore di forma o errore temporaneo, è un capo per cui probabilmente non vuoi lavorare.
2. Puoi capire in che modo l'azienda gestisce una situazione stressante.

Potrebbe non essere popolare, ma ho sempre un grande rispetto per i manager con le pietre per riconoscere che un progetto fallirà e lo ucciderà per smettere di sprecare soldi, o che qualcosa è diretto nella direzione sbagliata e deve essere ucciso o riavviato.

In definitiva, se parli di soddisfazione sul lavoro, la tecnologia (linguaggio / piattaforma / compilatore / qualsiasi altra cosa) non importa tanto quanto le personalità coinvolte e l'ambiente di lavoro.

Alcuni anni fa ero in un'intervista e mi erano state poste varie domande tecniche su un linguaggio di programmazione ... su cui non avevo fatto bene (60/40 corretto / errato). La discussione è passata al progetto che avevano in mano e ho iniziato a fare domande sul design e poi ho evidenziato un paio di problemi e limitazioni che avrebbero introdotto.

Mi è stato offerto il lavoro il giorno successivo. Purtroppo non ho potuto prenderlo per motivi personali.

Fare domande sulla progettazione non dovrebbe essere un problema se si tratta di domande intelligenti, soprattutto se è possibile collegarle alla loro attività.

Non ho fatto molte interviste, ma, dalla tua esperienza, ho concluso:

a) Va bene se vuoi prendere una decisione informata sul fatto che tu voglia il lavoro;

b) Non è OK se hai già deciso di volere il lavoro.

Le persone possono facilmente essere offese da benevoli quentioni sulle loro scelte. Questa è una caratteristica terribilmente negativa, ma comune.

Ecco alcuni consigli

1. Chiedere perché hanno scelto una soluzione esistente potrebbe essere una cattiva domanda, perché probabilmente il team di sviluppo non ha avuto la possibilità di cambiarlo o sceglierlo.
2. Probabilmente il team sa già perché la tecnologia non è stata la scelta migliore
3. Ma sfortunatamente, l'ultima cosa di cui un team di sviluppo ha bisogno è che le persone provino a cambiare l'architettura o le scelte di discussione fatte 10 anni fa: dà l'impressione che la loro tecnologia sia già vecchia roba e che i messaggi che circolano nel team possano rendere gli sviluppatori insoddisfatti della situazione attuale
4. Così in un'intervista, l'ultima cosa che dovresti fare è dare l'impressione di lamentarti sempre delle scelte che la squadra non ha il controllo su