Avendo attraversato il processo di ricerca di lavoro per diversi mesi, posso darti la mia prospettiva sul processo di ricerca di lavoro in relazione a me. In primo luogo, alcuni non fare; queste sono tutte cose che molti datori di lavoro stanno facendo in questo momento e non dovrebbero farle:
Non chiedere alle persone di elaborare domande su cose che non useranno mai sul lavoro.
Non sto parlando di FizzBuzz. FizzBuzz esiste per eliminare le persone che non possono programmare affatto. Sto parlando di chiedere alle persone di progettare e implementare un albero binario, quando quel problema è già stato risolto decenni fa. Invece, chiedi informazioni sulla complessità (Big O) e forse su come usare la ricorsione per camminare su un albero binario.
Non chiedere alle persone di scrivere codice perfetto.
Non lo otterrai in un'intervista di codifica, soprattutto se è tramite skype o per telefono. La maggior parte delle persone usa gli IDE al giorno d'oggi e li ha derubati di quello strumento. Se parte del tuo set di competenze lavorative richiede che le persone eseguano il codice nel Blocco note, quindi con tutti i mezzi. Dubito che sia vero, però.
Non chiedere alle persone di viaggiare in tutto il paese per un impegno di sei mesi.
Questa è solo una variazione su "l'intervista che non finisce mai". Scopri come trovare persone di talento da intervistare nel primo o secondo contatto da intervistare, quindi rendi l'intervista pertinente al tuo lavoro.
Smetti di seguire la mandria!
Alcune delle cose che stai facendo nelle tue interviste si stanno facendo perché Google le fa, o Facebook le fa. Il tuo miglior processo di assunzione non è necessariamente la codifica di concorsi tra scatti di whisky (se la tradizione è vera). Il tuo miglior processo di assunzione è quello che meglio si adatta alla tua società, non all'ultima moda di Google o Facebook.
Infine, non chiedere alle persone cose che non conosci già da solo.
Se chiedi a qualcuno di migliorare le prestazioni di un algoritmo di inversione delle stringhe quando lo hanno già scritto nel modo ottimale, stai solo perdendo il tempo di tutti.
Ora che è fuori mano ...
For example, in a Java snippet I would use == instead of .equals(), duplicate some code...
Questo sembra un approccio ragionevole.
Mi aspetto che ogni sviluppatore esperto conosca già alcune cose sulla loro lingua di scelta. Mi aspetterei un programmatore C # ragionevolmente competente per sapere come == differisce da equals() , perché le stringhe sono un'eccezione, cos'è IDisposable e come si riferisce a using , ecc. Preferirei personalmente le abilità di crack nelle loro lingua preferita sul tuo preferito lavello della cucina dei gusti tecnologici desiderati della settimana, dal momento che qualcuno con eccellenti capacità di codifica può facilmente raccoglierli.
I found that this question gave me insight into several things. First, it was a red flag if a developer could not point out obvious issues with the code. Second, even if a developer could not find all the issues, I could point it out and they can say 'ah yeah' and talk about it in a meaningful way. It also allowed me hear them dig as deep as they wanted on certain things.
Tutto vero.
I personally find it intimidating to write code during an interview. I also find it strange when potential employees give you a 'homework' to complete at home and hand in before the actual interview. But then how else are you supposed to evaluate their programming potential?
Nel momento in cui concedi a qualcuno un'intervista, dovresti già avere una buona idea se li assumerai o meno. Quando ho intervistato per il lavoro che ho ora, non mi hanno nemmeno fatto domande tecniche. La persona che mi ha intervistato ha passato la maggior parte del suo tempo a vendermi sulla sua compagnia. Ha detto "So già che puoi fare il lavoro, fatte salve le tue referenze confermando che hai fatto le cose che dici di aver fatto nel tuo curriculum."