Su cosa concentrarsi nello sviluppo di una demo del gioco per un'intervista?

In altri thread su questo stesso sito Web, è stato più volte sottolineato che avere una demo del gioco da mostrare in un'intervista di lavoro è di fondamentale importanza, quindi ho deciso di provare e scrivere la mia demo del gioco.

Vorrei sapere su cosa è tipico per gli intervistatori focalizzare la loro attenzione durante la revisione della demo del gioco .

Chiarirò che non ho un'apertura specifica disponibile per me in questo momento, ma che probabilmente avrei preso di mira posizioni di gioco e / o programmazione AI . Per questo motivo posso rispondere da solo in termini di ampie categorie: la "grafica elaborata" non dovrebbe essere il mio obiettivo prioritario mentre il "comportamento dei giocatori di computer" dovrebbe ... Eppure - non avendo esperienza diretta in questo settore - vorrei sapere se ci sono cose meno ovvie dovrei prestare attenzione a:

• Quanto è importante la modularità del codice?
• Quanto è importante mostrare una tipica implementazione dell'algoritmo?
• Quanto è importante includere nuove funzionalità?
• Quanto è importante la giocabilità?
• Devo privilegiare la leggibilità o l'ottimizzazione del codice?
• Quanto è importante la documentazione del codice?
• eccetera...

Ricorda che quanto sopra è solo un esempio per illustrare il livello di dettaglio che apprezzerei nella risposta, non sono domande specifiche che vorrei necessariamente essere affrontate (a meno che tu non pensi che sia pertinente discuterne alcune).

Grazie in anticipo per il tuo tempo e competenza.

Non scrivere una demo per un'intervista se puoi evitarla; inviare codice o progetti esistenti, se possibile.

Demo ed esempi di codice sono importanti per molte ragioni (che variano a seconda del revisore), ma principalmente si tratta di mostrare ai potenziali datori di lavoro il tipo di codice che scrivi in ​​natura e il tipo di problemi che ti interessano risolvere. Aiutano anche a dimostrare il tuo livello di interesse nell'arte dello sviluppo del software.

È molto meglio inviare un codice che hai già scritto per un progetto o un gioco precedente di cui sei orgoglioso o che dimostra una soluzione intelligente a un problema: tutto ciò che è interessante o difficile o che può servire come la base per una buona discussione.

La scrittura esplicita del codice da inviare come codice di esempio tende a risultare falsa e inventata; può essere sorprendentemente facile dire, ad esempio, che un programmatore ha pensato che un potenziale datore di lavoro avrebbe voluto vedere un codice "ben documentato" e quindi inserire commenti molto dettagliati su tutto, cercando di ottenere ciò che credono essere la perfezione. Il vero codice non è perfetto, ha verruche e bordi grezzi, e quando scrivi esplicitamente il codice per l'invio della demo tendi a lucidarlo così tanto che diventa ovvio che non lo hai scritto perché ti è piaciuto scriverlo. Volevi solo un lavoro.

Detto questo, se non hai alcun lavoro che puoi inviare - o perché non ne hai ancora scritto uno o perché il tuo lavoro precedente ti impedisce di inviare qualsiasi codice (sotto NDA) - non hai un molte opzioni ma per scrivere qualcosa di nuovo. In quello scenario, ti incoraggio a concentrarti sullo scrivere la cosa per se stessa , e dimenticare ciò che "i datori di lavoro" vogliono ". Scrivi una partita perché vuoi scrivere una partita. Scrivi una bella demo tecnologica perché vuoi esplorare quella tecnologia, perché è quello che ti interessa.

• Quanto è importante la modularità del codice?
• Quanto è importante mostrare una tipica implementazione dell'algoritmo?
• Quanto è importante includere nuove funzionalità?
• Quanto è importante la giocabilità?
• Devo privilegiare la leggibilità o l'ottimizzazione del codice?
• Quanto è importante la documentazione del codice?

Le risposte a tutte queste domande più piccole sono, purtroppo, "dipende" (ad eccezione della leggibilità - penso che dovresti favorire la leggibilità in generale, specialmente per il "codice demo"). Alcuni datori di lavoro potrebbero voler vederti reimplementare quicksort. Ad altri potrebbe non interessare. Altri ti chiederanno comunque di reimplementare quicksort su una lavagna durante l'intervista.

Non concentrarti su ciò che pensi che i datori di lavoro desiderino , perché diversi datori di lavoro e persino persone diverse che potrebbero rivedere il tuo codice vorranno cose diverse. Concentrati invece su ciò che vuoi mostrare su te stesso , perché hai un controllo molto maggiore su quello e ti trarrà più beneficio a lungo termine.