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


12

Ho appena avuto un colloquio telefonico per lo sviluppatore ASP.Net, dopo le cose introduttive iniziali l'intervistatore mi ha posto la prima domanda tecnica:

"Come archivieresti 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 così tanti dati sul lato client? Non possiamo tenerlo nel database e collegarlo in qualche modo all'ID sessione / ID utente .

La sua risposta fu "No, dimmi come lo memorizzeresti sul lato client, considerando che ogni elemento è un record con circa 8 campi tra cui int / string, una normale riga di tabella".

Ho detto: "Potrebbero essere conservarli in una sessione, ma poiché le sessioni sono gestite sul lato server per ciascun utente, potrebbe diventare costoso, o l'altra opzione è quella di memorizzare molti dati nei cookie", ho anche detto che non lo sono certo se molti dati potrebbero essere memorizzati nei cookie. Ho citato le opzioni di archiviazione HTML5 che ci sono, ma non ci ho lavorato. Dal momento che si basa su SQLite, potrebbe memorizzare molti dati teoricamente .

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

Mi chiedo, cosa ho fatto di sbagliato? o c'è qualcosa di veramente fondamentale che mi manca rispetto alla memorizzazione dei dati sul lato client.


14
Immagino che stesse cercando l'archiviazione locale html5 , anche se sembra che tu l'abbia menzionato. Può darsi che l'intervistatore fosse un coglione e / o ti abbia frainteso.
Gort il robot il

1
È stata data una definizione per quello che dovrebbe essere un "elemento"? Non credo che tu abbia fatto qualcosa di sbagliato, la domanda è particolarmente vaga.
GrandmasterB,

8
Non so perché avrebbe usato il termine "elemento" per descriverlo. Ma sì, sembra che fosse dopo l'archiviazione HTML. Penso che anche il tuo primo istinto di "perché" vuoi archiviare quel lato client è stato buono.
GrandmasterB,

5
L'intervistatore potrebbe averti cercato di pronunciare letteralmente le parole "archiviazione locale". Alcune persone sono davvero così ritentive anali. Non vorrai lavorare per loro comunque. Hai schivato un proiettile.
Greg Burghardt,

2
"che cosa ho fatto di sbagliato?" dal suo commento e atteggiamento, applicando a questa azienda: è qui che l'intervistatore ha detto in qualche modo sarcasticamente, quindi hai 3 anni di esperienza nello sviluppo web e hai terminato l'intervista
Francisco Presencia,

Risposte:


10

Concordo con i commenti sul fatto che probabilmente stava cercando l'archiviazione locale HTML5 e che probabilmente si sarebbe aspettato che tu ne avessi esperienza.

Francamente, a meno che non fosse un requisito integrale del lavoro e tu abbia dichiarato di avere esperienza con esso, la sua aspettativa e reazione erano irragionevoli, secondo me, per chiunque avesse qualsiasi 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 con un prodotto di quanto lo sia stato in giro. È raro vedere lo stesso accadere per un'intera specifica. Per questo, ti applaudo per aver trovato una gemma del genere.

Più seriamente, però, sembra che il problema risieda più nel fatto che il tuo intervistatore ti pone una domanda troppo vaga e ti giudica troppo severamente al riguardo. Non è raro che gli intervistatori facciano domande vaghe, specialmente nell'arena dello sviluppo. Di solito, questo viene fatto per cercare di valutare come pensi e dove ti porta il tuo primo istinto. Per questo, hai fatto bene mettendo in dubbio la necessità di archiviare quel tipo di dati localmente. 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 del colloquio significa che probabilmente non vuoi lavorare per quella società, comunque).

Ora, è possibile che le esigenze aziendali dell'azienda richiedano l'uso dello storage locale per un motivo o per l'altro. In tal caso, avrebbe dovuto essere indicato nella descrizione del lavoro e avresti dovuto essere escluso come candidato potenzialmente praticabile quando il tuo curriculum non rifletteva tale esperienza se sentivano che non potevano o non dovevano allenarsi o altrimenti fornire il nuovo dipendente con il tempo / i mezzi per arrivare al passo con la tecnologia.

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

Infine, l'utilizzo per l'archiviazione locale HTML5 è ancora meno comune. Nei miei anni come sviluppatore web, mi sono imbattuto in un'app che conosco l'ho utilizzata tutta una volta (potrebbero essercene alcuni che la usano invisibilmente, ma è più difficile da quantificare) e forse una mezza dozzina di progetti che potrebbero essere in grado per usarlo (ma non ne aveva davvero bisogno in quel momento, o il costo dell'uso di quell'approccio contro un altro non era giustificato).

In senso più generale, si verificano interviste fallite. Lo sviluppo del software è di gran lunga campo troppo grande per essere in grado di conoscere tutti i piccoli dettagli su ogni singola cosa (in questo caso, i limiti di HTML5 storage locale di stoccaggio), ed essere onesti di non sapere una data cosa è, a mio parere, è ancora il percorso migliore (personalmente ho più rispetto per qualcuno che riconosce le proprie lacune nella conoscenza e cerca di colmarlo, piuttosto che per qualcuno che cerca di nascondere il fatto di non sapere qualcosa). Con questo in mente, direi che hai gestito bene la domanda, date le informazioni che hai fornito qui. Se ci fosse qualcosa tu fatto male, potrebbe essere stato nei dettagli di come hai risposto, di cui non possiamo aiutarti, qui, perché non eravamo presenti al colloquio per valutare gli aspetti non linguistici delle tue risposte.


7

La risposta "corretta" - almeno quella che stavano cercando - era effettivamente HTML5 LocalStorage (un eccellente collegamento di Steven Burnap). E probabilmente l'intervistatore sarebbe stato ... beh, credo che la frase tecnica sia "un po 'un pugno ".

Questo è sostanzialmente raggiunto dal processo di eliminazione, in quanto un cookie non può essere abbastanza vicino abbastanza grande , le sessioni sono in effetti lato server e non sono affatto un meccanico di archiviazione lato client, ecc. L'intervistatore ha presumibilmente pensato che fosse una conoscenza comune e tu dovresti saperlo, il che è divertente in quanto hai solo bisogno delle funzionalità HTML5 LocalStorage in genere nel lavoro dell'interfaccia utente pesante di dati che è l'eccezione piuttosto che la regola. Una persona potrebbe programmare per molti anni e non avere bisogno della funzione, mentre altri potrebbero averne bisogno nel loro primo progetto.

Tuttavia, direi che in casi come questo è meno una domanda della 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ù sensati non dichiareranno un piccolo aspetto della tecnologia una cartina di tornasole in cui ogni persona deve rispondere alla grande ... tuttavia, ho avuto molte interviste con persone che non sono intervistatori sensibili. Conoscere tali curiosità può essere un vantaggio quando ti imbatti in tali individui.

Infine, noterò che dichiarando l'intervista piuttosto in un modo non molto piacevole, è molto probabile che la persona fosse già infastidita e avesse già deciso su di te (la tua risposta a questa domanda specifica potrebbe non avere importanza nel minimo). Stavano solo aspettando un momento per farti inciampare in modo che potessero indicarlo e non esporre il fatto che avevano deciso nei primi 30 secondi circa se eri un candidato praticabile o meno.

Forse mi eserciterei a rispondere a domande a cui non conosci immediatamente la risposta "giusta", poiché la capacità di sbagliare con garbo e sembrare comunque comprensibile e intelligente è un'abilità davvero utile - e tutti potremmo beneficiare della pratica extra . Ripassare alcuni articoli "Novità in [ultima versione di tecnologia importante]" e poi tornare indietro!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.