Beyond Code

The Technical Interview

Good Interview Process

Good Interview Questions

1. Describe the project architecture (or any project's architecture) briefly, and then turn over to the candidate.

   None-threatening, because for the first 5 minutes the interviewer talks, not the candidate. No specific questions, instead candidate driven.

   To look for:
   • Responsiveness
   • Understanding: immediate, or does the candidate need an explanation?
   • Comments: measured, thoughtful response?
   • Confident to voice criticism or just blanket approval?
   • Expression of previous experience with a similar system?
   • Human interaction: could we work together on this?
2. Personal work history descriptions: What did you do, what were your responsibilities and your specific contributions?
3. Questions on social interactions (how do you work with others, etc) can be interesting, but are not necessarily leading far.
4. Questions on software engineering practices:
   • Exposure to config control - do you own your files or do you practice shared ownership? If you own your files, would you be ok with someone else making modifications to them? Would you be willing to make modifications to someone else's files?
   • Exposure to unit and regression testing.
5. A dozen code-snippets with subtle C++ bugs (example here)

   Shows understanding of C++: really necessary, because you have to be an expert to write good C++ code.

   Also shows whether the candidate has ever understood the necessity to become a C++ expert and drawn the necessary consequences? Ie is the candidate a careful worker?

   Important to have at least 10 different questions!

   What to look for:
   • Does the candidate find the bugs quickly?
   • Have the candidate describe what he sees, if he does not find the bugs quickly - shows his understanding and thought process.
   • Does the candidate give up easily or does he say: "Don't tell me - I am going to find it!" - if there are only 3-5 lines of code, a good programmer should take it on his honour to find the bug!
   • In case the candidate gives up and you explain the bug to him: does he get it?
   Case studies:
   • One candidate found a lot of really obscure C++ rule violations, but was unable to find simple typos or slight bugs in code that actually did anything: Academic knowledge, but less can-do attitude?
6. How would you model a parking lot?
   What to look for?
   • Expected answer: A parking lot is (at least conceptually) a container for objects of type vehicle - vehicle may be subclassed for different kinds of vehicles: trucks, motorcycles, cars, ... - Important concepts: container, inheritance!
   • Does the candidate jump to conclusions as to what the parking lot is supposed to do?
   • Does the candidate approach this problem in an object-oriented way or in a data-driven or functional way?
   • After the first general stab, the candidate should ask for additional requirements: what is the parking lot supposed to do, how is it to be used. Does the candidate offer possible ways that it might be used (in a fitting problem, in a real-time control system, in a billing problem, for instance)
   • Comments about implementation issues are generally inappropriate, unless the specific use of the parking lot has been established!
   • Follow-up question: What functionality would be abstracted/encapsulated in the parking lot? Expected answer: size or capacity, occupancy, even which slots are filled. Anything else depends on the specific usage!
   • Advanced follow-up question: where should the responsibility to to park a vehicle? ParkingLot.park( Vehicle ) or Vehicle.park( ParkingLot )? Reason for choice? Introduce Meilir Page-Jones example: unmilk the cow, or uncow the milk? Therefore: Introduce parking mgr (Can the candidate name an applicable Pattern? Mediator!)
     Benefits:
     • less smart objects: more reusable
     • less coupling (otherwise cars need to know about parking lot and vv)
     • Single pt of control
     • Better conceptual modeling!!!
7. Programming exercise. For instance: write a fct that finds the first occurrence of a string in another string. It is important to keep these exercises trivially simple. These questions are sanity checks to see whether the candidate can program at all. They are not designed to see whether the candidate can develop complex algos at the blackboard - which is an irrelevant skill, since this is not part of the job description (non-trivial algos are developed at the desk, alone, while no one is watching!).

   It is important to find a topic that does not require specialized skills or API knowledge - unless that is what is to be tested specifically.

   Programming exercises are extremely high stress and not their results not necessarily all that relevant. Keep them short, sweet, friendly and non-threatening. Remember: they serve as sanity check, nothing more!

   Exercises in interviews should have a clear purpose. Simply hazing the candidate is not acceptable. How ultimately important (and meaningful) is a correct program in the end?

   Possible focus points are:
   • basic language syntax
   • ptr handling (C)
   • inheritance mechanism (?) (C++)
   • API knowledge (if this really is supposed to be tested)

   Java: libraries so disproportionally huge compared to basic language, every question becomes a Javadoc question.

   Design Questions (such as pre- and post-conditions, valid parameter assumptions, error handling and reporting, possibly threading issues) can be discussed in a less threatening setting, possibly using pseudo-code.

   Another good example exercise: int atoi( char * )

   or (more tricky, C++ only) operator=() in presence of deep copy and exceptions

   What to look for:
   • Can the candidate do it?
   • What assumptions does the candidate make about the interface? Pre-, post-conditions, error handling and reporting?
   • Is the candidate willing to discuss alternatives?
   • The candidate will implement the simple O(n^2) algo for the findIn() problem above - ask about efficiency. Does the candidate know about advanced algos?
8. Bring up a technological topic: Java vs C++, the benefits of J2EE, XP vs RUP, anything that might be contentious. Question: What do you think of it, how do you like it?
   What to look for:
   • Does the candidate have any interest in the topic?
   • Does the candidate give a measured response? "All bad" hints at a personality problem, "All good" indicates a lack of independent thinking.
   • Is the candidate able to make specific comments or does he remain mired in vague generalities? Is he able to back up his assessments with specific facts or examples?
   • Does the candidate refuse to take a personal stand?
   • Is the candidate willing to say "I don't know enough about it" or does he try to snow you with buzzwords?
   • Does the candidate exhibit unreasonably strong preferences or pet peeves? This is indicative of personality issues, which will directly affect his work (not just his interactions with peers). The key word here is "unreasonable" - preferences, are a sign of maturity, provided there is a clear sense of flexibility around them.
9. Tell us about some Patterns you have used? Shows to what degree the candidate has read the literature. Since the relevance of formalized patterns can be somewhat open to debate, this question might not lead far.
10. Have the candidate bring in code samples that he is willing to show and he thinks are representative of his work. Sure, they may be faked or copied, but when he is asked to explain them, it will be pretty obvious whether he knows what he is talking about!
    What to look for:
    • Decent code lay-out, decent variable names, etc
    • Is the candidate able to explain not only the code, but also the trade-offs of the specific design decisions made?
    • Is the candidate able to discuss alternative approaches?
    • Is the code robust? Are errors handled? Are pre- and post-conditioned handled properly? Does the candidate discuss pre- and post-condition issues?
    • Are the fct or class interfaces sensible, minimal, complete (within the realm of the sample application), consistent?
    • Is the sample application appropriate? (1-5 pages, simple to understand, ...)
11. Does the candidate show open cynicism (about the profession, the job market, his former workplaces) in the interview? This is bad, not only for what it is, but because it demonstrates the failure on the side of the candidate to understand the interview situation!
12. Does the candidate show a sense of humour?

Terrible Interview Questions

1. C syntax questions, specifically C fct ptr syntax (one of the most absurd questions I have heard was: What is the syntax for a pointer to a member function of a C++ class?)
2. Programming examples based on linked lists. In modern programming languages, linked lists are provided as part of the std libraries. Programmers are can not be expected to have a lot of experience implementing linked lists themselves. (This is known as progress!)
3. Never ask only one question of a kind: Do you know this pattern? What is wrong in this code sample? etc to avoid flukes (false negatives or positives!)