Storing 5000 elements on client side in a web application [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

I just had a phone interview for ASP.Net developer, after initial introductory stuff the interviewer ask me first technical question:

"How would you store 5000 elements on client side for each user in a web application".

My answer started with,

What is the average size of each element ? Do we really have to store this much data on client side ? Can't we keep that in the database and link this to user session/client ID somehow.

His reply was "No, You tell me how would you store it on the client side, considering that each element is a record with around 8 fields including int/string, a normal table row".

I said, "May be keep them in a session, but since sessions are maintained on server side for each user, It could become expensive, or the other option is to store that much data in cookie", I also said that I am not sure if that much data could be stored in cookie. I mentioned HTML5 Storage options is there, but I haven't worked with it. Since it is based on SQLite, it could store that much data theoretically.

That's where the interviewer somewhat sarcastically said, so you have 3 years of experience in web development, and terminated the interview.

I am wondering, what I did wrong? or is there something really basic that I am missing with respect to storing data on client side.

Answer 1

I agree with the comments that he was likely looking for HTML5 local storage, and may have expected you to have experience with it.

Frankly, unless it was an integral requirement of the job and you stated you had experience with it, his expectation and reaction were unreasonable, in my opinion, for anyone with any amount of experience.

Why?

Because, three years ago, HTML5 as a spec was still in its infancy. In other words, for you, specifically, your career is about as long as the history of the spec itself. It's not uncommon to see jobs looking for people with more experience with a product than the product has been around. It's rare to see the same happen for an entire specification. For that, I applaud you for finding such a gem.

More seriously, though, it sounds like the issue lies more with your interviewer asking you an overly vague question, and judging you too harshly on it. It's not uncommon for interviewers to ask vague questions, especially in the development arena. Usually, this is done to try to gauge how you think, and where your first instinct leads you. For that, you did well by questioning the need to store that kind of data locally. These questions are not, in and of themselves, bad, but what the interviewer does with them can lead to a bad outcome for you (arguably, such interview termination means you probably don't want to work for that company, anyway).

Now, it's possible that the company's business needs required they use local storage for one reason or another. If that's the case, it should have been spelled out in the job description, and you should have been ruled out as a potentially viable candidate when your resume reflected no such experience if they felt they couldn't or shouldn't train or otherwise provide the new employee with the time/means to come up to speed on the technology.

As for local storage, itself -- as I mentioned previously, HTML5 as a spec has only been around for about three years, and that's being generous and counting the "last call" drafts. Then, you have the issue of browser support, which may or may not have a long history (for example, while name-value pairs have been widely supported even prior to HTML5 solidification, IndexedDB and Web SQL DB are still sketchy).

Finally, the usage for HTML5 local storage is less common still. In my years as a web developer, I've come across an app that I know utilized it all of once (there may be some that use it invisibly, but that's harder to quantify), and maybe half a dozen projects that may be able to make use of it (but didn't really need them at that time, or the cost of using that approach vs another wasn't justified).

In a more general sense, failed interviews happen. Software development is far too big a field to be able to know all the little details about every single thing (in this case, the storage limits of HTML5 local storage), and being honest about not knowing a given thing is, in my opinion, still the best route (I personally have more respect for someone who acknowledges their gaps in knowledge and seeks to fill them, than for someone who tries to cover up the fact that they don't know something). With that in mind, I'd say you handled the question well, given the information you've given here. If there was something you did wrong, it may have been in the details of how you responded, which we can't help you with, here, because we weren't at the interview to assess the non-lingual aspects of your responses.

Answer 2

The 'correct' answer - at least, the one they were looking for - was indeed HTML5 LocalStorage (an excellent link by Steven Burnap). And the interviewer was probably being...well, I believe the technical phrase is "a bit of a knob".

This is basically arrived at by process of elimination, in that a cookie cannot be anywhere near big enough, sessions are indeed server-side and not a client-side storage mechanic at all, etc. The interviewer presumably thought this was common knowledge and you should know it, which is funny in that you only need HTML5 LocalStorage capabilities typically in data-heavy UI work which is the exception rather than the rule. A person could program for many years and not have need for the feature, while others might have a need for it on their first project.

However, I would generally say in cases like this it's less a question of your answer and rather a question of how you answered it and the process you used to get there. From your description you did OK, but I wasn't there and so their impression might be very different.

Most sensible interviewers won't declare one small facet of technology a litmus test where every person must answer it great...however, I've had a lot of interviews with people who aren't sensible interviewers. Knowing such trivia can be a boon when you run into such individuals.

Finally, I would note that by declaring the interview over in rather a not-very-nice way, it is highly likely that the person was already annoyed and had decided about you already (your answer to this specific question might not have mattered in the slightest). They were just waiting for a moment for you to trip up so they could point at it and not expose the fact that they'd decided in the first 30-seconds or so if you were a viable candidate or not.

I'd perhaps practice how to answer questions you don't immediately know the "right" answer to, as the ability to be wrong gracefully and seem knowledgable and intelligent anyway is a darn handy skill - and we all could benefit from the extra practice. Brush up on some "what's new in [latest version of important technology]" articles and then get back out there!