What's the point of those technique detailed interview question for Senior dev? [closed]

Question

I've had an internal promotion interview for gain a higher level programmer title, something like Senior plus. And I've been interviewed by around 7 people using different technology, and people using the same technology with me(.Net) tend to ask very technique detailed question which can actually easily been found via Google, like what is JIT, how GC works, difference between List and Array, abstract class and interface, delegate and event, even what is the class name when you process Upload file, etc. And I've got only one question asked about one of my design idea in my project and just simple discussion. But for most other my design choice they seems just not interested.

I didn't get the result yet and it would be about late this week, but here is my concern:

I personally think when I play as a senior programmer, I mainly solving problems, and I just need to know there are some certain way can make it happen but I may not remember every detailed thing, and that's should be why we have those detailed reference documentation like MSDN.

I feel it fine if you found I've not too much experiences around this area like Junior to Intermediate level, but when tend to interview higher level guy, isn't you should more focus to see how this guy logical thinking is and how good is he/she at solving problems? Does everybody just think if you know every detailed small point tech stuff then you are a Senior+. And by checking those interview question books I found there are more those kind of questions.

If I spend 5 days go through those interview question list book I can easily make those guys feel a wow, but does that really mean anything? This kind of interview can easily let those guys good at remember things gain higher salary even they have no idea how to solve difficulty problem.

So why is this happening on the world, is that just cause problem solving skills, design skills are hard to measure? I've serve this company for years and only had few interview with other companies so I wonder is that every company doing the same thing?

Or is this actually just my own problem that I should try harder to remember everything in MSDN in my mind so that I can work even without it and internet?

EDIT

For better explain my situation regarding Frank's concern about job tasks. Sorry it's my bad didn't clarify those background.

There actually will be no specifically job's task changes, I personally think what I've done already played as a senior, like code review, mentor members, review BA's doc and give technique opinions, design architecture of new projects, it's just my title still stayed without senior and I asked to get one to reflect pay slip and lead to such an interview. This is a Saas company so people stay in one project as long as that product is still alive, this leads they need people be able to design more new features based on current product, fixing technique difficulty on live servers, design/code review/mentoring members And higher level title based on technique would be Architect and we do not have any job similar with Technical Expert. And I agree if you want to play Technical Expert role you should know more detail about the tech you use. Sorry it's my bad didn't clarify those background.

Answer 1

As a senior engineer and a person who hires engineers, it sounds like the interview process missed a whole swath of conceptual information.

I want my senior engineers to be able to visualize an end-result, choose the right technology, design the right database and processes, and be able to delegate the detail to other engineers when needed. Google is always at their side, so I focus on their ability to deliver results, rather than how big of an SD card they plugged into their ear. (lol).

Hope it works out well.

Answer 2

It's not entirely sure what the tasks of a Senior+ in your case would involve. Always keep in mind that it is much more important to know what your job's tasks are rather than what your position is called. While having a Senior in front of your job title may have an impact on your financial outcome it does not in any way tell anything about what you actually do in your work. There are however two different types of senior level "developers".

System Architect

If you were interviewed for such a position, then indeed something is amiss. I agree with gahooa that such an interview should focus on the big picture thinking of the candidate, which seems to have been missing in yours.

There is, however, also the kind of evil perspective on this: in everyday work you will always be overwhelmed by those little detail things and it'll be your responsibility to keep track of the big picture despite all of these minor disturbances. If you want to test whether a candidate is able to not lose him/her-self in the small details one way might just be to try to sink him/her in those details. If you did not remind them that the envisioned architecture position is about the big picture - you might have just failed that test. Though I doubt that, as this sort of interviewing certainly isn't on the friendly side of things.

Technical Expert

In this case you may not be able to influence the overall system architecture and company direction much. Instead you will focus on the design level. Do note that all the questions you gave as examples fit perfectly into this category. From a senior developer responsible for SW designs I do expect him/her to know stuff like JIT, GC, data structures, etc. in and out - without needing to look up anything but the most intricate details. If you're supposed to make a software design, yet do not know the difference between an array and a list you're in the wrong position.

From reading your question I suspect that your job position (the current and the proposed one) focuses on software design. In that case, you may want to rethink what you actually should know/remember and what not. Given that you work with these things day by day there should be little need to look something up for answering elementary questions like those.

---

On a side note: a former professor of mine had the interesting habit of asking questions about elementary subjects in oral exams on advanced courses. While these subjects were never explicitly covered in the advanced course a student was supposed to know them from their elementary education. In interviews (of any sort) I adhere to this behavior as well, because over the past years I have witnessed over and over how students/candidates for something "advanced" have a severe lack w.r.t. the foundations. Given that reasoning, I for one have no qualms about asking a candidate for a senior position what a listener pattern is, or what the pros/cons are of keeping the listeners in an array vs list vs set.

Answer 3

I am sorry, but I do not think that the kind of questions you were asked are trivia that should be Googled when needed. This may be true for the class name when you process Upload file, but:

• what is JIT: This is a fundamental technological concern. A senior programmer should definitely know what this means at least high level. For instance, this affects the performance of different VM and runtimes, hence it should be at least considered when evaluating a new technology.
• how GC works: similar to the above. The algorithms for GC are at the core pretty simple, and one should at least be familiar with generational GC versus mark & sweep, versus reference counting and the various tradeoffs
• difference between List and Array: this is a basic question that I would expect a junior programmer to know
• abstract class and interface: same as above. I do not understand how one is expected to architect a complex system without knowning at least interfaces
• delegate and event: again, to design a robust and flexible system, event delegation is one of the basic patterns.

It seems to me that they have done a pretty good job of asking conceptual questions that are relevant to a senior programmer without getting lost in trivia.