Technical Interviewss

I have been going for some job interviews lately, and what has been interesting is the technical interview aspect of each of them. I have been to what I consider 2 major interviews, each with the technical interview (they all consisted of at least 3 interviews) going for at least 2 hours, usually up towards 3 hours.

While both of them were for fairly prominent .Net related positions, tey they were both vastly different. One involved an initial multiple choice test, with a further one on one interview discussing some fairly detailed technical questions. The other involved almost next to no .Net related technical questions, but instead concentrated on process, architectural and design skills. The latter had me describing the software development lifecycle (SDLC), drawing plenty of UML diagrams such as use cases, sequence diagrams and class diagrams, as well as a quick code test I had to write up on a whiteboard. The individuals interviewing me were clearly of high quality but were definitely not .Net specialists (I had to explain some basics of ASP.NET operation such as code behind files).

As mentioned, the first interview had some fairly detailed technical questions, but were usually things that one could easily find using on line help, or a bit of searching on Google. It was more a memory thing, whereas the second interview definitely exercised skills that you cannot get from some help system, a reference manual or anything else except experience. It was damn hard, but I did pretty well and even if a) I dont get the job or b) dont want the job, it was a very valuable exercise in architectural and design knowledge.

Motto of the story: Know the expectations of your job interview. Knowing a method signature on a particular function of a .Net library may not help you at all, and in the end, nothing is a substitute for experience. This kind of implies I have a huge base of experience, which is really subjective and may or may not be true, but the point is that my general experience has served me better than my knowledge of method level functions in a class.

I'd be interested in others experiences in technical interviews though. What else have you come across?

2 Comments

  • While I agree that knowledge of a given method's parameters does not reflect much on the skill of a candidate, I find that those that can write compiler ready code on the whiteboard are often what I'm looking for. THe reason for this is that it shows how much the person uses a given feature of the language - something which only comes with experience.



    I guess I'd be a lot more willing to give up on syntax skills for the process skills you mentioned, however, should I come across both the process and syntax together - well, that's a candidate I'd be clamoring for.

  • Hi Udi,



    Its not that I dont value that knowledge, but its been of less use to me in interviews than I would have thought.



    Also, when I have conducted interviews, we have had a large number of candidates touting this knowledge, but very little else, which is understandable to an extent. If you lack experience in areas, you need to showcase your other qualities, which is what these candidates have done, its just not what we were looking for.

Comments have been disabled for this content.