The 5 Types of Technical Interview QuestionsMay 28, 2007
As I mentioned before, one of the most popular topics of this blog is the “interview questions” section. The following post tries to sort out the different types of technical interview questions one should expect.
The logic puzzle is a favorite of many interviewers. The basic premise is that you are given a relatively tough logical puzzle (not necessarily related to digital design) which naturally, you should aim to solve. I used to belong to this school of thought and when interviewing people for a job used to try a few puzzles on them. The reason behind giving a non design related puzzle is that you want to try to assess how the person handles a problem which he never encountered before. The problem with this approach in my opinion is that the majority of puzzles have a trick or a shortcut to the answer, which makes them so elegant and differ from “normal” questions. These shortcut are not always easily detected under the pressure of an interview, moreover, who says that if you know how to solve a mathematical puzzle you know how to design good circuits?
Tips: If you do get this kind of question and you heard the puzzle before – admit it. If you encounter difficulties remember to think out loud.
Bottom line: I love puzzles, especially tough mathematical ones, but still I do not think it is the right approach to test for a job position.
I actually got this one in an interview once. I can only guess that the interviewer either hopes that one of the candidates will solve the problems he (the interviewer) was unable to, or to see whether the candidate encounters the same problems/issues/pitfalls the interviewer has already experienced. I believe those kind of questions are well suited for a complicated algorithm or state machine design. I can see the merits of asking such a question, as the thought process of the candidate is the interesting point here.
Tips: Think out loud. Maybe you can’t say how something should be done, but if something can’t be done in a certain way, say why it is not a good idea to do so.
Bottom Line: This could be an interesting approach to test candidates – I just never tried it myself…
This type of question is the most common among them all. In my opinion, it is also the most effective for a job interview. The question directly deals with issues encountered at the job’s environment. If the interviewer is smart, he will ask a sort of incremental question, adding more details as you move along. This is very effective because he can very easily “feel” the ground and detect what are the weak and strong points of the candidate. Many of the questions start simple and as you move along the interviewer will try to throw in problems or obstacles.
Tips: Study some good solid principles of digital design (e.g. synchronization issues, synthesis optimization, DFT etc.). When you get stuck, ask for help – since the question is usually incremental it is better to get some help in the beginning than to screw the entire thing up.
Bottom Line: The best and most fair way to test a candidate.
you might come across this kind of question sometime in the middle of the interview, where you interviewer tries to see how much hands-on experience you got.
Tips: Learn the basic constructs of an HDL i.e. learn how a flip-flop is described, Latch, combinational always/process etc.
Bottom Line: I believe this is a stupid approach for an interview question. In my opinion, the concept and principle of how to design a circuit is much more important than the coding (which we all anyway cut-and-paste…)
This should be pretty obvious. Just remember to talk about a relatively small design you did – nobody has time or interest to hear about 4000 lines of code you had in a certain block. A very important point is to understand tricky points and to be able to say why you designed it like you did. Not less important is to know why you didn’t choose certain strategies.
Tips: Be well prepared, if you can’t tell about a design you did in detail, chances are you left a bad impression.
Bottom Line: This question is inevitable – expect it.