Intervista assegnazione: produzione, senza bug o campane e fischietti? [chiuso]

Cosa faresti se questo fosse un vero e proprio progetto da fare per la compagnia con cui stai intervistando? Penso che sarebbe meglio avere un codice privo di bug che implementa il 100% delle specifiche, oltre a artefatti (documenti di progettazione, piani di test, ecc.) O suggerimenti per il miglioramento. Penso che la tua idea di fornire una lista TODO sia eccellente - mostrerebbe il tipo di valore che porteresti nella posizione, oltre alle tue pure capacità di codifica - mentre dimostrerai anche che non sei un programmatore "da cowboy" che sta andando liberamente estendere o ignorare le specifiche per un progetto. (Solo i miei due centesimi)

Non aggiungere funzionalità extra, questo aggiungerà rischi per la consegna di successo - non saltare in testa. Piuttosto, considera il seguente

• Unit test your solution
• Aggiungi test BDD (come SpecFlow e Rhino Mocks)
• Implementa il test delle mutazioni
• Aggiungi un po 'di documentazione: come avviare test automatici, come eseguire tun tun e vedere cosa sta succedendo, come installare etc
• Aggiungi TODO
• Descrivi le limitazioni e i problemi noti o previsti

Inoltre, assicurati di aver implementato l'attività in modo intelligente .

Vorrei andare per la lista delle cose da fare.

Questo dimostra che stai pensando oltre le specifiche iniziali e sei consapevole di ciò che i clienti potrebbero chiedere in futuro e non concentrarti solo su requisiti e problemi immediati.

Identificherò anche le aree del codice in cui hai avanzato ipotesi che potrebbero causare problemi in futuro se emergessero nuovi requisiti o aree (come la registrazione) utili ma non coperte dai requisiti dell'utente finale, o almeno non direttamente dai requisiti dell'utente finale.

Questi dovrebbero darti argomenti da discutere al prossimo colloquio.

Assolutamente no! Hai finito il tuo lavoro prima dell'orario previsto e non stai informando il tuo manager? Questo è totalmente irresponsabile! Potrebbe esserci un altro compito sul percorso critico del progetto che ti sta aspettando!

Quindi ... quello che voglio dire in modo scherzoso qui è: non aspettare fino all'ultimo momento. Controlla doppio e triplo se il tuo lavoro soddisfa i requisiti, ma non estendere l'ambito da solo.

E ricorda

“Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint-Exupery

Aggiungerei UnitTest per ogni classe.

Cerca di ottenere una copertura del codice del 100% per ogni metodo.

In circostanze simili, ho sempre incluso i test unitari. Apparentemente è abbastanza raro che in entrambe le volte che ho fatto test di codifica da portare a casa mi è stato detto che la loro inclusione mi ha fatto risaltare molto di più rispetto agli altri candidati. Non consiglierei di aggiungere funzionalità al di fuori dell'ambito, a meno che non facciano una grande differenza nell'esperienza utente E non sminuire la logica di base.

Gli unici commenti che ho aggiunto erano le spiegazioni di perché ho scelto una particolare implementazione rispetto ad altre alternative, che è essenzialmente il modo in cui commento nel codice di produzione. (Potrei spiegare i compromessi in termini di prestazioni, o che ho scelto la semplicità rispetto alla purezza / alle prestazioni non elaborate / ecc.)