Come mi devo preparare per un'intervista con Microsoft?

Spero di avere qualche buona idea su questo argomento. Ho intervistato circa un anno fa per uno stage SDET su Bing e non sono andato molto bene nelle mie interviste. Era la prima volta che facevo colloqui importanti per il software, ed è stato un chiaro campanello d'allarme su ciò che dovevo fare se volevo davvero un lavoro del genere.

Ho finito per fare colloqui in una varietà di società di software nel corso dell'ultimo anno; alcuni sono andati bene, altri non così tanto. Alla fine ho intervistato di nuovo Microsoft lo scorso autunno per una posizione SDET a tempo pieno, e questa volta ho fatto abbastanza bene da ricevere (e accettare) un'offerta. Ecco cosa ho imparato:

1. Conoscere le strutture dati, in particolare le Linked List, le code, le pile, gli Heap, le mappe Hash e gli alberi (inclusi, ma non limitati a, BST, alberi AVL, ecc.). Vi si può chiedere qualsiasi cosa, dal semplice "Inseriamo in una Linked List?" all'astratto "Quale struttura dati risolve in modo più efficiente questo problema? Dovreste conoscere i tempi di esecuzione di base così su due piedi, ma concentratevi sul caso medio invece che sul caso migliore/peggiore.

2. Specificamente per i test, leggete i tipi di test eseguiti sui principali software oggi. Molto probabilmente vi verrà chiesto "Come testereste questa funzione/prodotto/servizio? Ci sono più modi per testarlo di quanto si possa pensare:

• Test funzionale - funziona?
• Edge cases - test dei limiti di un singolo parametro
• Corner cases - test limitato di più parametri
• Stress test - simulare molti utenti di un servizio
• Scale testing - come gestisce input di dimensioni assurde?
• Test interfunzionali - come impatta su altre parti del codice base?
• Test di accessibilità - l'usabilità è influenzata se l'utente è daltonico, sordo, ecc?
• Test geo-politici - ha ancora senso in altre aree con culture diverse? (Ho imparato questo durante le interviste)

3. Non iniziare, in nessun caso, a scrivere codice senza aver pianificato la tua soluzione, disegnato esempi, ecc. Ho scoperto che dopo aver lavorato attraverso la mia soluzione con l'intervistatore, avrebbero detto qualcosa del tipo: "Ok, suona bene. Vediamo un po' di codice". Questo è il vostro segnale che avete pianificato abbastanza bene per implementarlo effettivamente, ben fatto. Non dimenticate di rivedere una volta che pensate di aver finito (suggerimento: probabilmente avete dimenticato un caso limite o qualcosa del genere).

4. Se vi bloccate (la maggior parte delle persone lo fa ad un certo punto), non abbiate paura di camminare attraverso le cose con l'intervistatore. Digli come stai cercando di risolvere il problema, o forse che non vedi necessariamente una soluzione subito. Torna al tavolo da disegno se devi. Cercate di pensare al vostro intervistatore come a un collega che può aiutarvi ad arrivare alla soluzione, non a qualcuno che giudica solo la vostra performance in quel momento.

5. Conoscere i paradigmi di base come la programmazione dinamica, gli algoritmi greedy, ecc. può essere utile ma non sempre necessario. Invece, ho trovato che essere esposti a molti problemi e soluzioni diverse è un buon modo per fare esperienza pensando alle cose in modo diverso. Andate a cercare le domande del colloquio online, provate a pensare come lo risolvereste e vedete qual è la soluzione effettiva. Questo non si applica ai problemi in cui la soluzione è semplicemente un algoritmo popolare.