AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Interviewing Engineers Continued – Part II (The Technical Interview)

The technical interview is important because besides the code test and the phone screen, which both can be misleading, it is the only chance you get to see what the engineer brings to the table in terms of their technical prowess.  First we should probably address why the code test and phone screen can be misleading.  Depending on how you conduct each of these there is a very real possibility that unsavory candidates will cheat to some degree on these.  During the phone screen you may hear frantic typing in the background, a possible hint that they are googling your questions.  If the coding test is done remotely or if the same one is given to everyone it’s likely, at least according to this article and this one, that a high percentage of candidates will cheat on it.  So that leaves us with the in person technical interview as the one remaining check we have of how good they are technically.

To start with we think there are at least seven areas of knowledge in which every engineer should have at least a solid understanding if not proficiency.   These areas are: 

  1. Algorithms, big-O or asymptotic notation used to describe upper and lower bounds for algorithms and how growth can be constant, linear, or logarithmic.  
  2. Object oriented programming, the fundamentals of inheritance, encapsulation, abstraction, and polymorphism and how these are implemented or not in their particular language of choice. 
  3. Syntax, data structures, and type of a primary language, be able to write a method on the board without glaring syntactic errors.
  4. Design patterns, why they exist and at least a couple of the more common ones such as factory and bridge. 
  5. PDLC, know the difference between Waterfall and Iterative lifecycles and be able to argue for the appropriate uses of each.
  6. Source Code Control, should believe in the concept and have knowledge of at least one platform.
  7. Compiler / Interpreter, should have an understanding of the debugger and that they be able to read and step through the compiler output (assembly equivalent) in the debugger.

How do you put these into a technical interview?  We recommend start off by picking your favorite sorting algorithm, such as a bubble sort.  Ask the candidate something similar to the following:

  • What are the steps involved in a bubble sort?
  • What is the worst and average complexity (big-O notation) of a bubble sort? 
  • In the expected language that will be used every day, write a method implementing a bubble sort on a white board.
  • What OOP properties are displayed in the code?
  • If the sort was written in C++ with an iterator what design pattern is being followed?  {or some language appropriate design pattern question}
  • What PDLC methodology did they most closely demonstrate when writing the bubble sort?
  • How would you check in this piece of code?
  • What are the steps that compiler goes through when compiling the bubble sort code? 

In a few quick questions you have covered in a concrete fashion the seven areas of knowledge that an engineer should possess.  Do you have any favorite engineering interview questions?


Comments RSS TrackBack 3 comments

  • Blinnisphes

    in April 4th, 2009 @ 14:35

    Great site this akfpartners.com and I am really pleased to see you have what I am actually looking for here and this this post is exactly what I am interested in. I shall be pleased to become a regular visitor :)


  • Abbott, Keeven, Fisher &#038 Fortuna Partners

    in April 7th, 2009 @ 09:07

    […] like a good approach to interviewing. We combined the two, presentation and programming, in our recommended approach to the technical interview. You probably can’t go wrong with either approach. […]


  • Hiring ‘A’ Players | AKF Partners Blog

    in March 22nd, 2010 @ 22:37

    […] also think the technical interview is critical to distinguishing the ‘A’ players, whether or not you use puzzle […]