My Two Cents on Interviewing Software Engineers

In the technology industry, interviewing someone is a tough process. It is a very complex problem that attempts to solve a collection of goals into a [best case] mutually satisfactory outcome. The interviewer needs a person who will fit in the working environment, perform tasks that are expected, has the needed skills, and is competent to do that job, all while avoiding an undesirable hire. The interviewee is looking for a new position in a reasonable environment, with people they can trust, and that helps them obtain the lifestyle/financial goals that they wish to achieve. There are three outcomes of this process: hire, wait for more experience, or don’t hire. Dancing around the decision, or making this process more difficult helps neither party.

What I’ve found incredibly frustrating is the attitude of many of the interviewers that I have been interviewed by. Most of the individuals whom I have been interviewed by have been highly combative. They want you to prove that you know what they want you to know, whilst simultaneously proving that you would be a good cultural fit. For example, smaller organizations will throw out Google/Microsoft like interview questions just for appearances. Is this necessary for determining the quality of the applicant? I don’t believe that it is. Unless your industry requires every engineer to make close estimations, it appears to me that it is more of a way to build an unrealistic ‘tough-guy’ image. There is absolutely no reason for an interviewer to be combative with an interviewee. The goal, on the company’s side, is to find out if the applicant would provide value for the company. If an individual’s average day is fairly easy going, why make the interview stressful? It’s akin to demanding an auditioning actor to recite the entirety of Shakespeare’s work when interviewing for a non-speaking role in a 30 second commercial.

Another issue that I’ve found is the amount of criticism of interview code. I’ve had a range of this: “code portfolios,” sample programs prior to the interview, temporary assignments, IQ tests, talk and coding, and white board exercises. Only a few of these coding practices are reasonable, the others are unrealistic and stressful. The IQ/aptitude test was a part of the application process at IBM. It was a little silly, and timed, but I guess I was within their upper and/or lower limits for acceptance. The test was online and it was after the interview, so it wasn’t so stressful. I’ve had an organization request a coding portfolio; that is a horrible idea. Portfolios are required of those who do visual work, but code portfolios suffer from a lack of context, industry acceptance, and lack of time to compare and contrast multiple candidates’ submissions. I’ve had to work with one group temporarily [after the interview] as a trial period. This wasn’t so bad for a few reasons, one the company paid for my travel to get me there (going from the US to Europe), was only for a short time and lastly, it isn’t unreasonable to ask for this when considering very long distance applications. However, the downside to this is that it negatively impacts the discreteness of interviewing a new workplace.

I tend to like coding samples prior to the interview. If you’re given a problem set to choose from, it gives the interviewee a chance to emulate the conditions in which they would be working in. The interviewee is able to ponder, on his/her own schedule, about the problem, design, code, test, and package the code. I am not a fan of coding on a whiteboard. It is a completely different experience from how one codes. It strips away the tools and contexts, and expects the individual to perform their tasks in a completely foreign way. If the interviewer was asking for high level details, this request isn’t too far fetched. From my experience, there are a lot of organizations that attempt to have the interviewer watch an interviewee code via a live collaborative editor while on the phone. These are some of the worst interviews I’ve ever had. The task is not humanly possible. The tasks are usually set up in a professor/student manner. The process is usually: a problem is presented, thinking occurs, have the interviewee talk through a problem, code while explaining the code, and to use a foreign editor at the same time. To make things worse, this is all done while the interviewee is holding a phone and typing on a keyboard. It is not humanly possible for an individual to communicate, and solve deep problems at the same time, to make things worse you’re being judged at the same time.

Lastly, I have been asked to code up a problem or two, with the interviewer on a computer. This has been done in a peer-wise and non-peer-wise fashion. Usually this involves a small problem, and you’re given a new project in an IDE. At times, this may be a little tough if the IDE is unfamiliar, but this at least attempts to reproduce the working environment.

What are some of the questions that I would like to be asked?

I believe that an interview should be more for an inquisitive time between an interviewer and interviewee. There is no benefit from trying to make a stressful interview even more stressful via combative techniques. So I think there are a few questions that would make it easier:

  1. Ask questions related to the projects that the interviewee has worked on before. [Preferably a non-work based project]
  2. Ask about some of the challenges faced on the projects. For example, if the project required a high level of performance, how did they solve the communication issues between components? If the project dealt with numbers or precision or money, ask how they solved the issues with floating point math.
  3. Ask what an individual project taught the interviewee.
  4. Ask about times where the interviewee has conflict with another coworker; ask how he or she would have resolved the issue. (Don’t ask for opinions or gossip surrounding the conflict)
  5. Ask about what blogs/technical content they follow.

These questions get the interviewee to talk more about what they should be confident on talking about. The questions also demonstrate the ability to work with others, willingness to adapt, interests, technical strong points, experience, passion, and potential weak points. Lastly, to the interviewer, consider the individual that you are communicating, with being hostile won’t do you any favors if you have to work with them later.

  • Eric Hydrick

    Coding on a white board is a little stressful beyond FizzBuzz, but pseudocoding on a whiteboard is pretty useful to gauge how an interviewee thinks, processes information, etc. It also focuses on *how* they’re designing a solution to the problem, and can lead to discussions on the problem-solving process.

    I’ve done the phone-based code/be observed bit too, and it does suck. I’ve had a couple of “homework assignment” style programming questions though, where you’re given a problem, due date, and told where to send the solution to. Those tend to be much less stressful and let me focus on the code I’m writing.

    • crash025

      From my point of view, If you’re asked to do anything on a whiteboard during the job, you’re asked to do high level interactions between components and/or modules. You will never code on the board. However, I’ve been asked to code on the whiteboard before. Another thing I’ve had to do, while whiteboarding, is to write a piece of software that generated primes. I get the sense that the guy was asking for me to do a recursive prime number generator, and then quiz me on why thats a bad idea. [I used the sieve of sieve of eratosthenes, and I’m not sure that the guy was too pleased with that]

      From my experience: When working on a problem you’re judged on how you’re working on the problem, and usually the interviewer judges it against their own style.

      • Eric Hydrick

        I’ve been asked to pseudo-code, and sketch out solutions on a board, as well as code. The first 2 are fine, they gauge how you think and process the problem. The latter is stupid when we live in a world where IDEs exist.

      • Don Almeida

        The sieve of Eratosthenes is the the best way to find prime numbers. Only good CS students know this.

        • Warren

          It’s certainly A good way to find them. For smallish values, it’s fast – but does waste a lot of space

  • Pingback: NEW RULES: People being interviewed are not allowed to reply any more, to the interviewer saying “that is a good question” | Sunset Daily()

  • Warren

    I disagree with “coding samples” in almost any form: give me algorithms, overviews, your design approaches, whiteboard swags, etc. I want to see how you think, how you communicate, and why you think the way you do.

    I also always give problems outside the [direct] experience of the candidate: they’re not trivia, they’re not riddles – they have “wrong” answers, but there is no one “right” answer. Requirements of a given assignment/problem/etc will change so frequently (unless you’re on the crew that maintains the ISS life support systems) that sticking rigidly to coding samples etc is a Bad Idea.

    An interview tends to be a poor heuristic on whether to hire someone or not: bad days happen, and overly good days happen, too.

    Some of my thoughts on the interview process –

    • crash025

      I’m not sure about setting traps with wrong answers. I think it would be interested to see how the candidate responds to learning something new.

      • Warren

        There’s no trap – the “wrong” aspect is generally in relation to unqualified answers, no explanation of assumptions, etc

        • crash025

          Just to clarify I’m not talking about completely wrong solutions. I’m talking about uncommon alternative workable/semi-workable solutions.

          • Warren

            I’m good with workable – I’m NOT ok with wrong answers :)

    • Eric Hydrick

      I support code samples just to get a sense of “what is this developer going to check in that the rest of us are going to have to try to maintain and understand”.

      • Warren

        the average developer can’t submit coding samples – everything they’re likely to have that’s “interesting” is locked in some corporate SVN

        • Eric Hydrick

          True, but you can pose a problem similar to the kinds of things they work on, and either get pseudo-code, or if it’s small enough, ask them to do a homework problem on their own and submit it.

          It’s not as good as “Hey, are there any open-source projects you contributed to we can look at?”, but it’s something.

          • Warren

            if I’m getting homework for an interview, I’m ending the application myself – but that’s just me :)

  • visafraud

    Really…were you born yesterday? These fake “software interviews” are direct result of infestation with H1B VISA FRAUDS. Welcome to today’s world.