Tutto ok.
Ben tornato.
Questo sarà un video di 30 secondi.
Volevo solo riassumere i passaggi.
Quindi, per ricapitolare il protocollo in cinque passaggi qui, se ti trovi di fronte a una dura sfida per le
interviste e sei a un tavolo bianco, c'è un sacco di persone che ti guardano o stai
cercando di risolvere qualcosa per conto tuo un romanzo.
Non so sfidarti.
Stai cercando di costruire cercando di capire come ordinare i risultati della ricerca qualunque essa sia.
Questi sono i passi che mi piace attraversare.
Assicurati di aver compreso il problema e di farlo nel modo in cui l'ho insegnato o di averlo discusso in merito
alle interviste, come ho detto in particolare su come capire il problema.
Quindi fai domande al tuo intervistatore, ovviamente chiarisci il problema assicurati di capirlo.
Ma anche se lavori solo su qualcosa.
Assicurati di comprenderlo per assicurarti di aver davvero pensato a come la tua soluzione come dovrebbe
funzionare la tua applicazione come dovrebbe comportarsi in ogni scenario e che va di pari passo con l'esplorazione
di esempi concreti.
Questi due sono in realtà entrambi relativi alla comprensione del problema, alla comprensione degli input, alla comprensione degli
output, alla comprensione dei casi limite, alla gestione degli errori, a ciò che accade quando un utente inserisce qualcosa
di non valido.
Tutte queste diverse cose hanno a che fare solo con una sorta di comprensione fin
dall'inizio di come tutto dovrebbe funzionare sin dall'inizio.
Non lo so rompere.
Quindi, a questo punto, se ti piace scrivere come uno pseudo codice totalmente perfetto per linea puoi farlo
o semplicemente aprire un paio di passaggi per definire un piano di gioco per il codice che devi implementare.
Questo è molto utile specialmente in un colloquio alcune volte e sai che stai per
perdere tempo.
Può essere utile scrivere il tuo piano di gioco in modo da poterli mostrare. Ehi, questo è dove stavo andando
anche se ho solo implementato il 40% di questo.
Ecco gli altri passaggi che stavo per fare.
Quindi assicurati di sapere dove stai andando prima di iniziare a digitare il codice.
Spesso è un brutto modo.
Puoi finire in un buco.
Puoi confonderti che mi è successo molte volte nelle interviste se inizi a pensare di sapere da
dove cominciare e vedrai il resto mentre vai.
Spesso incaselli tu stesso in un unico approccio e poi comincio a prendere dal panico
perché non sta funzionando e faccio un passo indietro e di solito cancella tutto ciò che ho fatto e ricomincio e
pianificato.
Allora risolvi.
E se non puoi risolvere il problema subito risolvi un problema che puoi.
Anche se è più semplice se si semplifica, si rimuove alcune difficoltà di nucleo di difficoltà principale e si tenta di risolvere qualcosa
in cui è possibile quindi reintegrare nuovamente la difficoltà principale.
Quindi abbiamo parlato di due video fa se non sei sicuro di come testare che
qualcosa di alfanumerico ignori quella parte e scrivi il problema scrivendo la soluzione ignorando la parte alfanumerica in modo
da poterla poi collegare in seguito.
E poi finalmente quello che ho detto è stato il più importante per imparare o migliorare come sviluppatore.
Guardando indietro al tuo codice e qualche volta refactoring a volte solo guardando indietro e analizzando e
dando pacche sulla schiena.
La maggior parte delle volte c'è spazio per il refactoring anche se sei uno sviluppatore totalmente esperto.
Può essere molto utile guardare le soluzioni di altre persone o scrutare il tuo e capire
cosa avresti potuto fare meglio.
Tutto ok.
Quindi questi sono i passaggi che consiglio se ti trovi di fronte a una sfida difficile,
soprattutto se sei un'intervista in un'intervista.
Consiglio assolutamente di iniziare sempre con la comprensione del problema.
Esplorando gli esempi uno su due di sicuro.
Fallo fuori di testa.
Assicurati che l'intervistatore ti senta parlare di ciò che stai facendo.
Abbattendolo.
Scrivi i passaggi verso il basso.
Parla ad alta voce.
Risolvilo ovviamente.
Se puoi, guarda indietro sul tuo codice e refactoring se puoi.
Tutti questi onestamente sono ugualmente importanti.
In un'intervista ambientata così come nella vita reale, ma penso che la maggior parte di voi si preoccupi delle interviste per
la maggior parte.
Quindi mi sto orientando verso quello.
OK, quindi questa è la parte più sdolcinata della risoluzione dei problemi, un po 'l'approccio che puoi
prendere mentalmente per prepararti.
Quindi parleremo di alcuni pattern per il codice.
Ci sono un paio di modelli di archetipi per soluzioni che potrebbero rivelarsi utili.
Onestamente penso che questa roba sia molto più utile nel mondo reale perché questo si applica a tutti i tipi
di problemi.
Bene, impareremo dopo.
È un po 'più specifico, ma per i tipi di problemi che aiuta aiuta davvero.
OK.
Questo è il prossimo.