Memorizzazione di 5000 elementi sul lato client in un'applicazione Web [chiusa]

12

Ho appena avuto un'intervista telefonica per lo sviluppatore ASP.Net, dopo le prime domande introduttive l'intervistatore mi ha fatto una prima domanda tecnica:

"Come memorizzeresti 5000 elementi sul lato client per ciascun utente in un'applicazione web".

La mia risposta è iniziata con,

Qual è la dimensione media di ciascun elemento? Dobbiamo davvero archiviare molti dati sul lato client? Non possiamo tenerlo nel database e collegarlo alla sessione utente / ID client in qualche modo .

La sua risposta è stata "No, dimmi come lo memorizzerai dal lato client, considerando che ogni elemento è un record con circa 8 campi inclusi int / string, una normale riga della tabella".

Ho detto, "Potremmo tenerli in una sessione, ma dal momento che le sessioni vengono mantenute dal lato server per ciascun utente, potrebbe diventare costoso, o l'altra opzione è quella di memorizzare tanti dati in cookie", ho anche detto che Non sono sicuro che molti dati possano essere memorizzati nei cookie. Ho menzionato le opzioni di archiviazione HTML5, ma non ci ho lavorato. Poiché è basato su SQLite, potrebbe memorizzare molti dati teoricamente .

È qui che l'intervistatore in qualche modo sarcasticamente ha detto, quindi hai 3 anni di esperienza nello sviluppo web e hai interrotto l'intervista.

Mi chiedo, cosa ho sbagliato? o c'è qualcosa di veramente fondamentale che mi manca per quanto riguarda la memorizzazione dei dati sul lato client.

    
posta CriketerOnSO 15.12.2014 - 19:51
fonte

2 risposte

10

Sono d'accordo con i commenti sul fatto che probabilmente stava cercando l'archiviazione locale HTML5 e probabilmente si aspettava che tu avessi esperienza con esso.

Francamente, a meno che non fosse un requisito integrale del lavoro e hai affermato che avevi esperienza con esso, le sue aspettative e reazioni erano irragionevoli, secondo me, per chiunque avesse una certa esperienza.

Perché?

Perché, tre anni fa, HTML5 come specifica era ancora agli inizi. In altre parole, per te, in particolare, la tua carriera è lunga quanto la storia delle specifiche stesse. Non è raro vedere lavori in cerca di persone con più esperienza di un prodotto rispetto al prodotto che è stato in giro. È raro vedere lo stesso accadere per un'intera specifica. Per questo, ti applaudo per aver trovato un tale gioiello.

Più seriamente, però, sembra che il problema risieda maggiormente nel fatto che il tuo intervistatore ti sta ponendo una domanda troppo vaga e ti giudica troppo duramente. Non è insolito per gli intervistatori porre domande vaghe, soprattutto nell'arena dello sviluppo. Di solito, questo è fatto per cercare di valutare come pensi, e dove il tuo primo istinto ti guida. Per questo, hai fatto bene a mettere in discussione la necessità di archiviare localmente quel tipo di dati. Queste domande non sono, di per sé, cattive, ma ciò che l'intervistatore fa con loro può portare a un risultato negativo per te (probabilmente, tale interruzione dell'intervista significa che probabilmente non vuoi lavorare per quella società, comunque).

Ora, è possibile che le esigenze aziendali dell'azienda richiedano l'utilizzo della memorizzazione locale per un motivo o per l'altro. Se questo è il caso, avrebbe dovuto essere spiegato nella descrizione del lavoro, e avresti dovuto essere escluso come candidato potenzialmente vitale quando il tuo curriculum non rifletteva tale esperienza se sentivano che non potevano o non dovevano allenarsi o fornire altrimenti il nuovo dipendente con il tempo / i mezzi per venire a conoscenza della tecnologia.

Per quanto riguarda l'archiviazione locale, come già detto, HTML5 come una specifica è in circolazione da circa tre anni, e questo è generoso e contando le bozze di "ultima chiamata". Quindi, hai il problema del supporto del browser, che può avere o meno una lunga storia (ad esempio, mentre coppie nome-valore sono stati ampiamente supportati anche prima della solidificazione HTML5, IndexedDB e Web SQL DB sono ancora imprecisi ).

Infine, l'utilizzo dell'archiviazione locale HTML5 è ancora meno comune. Nei miei anni come sviluppatore web, mi sono imbattuto in un'app che so utilizzata da un po '(potrebbero essercene alcuni che la usano in modo invisibile, ma è più difficile da quantificare) e forse una mezza dozzina di progetti che potrebbe essere in grado di farne uso (ma in realtà non ci hanno bisogno in quel momento, o il costo di usare quell'approccio contro un altro non era giustificato).

In un senso più generale, si verificano interviste fallite. Lo sviluppo del software è lontano un campo troppo grande per poter conoscere tutti i piccoli dettagli su ogni singola cosa (in questo caso, i limiti di archiviazione della memoria locale HTML5) ed essere onesti nel non conoscere un dato la cosa è, secondo me, ancora la strada migliore (personalmente ho più rispetto per qualcuno che riconosce le loro lacune nella conoscenza e cerca di riempirle, piuttosto che qualcuno che cerca di coprire il fatto che non sanno qualcosa). Con questo in mente, direi che hai gestito bene la domanda, date le informazioni che hai fornito qui. Se c'era qualcosa che tu hai sbagliato, potrebbe essere stato nei dettagli di come hai risposto, che non possiamo aiutarti, qui, perché non eravamo al colloquio per valutare il non - aspetti marginali delle tue risposte.

    
risposta data 15.12.2014 - 20:57
fonte
7

La risposta "corretta" - almeno, quella che stavano cercando - era in effetti HTML5 LocalStorage (un link eccellente di Steven Burnap). E l'intervistatore probabilmente stava ... beh, credo che la frase tecnica sia "un po 'di manopola ".

Questo è fondamentalmente arrivato per processo di eliminazione, in quel un cookie non può essere abbastanza vicino abbastanza grande , le sessioni sono effettivamente lato server e non un meccanismo di archiviazione lato client affatto, ecc. L'intervistatore presumibilmente pensava che fosse una conoscenza comune e dovresti saperlo , il che è divertente in quanto occorrono solo capacità HTML5 LocalStorage tipicamente nel lavoro dell'interfaccia utente pesante, che è l'eccezione piuttosto che la regola. Una persona potrebbe programmare per molti anni e non averne bisogno, mentre altri potrebbero averne bisogno nel loro primo progetto.

Tuttavia, direi che in casi come questo è meno una domanda sulla tua risposta e piuttosto una domanda su come hai risposto e sul processo che hai usato per arrivarci. Dalla tua descrizione hai fatto bene, ma io non ero lì e quindi la loro impressione potrebbe essere molto diversa.

Gli intervistatori più sensibili non dichiareranno un piccolo aspetto della tecnologia come una cartina di tornasole in cui ogni persona deve rispondere alla perfezione ... tuttavia, ho avuto molte interviste con persone che non sono intervistatori sensibili. Conoscere tali trivia può essere un vantaggio quando vi imbattete in tali individui.

Infine, noterò che dichiarando l'intervista in modo piuttosto non molto carino, è molto probabile che la persona fosse già annoiata e che avesse già deciso su di te (la tua risposta a questa domanda specifica potrebbe non avere importato nel minimo). Stavano solo aspettando un momento per farti inciampare in modo che potessero indicarlo e non mostrare il fatto che avevano deciso nei primi 30 secondi o giù di lì se tu fossi un candidato valido o meno.

Potrei forse esercitarti su come rispondere a domande a cui non sai immediatamente la risposta "giusta", poiché l'abilità di sbagliare con grazia e sembrare ben informato e intelligente è comunque una destrezza pratica - e tutti noi possiamo trarre vantaggio da la pratica extra. Rispolvera gli articoli "novità in [ultima versione di tecnologia importante]" e poi torna indietro!

    
risposta data 15.12.2014 - 20:45
fonte

Leggi altre domande sui tag