Dovrei essere preoccupato per gli incarichi di programmazione overingegneria dati durante il processo di intervista? [chiuso]

Come intervistatore sarei felice di vedere la conoscenza del processo di sviluppo del software dimostrato da questo approccio; al contrario di solo la scrittura del codice.

In particolare, disporre di una suite di test per problemi anche molto semplici sarebbe un buon segno (anche livello FizzBuzz). Ho visto candidati presentare soluzioni che non hanno nemmeno risolto il problema e una semplice serie di test avrebbe mostrato loro questo. Inoltre, avere la cronologia dei commit mi permette di avere un'idea del processo di pensiero che il candidato ha usato per arrivare alla soluzione.

D'altra parte, ho conosciuto persone che sono state rifiutate da alcune aziende in una fase iniziale del processo di sovraingegneria. Tuttavia, nella maggior parte dei casi, ciò è dovuto alla sovraingegnerizzazione della soluzione, non necessariamente ai processi utilizzati.

Avendo intervistato qualcuno che capiva cose come controllo di versione, CI, test di unità e simili sarebbe un passo avanti su quello che vedo di solito.

Anche se, per me, la cosa più importante è che il problema è risolto e risolto bene, sapendo che il candidato ha compreso i modi per migliorare la qualità del suo risultato finale avrebbe sicuramente attirato la mia attenzione.

Quello che generalmente vedo sono persone che non solo non capivano il problema, ma anche chi non capiva come risolvere il problema - e venivano ignorati indipendentemente da quanti strumenti aggiuntivi usavano nel processo.

Ricorda che c'è un limite di tempo. L'intervistatore lo sa, quindi questo significa (se fossi l'intervistatore) che ti vedrà non solo risolto il problema entro il tempo prestabilito, ma lo ha così rapidamente hai avuto tempo per la doratura, che è un buon segno delle tue capacità di problem solving e del tuo apprezzamento per il rigore e la diligenza.

L'over-engineering è una parolaccia quando stai creando AbstractFactoryManagerAdaptors che viene collegato per distribuire BuzzManager e FizzManager solo per risolvere FizzBuzz.

Quello che stai facendo è eccessiva diligenza, che non è nemmeno una cosa (anche se la sotto-diligenza lo è sicuramente).

Detto questo, se finisci nel tempo o con una soluzione mezza compromessa perché hai usato il tuo tempo per gli extra che affermi "non aggiungere tempo", sembrerà che tu abbia una comprensione molto scarsa di come possono essere grandi compiti apparentemente piccoli. Questo può essere un attributo pericoloso in un ingegnere e fin troppo comune tra i giovani. Assegna la priorità in modo appropriato e fai le cose extra-credito solo dopo completando la richiesta soluzione.

Un'altra opinione da considerare è che il tuo approccio non è né buono né cattivo. Posso immaginare intervistatori che lo considerino troppo e posso immaginare intervistatori che amerebbero ancora più ingegneria.

Non ti preoccupare così tanto. Invece, risolvi il problema nel modo che ritieni migliore e probabilmente riceverai offerte di lavoro da persone che sono d'accordo con te. Questo è un primo grande passo verso un ambiente di lavoro produttivo. Ricorda, le interviste vanno in due modi. La risposta dell'intervistatore alla tua soluzione ti dirà molto su di loro. Vuoi veramente lavorare con persone che credono che i tuoi istinti di sviluppo e la filosofia siano sbagliati?

In realtà, a nessuno importa se il candidato può creare un repo git o creare makefile in fretta, perché questo è solo il richiamo di ciò che ha imparato a memoria. Queste sono abilità secondarie rispetto all'aspetto reale di problem solving e design della domanda dell'intervista.

Quindi sì, la tua intuizione è azzeccata sul fatto che potenzialmente sembra male, perché può sembrare che il candidato creda che qualcuno che può rigurgitare alcuni comandi e schemi memorizzati per creare uno scheletro di progetto abbia notevoli capacità software.

L'aspetto della suite di test della soluzione è comunque buono. Offrire una risposta con una suite di test di regressione probabilmente guadagnerà i tuoi punti. Tanto più che la tua suite di test esercita i casi salienti nel codice. La suite di test non deve avere molte trappole formali e fare affidamento sugli strumenti; solo il fatto che tu ne abbia in qualche modo uno è abbastanza buono per un colloquio. È più o meno ovvio che se riesci a mettere insieme alcuni test unitari ad hoc in un quiz di interviste, puoi farlo con strumenti su un vero progetto.

I recently had a phone interview with a company. After that phone interview, I was told to complete a short programming assignment (a small program; shouldn't take more than three hours).

Procederei con cautela. Valuta la pertinenza della sfida per il posto di lavoro e assicurati che il futuro rimborso da parte del datore di lavoro valuterà 3 ore del tuo tempo.

Metto in dubbio il valore di questi tipi di test e preferirei giudicare qualcuno sui risultati ottenuti in passato. Un breve compito predefinito non può dire al datore di lavoro nulla su ciò che puoi fare. Solo ciò che non puoi fare e che può essere determinato rapidamente con alcune domande al telefono.

Il test ha il suo posto. Porsi le seguenti domande sul test e rispondere di conseguenza.

1. La fiera del test è data dal tuo attuale livello di carriera?
2. Il test ha una risposta corretta chiaramente definita?
3. L'intervistatore è interessato al tuo potenziale come persona o mostra più interesse per i risultati del test (ad esempio le agenzie di assunzione sono terribili per questo).
4. Il test rappresenta il tipo di lavoro che ti piacerebbe fare o è una verifica ambigua delle competenze (cioè prova se conosci la sintassi Java).

I'm only directly instructed to complete the assignment and turn in the code.

Hai appena risposto alla tua domanda.

Immediately I planned on throwing it on Github, writing a test suite for it, using Travis-CI (free continuous integration for public Github repositories) to run the test suites, and using CMake to build the Linux makefiles for Travis-CI.

No, non è quello che ti hanno chiesto di fare.

That way, not only can I demonstrate that I understand how to use Git, CMake, Travis-CI, and how to write tests, but I can also simply link to the Travis-CI page so they can see the output of the tests. I figured that'd make it a tiny bit more convenient for the interviewer.

Sarei attento a dimostrare le competenze troppo presto o troppo tardi nel processo dell'intervista. Se senti che non hai fatto bene nell'intervista e stai cercando di compensare, allora non funzionerà. D'altra parte, fare troppo quando non è stato chiesto troppo dimostra troppo entusiasmo. Ciò potrebbe tradursi in una contrazione del datore di lavoro con un'offerta di salario inferiore che ti aspettavi.

However, I'm a bit worried that doing all this for a relatively simple task would look bad.

Sì, sembra brutto. Risolvere la sfida con una sola riga di codice sarà molto più impressionante di un progetto completamente svuotato.

Dalla mia esperienza non è così che vinci il colloquio di lavoro, ma è un modo per perdere il lavoro. Il test del codice è un problema di controllo della qualità. Ogni azienda che utilizza i test di codice durante l'assunzione di persone lo sta facendo, perché in precedenza non stavano usando i test di codice. Hanno avuto una brutta esperienza di qualcuno che scivolava attraverso le fessure del processo di intervista che non dovrebbe avere.

Prenderanno il codice sorgente e lo passeranno in ufficio. La gente ci commenterà e quello che non vorresti che dicessero è "Ha commesso questo errore, ma ha passato del tempo usando Git, CMake e Travis-CI. Che idiota per aver perso questo errore".

Questo è tutto. Hai perso.

Vogliono sapere che puoi programmare, perché non possono insegnartelo. Git, CMake e Travis-CI possono essere facilmente insegnati.

Penso che il tuo approccio non sia né buono né cattivo per sé . Vorrei chiedere all'intervistatore se va bene usare Github e gli altri strumenti. Come sottolineato da @Izkata nei commenti, stai rendendo pubblica la tua soluzione.

Come intervistatore, ho saputo che di solito non c'è nulla di male nel candidato che cerca di chiarire alcune cose. Inoltre, fare una o due domande può essere un buon segno, perché non affrettarti a fare cose che non hai capito.

Ricorda, tuttavia, che la cosa più importante è che il problema è risolto e risolto bene. A tale riguardo, tutti sono d'accordo sul fatto che una suite di test aiuti. Ma, per quello, forse hai solo bisogno di inviare un paio di classi di test insieme al tuo progetto / soluzione.