Come evitare di essere impiegati da aziende candidate alle storie di DailyWTF? [chiuso]

Sto leggendo gli archivi del Daily WTF e in particolare quelle storie sulle aziende legate all'IT che hanno un approccio completamente sbagliato allo sviluppo del software, al lavoro di uno sviluppatore, ecc.

Alcune storie sono totalmente orribili: un'azienda non ha una rete locale per motivi di sicurezza, un'altra ha un server di controllo del codice sorgente a cui può accedere solo il manager , ecc. Aggiungete tutte quelle storie sui manager che non conoscono nulla del loro lavoro e prendere decisioni stupide senza ascoltare nessuno.

Il fatto è che non vedo come sapere se sarai impiegato da tale società durante un'intervista. Certo, a volte, un intervistatore racconta cose strane che ti danno l'idea che qualcosa vada molto male con l'azienda (nel mio caso, l'ultimo manager ha detto che avrei dovuto lavorare il 100% del mio tempo tramite Desktop remoto, collegato a un vecchio e slooooow machine, perché "evita a più persone di modificare lo stesso codice sorgente" ; forse dovrei spiegargli cos'è SVN).

Ma nella maggior parte dei casi, non sarai in grado di ottenere informazioni sufficienti durante il colloquio per ottenere l'immagine esatta di un'azienda.

Quindi, come evitare di essere impiegati da questo tipo di aziende?

• Ho pensato di chiedere di vedere alcuni documenti come la guida alla documentazione o le linee guida sullo stile del codice . Il problema è che vivo in Francia e qui, la maggior parte delle aziende non ha affatto quei documenti, e nei rari casi in cui esistono quei documenti, sono obsoleti, scritti male, mai usati o ti costringono a fare cose che non hanno alcun senso .

• Ho anche pensato di chiedere di vedere come funzionano effettivamente i programmatori . Ma vedendo che hanno schermi doppi o "arredi in stile art-tardo-moderni" non significa che non hanno persone che prendono decisioni strane, rendendo impossibile lavorare lì.

Sei stato in tali situazioni? Che cosa hai provato? Ha funzionato?

Ricorda che le interviste sono una strada a doppio senso. Poni loro domande aperte che ti facciano sapere che sanno cosa stanno facendo. E impara a "leggere tra le righe" quando valuti le loro risposte. Per esempio:

Come potete assicurarvi che il software che state scrivendo non faccia schifo? (riformulato in qualcosa di più "appropriato" se sei noioso)

Buona risposta: "Utilizziamo test unitari, disponiamo di un dipartimento di controllo qualità e revisioni del codice".

Non deve essere questo. Né la persona che stai intervistando deve avere la stessa risposta a ciò che ho dato. Per lo più stai solo cercando di assicurarti che la società apprezzi il codice che scrive in una certa misura e non lo spingerà fuori dalla porta con abbandono spericolato.

Risposta errata: "Beh, intendevamo fare più di quelle cose" unit test ". Non ci siamo ancora fatti un'idea"

Ancora una volta, l'attenzione è meno sui test unitari e più sull'atteggiamento che l'intervistatore assume sulla questione. In generale, "Sappiamo di averne bisogno, non l'abbiamo fatto" è una bandiera rossa. Ciò significa una delle diverse possibilità:

1. I tuoi colleghi saranno pigri.
2. La direzione non dà il tempo di utilizzare il processo corretto.
3. I tuoi colleghi non sono abbastanza intelligenti da capire i test unitari.

Nessuno di questi è buono (ma alcuni sono peggiori di altri).

Descrivi il processo utilizzato dalla tua azienda per aggiungere una funzionalità (dalla decisione che la funzionalità è necessaria per spedirla al cliente).

Buona risposta: "Gli uomini d'affari decidono che una funzionalità è una buona idea e consultano i programmatori per vedere quanto sia facilmente implementabile. I programmatori e il personale tecnico decidono su un'architettura e la implementano. Un team di rilascio la spinge in libertà ".

Risposta errata: "Gli uomini d'affari dicono ai programmatori cosa fare e lo fanno."

Come sopra, la risposta in sé non è importante quanto l'atteggiamento. La buona risposta indica che il lato commerciale e il lato tecnico lavorano insieme per creare un prodotto. La cattiva risposta indica che la direzione vede i programmatori come dattilografi pagati in eccesso.

In sintesi , ricorda di porre le domande giuste durante l'intervista. E ricorda che le risposte particolari non sono importanti quanto l'atteggiamento dietro quelle risposte. Infine, non trattenerti . Fare domande difficili indica che sei veramente interessato al lavoro e che pensi di essere abbastanza bravo da essere un po 'esigente su chi ti assumerà.

Potresti dare loro il Joel Test:

1. Usi il controllo del codice sorgente?
2. Puoi creare una build in un solo passaggio?
3. Realizzi build giornaliere?
4. Hai un database di bug?
5. Correggi i bug prima di scrivere un nuovo codice?
6. Hai un programma aggiornato?
7. Hai una specifica?
8. I programmatori hanno condizioni di lavoro silenziose?
9. Usi i migliori strumenti che il denaro può comprare?
10. Hai tester?
11. I nuovi candidati scrivono codice durante il loro colloquio?
12. Fai test di usabilità in corridoio?

Mantieni il tuo curriculum in circolazione per circa un mese circa dopo essere stato assunto, e se le cose non sono all'altezza del tabacco, non aver paura di cogliere un'altra opportunità. Le aziende vedranno spesso il tuo impiego come periodo di prova per un periodo di tempo perché vogliono assicurarsi che tu lavori così come hai intervistato. È giusto che tu faccia lo stesso se le cose sono davvero a livello di WTF giornaliero.

Prenderò la posizione pessimista e non tradizionalmente ingegnere su questo.

Non puoi.

Ogni azienda, nessuna eccezione, è candidata per le storie WTF giornaliere. Questo perché ogni persona, senza eccezioni, non importa quale sia la sua professione e qualunque sia la sua esperienza, può essere un cretino in alcuni aspetti della vita professionale prescelta.

Sì. Questo include te, la persona che legge questo. (Se non credi che questo valga per te, penso che abbiamo appena trovato una delle tue aree di incompetenza ....)

Forse potresti provare a vedere le cose in modo diverso.

Essere assunti da una società sotto i riflettori di The Daily WTF è un'opportunità per te per mostrare come risolvere i problemi. Enormi problemi.

Puoi vedere quelle difficoltà come opportunità .

Invece di usare Joel Test per le avoidaziende, usalo per improveloro.

Cosa potrebbe esserci di più eccitante di così?

Se vieni in compagnia con il tuo cavallo bianco come Napoleone dicendo loro che sono tutti sbagliati, verrai espulso molto rapidamente.

L'opportunità è che sarai in grado di fare proposte costruttive , supportate da fatti e riferimenti . Se fatto come descritto nella frase precedente, ti verrà proposto di occupartene per la maggior parte del tempo (questa è l'occasione). In pochissimi casi, verrai ignorato.

Ricorda che ogni intervista è una strada a doppio senso. Il datore di lavoro sta cercando di determinare se sei un buon candidato. Allo stesso modo, dovresti provare a determinare se vale la pena lavorare per l'azienda. Fai molte domande. Scopri cosa è importante per te e chiediglielo. Chiedi ai tuoi intervistatori cosa gli piace e non piace dell'azienda.

Inoltre, secondo la raccomandazione dell'altro poster di dare loro il Joel Test .

Anche un manager psicotico megalomane può gestire una squadra che supera il test Joel. Come reagiscono quando le scadenze non vengono rispettate? Il CIO riferisce al CEO o al CFO? Questo può darti un'idea di quanto sia importante l'IT in un'azienda non software.

Perché la posizione è disponibile? Hanno molto turnover?

Cerca modi per vedere se i programmatori sono sovraccarichi. Nessuno ha avuto una vacanza da diversi mesi a un anno? Non puoi battere un'azienda che distribuisce il tempo delle vacanze, ma nessuno sente di poterlo mai prendere.

È possibile modificare cattive pratiche di test e sistemi di controllo del codice. Non posso curare il matto.

Ecco cosa farei se fossi in te:

• prova a ottenere la possibilità di intervistare uno o più programmatori dell'azienda e chiedi loro qual è la giornata tipo nel loro lavoro. Potrebbe essere difficile chiedere se non lo forniscono, ma una società che lo fornisce è un enorme vantaggio nel mio libro
• chiedi loro come viene sviluppata una nuova funzionalità, in genere, e come il lavoro viene condiviso tra i programmatori.

Entrambe le domande finiscono per essere la stessa cosa, poste in modo diverso a persone diverse. Punti importanti:

• Come vengono risolti i disaccordi su questioni tecniche nel team
• Come viene condiviso il lavoro tra gli sviluppatori
• Come vengono assegnati i bug alle persone
• Come prendi la decisione di progettare internamente, esternalizzare, fuori dagli scaffali?
• Come giudica il fallimento / successo del progetto

Questo in aggiunta al test Joel. Nota che non esiste una risposta "giusta": dipende da cosa stai cercando da solo, che tipo di azienda stai cercando, che tipo di azienda che è (ad esempio una startup avrà meno probabilità di essere in grado di permettersi il migliori strumenti rispetto a una fortuna 500). Se la persona non può rispondere a questa domanda, è quasi sicuramente un brutto segno: molto probabilmente non hanno nemmeno pensato a questi problemi.

Ci sono un certo numero di ovvi, due diligence tipi di cose che puoi fare, come porre loro alcune domande sul loro processo, o provare a parlare, o anche a lavorare brevemente, con un altro sviluppatore lì. Per quanto sia buono, è anche facilmente falsificabile - anche i peggiori manager spesso conoscono le cose giuste da dire sulla loro metodologia (sapere cosa dire senza capire il "perché" è ciò che li rende cattivi manager in primo luogo, giusto ?) e la maggior parte dei programmatori non vorrà sprezzare la compagnia per un possibile noleggio - perché rischiare che torni a qualcuno per uno dei milioni di intervistati che passa attraverso il sistema? (in una società malsana in cui le critiche sono ... disapprovate ... questo può essere un rischio reale)

Tuttavia, puoi guardare cose più soggettive: i gestori sembrano pieni di parole d'ordine o onesti? Ti sembra un ambiente sano?

Qual è la qualità delle domande e la conoscenza dei tuoi intervistatori: questo è il processo con cui tutti hanno lavorato, ricorda. Ti stanno facendo domande stupide? Domanda di tipo HR? Le domande sulla codifica sono troppo semplici?

Come altri hanno già detto, le interviste sono una strada a doppio senso ...

Ma qui c'è un sottile fattore psicologico che penso che molte persone non facciano bene: essere intimiditi nel fare un lavoro schifoso. Questo è più un problema per i giovani, ma siamo tutti vulnerabili ad esso.

Penso che molte persone abbiano la mentalità secondo cui non si può davvero cambiare il comportamento aziendale scadente, quindi prendiamo troppi brutti sentimenti quando decidiamo di accettare un'offerta di lavoro. Parte della psicologia qui è anche la relazione di potere tra datore di lavoro e dipendente - specialmente in un'economia negativa o competitiva - ci si sente come se dovessero dare un sacco di margine di manovra, anche di fronte a cattivi odori di lavoro - come Joel tristemente fallito Test, ecc.

Quindi, in effetti, quello che sto dicendo è che molti di noi accettano lavori sapendo che saranno lavori DailyWTF. Il trucco è essere più esigenti, esercitarsi con forza negli intervistatori - e semplicemente non accettare lavori scadenti a meno che tu non sia assolutamente disperato. Naturalmente c'è un equilibrio, ma vale davvero la pena esaminare i tuoi sentimenti quando decidi se un'offerta di lavoro sul tavolo è un WTF o meno. È facile convincerti che sei solo "troppo esigente e poco flessibile", quando in realtà stai ignorando un cattivo odore di lavoro.