As long as you grow up in your career, you move on top of the level that you asked to implement common data structures such as linked list, stack and queue. I have graduated in 2001 where the most common libraries were C++ STL and VC++ MFC. Lots of time I have been interviewed and asked to design and implement queue, stack and list containers.
In 2002, I started to use .NET framework version 1.0 where such data structures were part of the class libraries.
Now after 15 years, I still find people ask the same questions of implementing data structures while the type of development inside the company does not require this. I prefer to ask questions that appropriate to the nature of work. I take another approach when I interview candidate. I ask him about utilizing the built-in containers such as List, Queue and HashTable. For example, I give him the below code:
var hashTble = new HashTable();
var diction = new Dictionary<int, string>();
Both are data containers. My questions to the candidate would be:
1- The main difference in terms of internal implementation.
2- The best scenario for each one.
3- Performance in terms of time and space.
4- If I would like to override each one Add method, what I need to do (code).
5- Iterations over each one elements.
In my opinion, through this way I can figure out If the candidate understands such fundamentals very well or not. I always believe that we have to consider the work requirements when we perform interviews. I met lots of interviewers ask complicated questions only to make shows while questions are not related to work nature at all.
Top comments (1)
While I generally agree with this concept, I think it's easy to stray into turning an interview into a language trivia quiz. The .NET Framework is vast and it's relatively easy to find an area where a candidate might not have an immediate answer.
For example, I don't think I've ever used HashTable in an application. While I've heard of it, I couldn't answer specifics about it without looking it up. Since I've been working mostly in MVC and Web API the past few years, I probably wouldn't remember all of the details of WebForms and WCF stuff.