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

Ultimamente ho pensato alle domande sulle interviste e ho riflettuto sulle brutte esperienze di interviste che ho avuto in passato. Una nota particolare è quella in cui avevo chiesto all'intervistatore perché il team ha scelto di utilizzare EJB 3 su Spring nei propri prodotti. L'intervistatore mi ha praticamente strappato la faccia, urlando "Perché Spring non è il massimo e termina tutto lo sviluppo del software Java, vuoi questo lavoro o no?". In risposta a questo, gli ho detto che probabilmente questo non era il lavoro per me e sono uscito prontamente dall'intervista.

Sono stato informato all'inizio dell'intervista che l'azienda aveva un elevato turnover del personale, il prodotto che stavano lavorando era stato inizialmente creato in Modula-3, quindi portato su Perl e infine su Java. Mi è stato consegnato un opuscolo di 10 pagine di domande tecniche su Java, EJB, SQL e JDBC e mi sono state poste domande sugli stack tecnologici con cui ho lavorato. Quando mi è stato chiesto di porre domande, ho ritenuto ragionevole porre loro domande sul loro stack tecnologico e ottenere risposte ragionevoli, non per mandare in fiamme l'intervistatore.

Domanda: è una buona idea sondare le scelte architettoniche prese in un'intervista? Se no, perché?

Dal mio punto di vista, un'intervista è un processo a doppio senso. Se gli intervistatori mi stanno mettendo alla prova sulle mie capacità tecniche, ho tutto il diritto di porre loro le stesse domande a:

1) Scopri quali sono la loro mentalità e atteggiamenti verso lo sviluppo del software. 2) Determinare se il loro approccio è in linea con il modo in cui affrontare problemi di quel tipo.

È possibile che l'intervistatore che si è arrabbiato avesse scarse capacità di intervista e abbia dimenticato che un'intervista è uno scambio a due vie. Se mi fosse stato chiesto questo, avrei dato una risposta ragionevole, ma di certo non avrei cercato di mettere un intervistato in uno stato di mite capitolazione in cui la testa avanzava su e giù senza conversare.

Personalmente, trovo che intervistare le persone sia faticoso e stressante quanto essere intervistato. Ma è perché sono d'accordo con te sul fatto che il processo di intervista è uno scambio bilaterale.

Non mi importa quanto sei bravo, non voglio assumerti se non sarai felice di lavorare lì. È un gioco costoso da giocare. Quindi voglio rispondere a qualsiasi dubbio tu possa avere e mostrarti il ​​team e il prodotto così come sono, in modo che tu possa prendere una decisione informata.

Quando cerco un lavoro, voglio lavorare con qualcuno che condivida 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 proprio agio con una situazione.

Non mento in un'intervista, su entrambi i lati della scrivania, perché poi pensano che stanno assumendo qualcuno di diverso / andando a lavorare in un posto diverso. E mi aspetto lo stesso in cambio, dalla persona dall'altra parte dell'intervista.

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

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

Sì, è ok chiederti se sei sinceramente curioso e se la risposta è importante. Penso che chiederti dimostri 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 pronunci la domanda e doppiamente attento a come continui la conversazione. È facile imbattersi in decisioni difficili. L'ultima cosa che vuoi è che l'intervistatore creda che pensi di essere più intelligente di loro. Se sei sinceramente curioso, chiedi. Se pensi che abbiano 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 sulla tua architettura! Sono sempre alla ricerca di informazioni su come scegliere gli strumenti giusti ". (anche se, la sua domanda è strano - si chiede il motivo per cui hanno scelto di primavera, ed hanno scelto perché era non l'essere tutto fine tutti?)

Come persona che intervista frequentemente le persone, personalmente gradirei una discussione sul perché sono state fatte particolari scelte tecnologiche o progettuali, cosa faremmo diversamente ora se avessimo il lusso delle risorse o avessimo avviato un nuovo progetto. In genere lo vedrei come un segno di qualcuno che si preoccupa del loro mestiere e, a meno che i loro dogmi e il nostro non fossero compatibili, probabilmente classificherei quel candidato più di chiunque altro che risponda alle domande tecniche con competenza.

Attualmente sto lavorando a un progetto per un cliente che ha un'eredità di alcune decisioni architettoniche ben intenzionate ma mal implementate, e i candidati che esprimono curiosità per il mondo così com'è, e il percorso da seguire come lo vediamo, sono di solito i tipi di persone con cui vorremmo lavorare. Vogliamo persone in grado di fare la dovuta diligenza e convalida appropriate sulle decisioni di progettazione e implementazione del nostro team. In genere valutiamo le persone che portano sul tavolo qualcosa che non abbiamo o di cui non ne abbiamo abbastanza.

Quando sono stato candidato a un colloquio, prendo qualsiasi segno di ostilità o di difesa quando questi tipi di discussioni si verificano come un brutto segno, poiché un'organizzazione non in grado di auto-esame è di solito anche in un contesto tecnologico e di processo che essi sono incapaci e probabilmente non disposti a uscire. Se non vedo la motivazione per il miglioramento continuo nel team esistente, ci sono buone probabilità che non sarò felice lì.

che ha dormito una volta con un venditore Oracle e ha deciso che tutto lo sviluppo futuro verrà effettuato utilizzando i servizi Web Java 1.4, Oracle ERP e un frontend Borland C ++ utilizzando componenti della GUI di terze parti per lo più fuori produzione e preferiamo spendere $ 60.000 al mese tappando buchi per mantenere i clienti dal saltare la nave che rivisitare qualsiasi decisione e apportare miglioramenti permanenti che potrebbero portare nuove entrate se siamo 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 avrai il lusso di scegliere. Nessun concerto è perfetto, ma vuoi lavorare con persone che vogliono lavorare con te. (Mi preoccupo più di questo che delle scelte tecnologiche specifiche per la maggior parte del tempo.) Se qualcosa ha un cattivo odore, probabilmente lo è.

Quindi sì, chiedi via. Più curiosità per la nostra attività, il nostro processo e il nostro design, più seriamente, probabilmente prenderò un candidato. Ma non lavoro in un negozio Blub, quindi non posso dire se ti aiuterà a ottenere un lavoro Blub. Posso solo dire che funzionerebbe per te se vuoi lavorare con altre persone a cui importa del loro mestiere.

Domanda: è una buona idea sondare le scelte architettoniche prese in un'intervista? Se no, perché?

Va assolutamente bene, lo considero positivo.

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

Sarei preoccupato se un junior NON fosse interessato alle decisioni di progettazione, mostrerebbe una mancanza di curiosità / interesse nell'area tematica e non mostra alcun desiderio di migliorarsi.

Sono della mentalità è essenziale . Ho lavorato in troppi posti di lavoro con decisioni di progettazione senza senso o perché nessuno sapeva niente di meglio, non gli importava di imparare, o c'era un mandato da parte della direzione per usare tutto ciò che il CEO leggeva in una rivista / vedeva online / aveva qualcuno digli che era la "prossima grande cosa" senza alcuna considerazione delle alternative. Questi lavori erano tutti posti miserabili in cui lavorare.

Non dovresti necessariamente criticare una decisione di progettazione a meno che non sia qualcosa che sputa di fronte al buon senso o suoni semplicemente come un discorso folle, ma è comune mettere in discussione cose che sembrano "off" per scoprire se c'è una ragione legacy o qualcosa che è venuto ciò ha facilitato la necessità di utilizzare 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 conosco Java ma uso .NET quindi utilizzerò esempi .NET) Quando abbiamo scritto l'app non c'erano ORM maturi, quindi abbiamo usato le stored procedure con un livello gateway dati. Vorremmo passare a Entity Framework in futuro e un'altra cosa per ottenere una risposta come Usiamo solo procedure memorizzate. Entity Framework sembra spaventoso e potrebbe richiedere un lavoro di refactoring, e non possiamo refactificare nulla perché il CEO 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 raschiare.

Una società che ti offende mettendo in discussione le loro decisioni o volendo discutere del motivo per cui hanno scelto di utilizzare il Prodotto A invece del Prodotto B sta giocando la loro mano e dimostrando che non vogliono un pensatore libero ma un drone che non metterà in discussione, e è probabile che non sia il tipo di azienda per la quale uno sviluppatore competente desidera 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 piuttosto che la tecnologia Y? ".

Vuoi esprimerlo in modo da comunicare che sei generalmente interessato al processo decisionale all'interno del team. Nessuno vorrà ripassare ogni decisione legacy che la società abbia mai preso con un candidato.

Quando chiedi " Perché hai scelto la tecnologia X piuttosto che la tecnologia Y? ", Potresti scoprire che non sei d'accordo con la loro decisione (il che è ok ... ma può essere preso come ostile) o che vuoi vantarti di quanto conoscere le tecnologie in questione (che sarebbe fastidioso per chiunque), nonostante le tue buone intenzioni.

Mi piace chiedere a un intervistatore di parlarmi di una decisione di progettazione fallita che hanno preso e di ciò che è stato fatto dopo. Questo ti dà alcune buone informazioni:

1. Se il capo non può ammettere alcun errore di forma o fallimento temporaneo, è un capo per il quale probabilmente non vorrai lavorare.
2. Puoi dire come 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 si sta muovendo nella direzione sbagliata e deve essere ucciso o riavviato .

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

Qualche anno fa ero in un'intervista e mi erano state poste varie domande tecniche su un linguaggio di programmazione ... che non avevo fatto bene (60/40 corrette / errate). La discussione si è spostata sul progetto che avevano in mano e ho iniziato a porre domande sul design e quindi ho sottolineato un paio di problemi e limitazioni che avrebbero introdotto.

Mi è stato offerto il lavoro il giorno successivo. Purtroppo non sono stato in grado di accettarlo per motivi personali.

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

Non ho fatto molte interviste, ma, per esperienza, vorrei concludere:

a) Va bene se vuoi prendere una decisione informata se vuoi il lavoro;

b) Non va bene se hai già deciso di volere il lavoro.

Le persone possono facilmente essere offese da domande benigne sulle loro scelte. È un tratto terribilmente negativo, ma comune.

Ecco qualche consiglio

1. Chiedere perché abbiano scelto una soluzione esistente potrebbe essere una cattiva domanda, perché probabilmente al team di sviluppo non è stata data la possibilità di cambiarla o sceglierla.
2. Inoltre, probabilmente il team sa già perché la tecnologia non è stata la scelta migliore
3. Ma sfortunatamente, l'ultima cosa di cui ogni team di sviluppo ha bisogno sono le persone che cercano di cambiare l'architettura o di mettere in discussione le scelte che sono state fatte 10 anni fa - dà l'impressione che la loro tecnologia sia già roba legacy e che tali messaggi in giro nel team possano rendere gli sviluppatori infelici sulla situazione attuale
4. Quindi in un'intervista, l'ultima cosa che dovresti fare è dare l'impressione che ti lamenterai continuamente delle scelte su cui la squadra non ha alcun controllo