Numerous resources explain how software companies (Microsoft, Google, Facebook, etc.) conduct coding interviews. Even books have been written on this topic, full with examples of coding questions.

I understand that one can get an accurate picture of a candidate's technical skills with such interviews, and that's of course very important. But other factors, too, are crucial. For example:

  • How motivated will the candidate be?

  • How productive is the candidate?

  • How organized is the candidate? For example, does s/he maintain a clean revision control history, or does his/her revision control history look like spaghetti of branches and merges?

  • How good commit comments does s/he write?

  • How clean code does the candidate write? How easy to read is the code?

  • etc.

How do software companies test such essential aspects?

  • Big companies have procedures and processes for the employees to follow. If you don't follow procedures, you are out. – scaaahu Oct 26 '15 at 10:02
  • @scaaahu, being able to "follow procedures" has very little to do with productivity, organization, and qualities like clear communication and good taste in code. These things require a highly subjective approach to evaluate and nobody has it "figured out". One factor that helps is that many candidates are not completely unknown quantities, they're referred to jobs by their professional network. Candidates with excellent soft-skills will develop and maintain good networks and this acts to get them leads that would otherwise be unavailable. – teego1967 Oct 26 '15 at 10:42
  • @scaaahu at some point, there is a person who is responsible for deciding on those processes and documenting them. If you're going to be in line to one day have that position, it probably helps if you're comfortable with best practices of your own accord rather than just following them because you're told to. – Amy Blankenship Oct 26 '15 at 15:37

That depends entirely on the company. However, most of these skills are not objective. How "clean" is one example. One developer's "clean" might be another one's "cryptic".

There are some options to test this, and they all come with their own advantages and drawbacks:

Test the candidate on the interview

This takes little time and little preparation. Let the candidate code something and take a look. Good candidates will show some degree of "clean" even on interviews because it has become their default mode of operation. However, an interview is the exact opposite of their day job. It's a stressful, time-limited task and if you expect good code then your coders at work should not be that stressed. So it's better then not testing, but the result is a vague guesstimation.

Test the candidate a full day

This step takes both time and preparation. Have the candidate work for you for a day. Give the candidate a task that someone else has already solved in a day, so you can compare how good the candidate is, how productive and clean. Although there is stress, the candidate has a full day to go for a breaks, think about the problem, ask someone, or Google for additional information -- time enough to do it right. However, this goes both ways. You need to invest time to actually judge a full day's work. And the candidate will see your company. How you work. That should be a good advertisement for the job, but make sure it actually is.

  • 9
    If you're a regular company and not a software colossus (like Microsoft, Google, Facebook etc.), then expecting candidates to spend 1 full day doing free work for you is a bit unrealistic. People have very busy lives, programmers even more so. You need to figure out how to do it in those 60 - 120 minutes of regular interview time. – Radu Murzea Oct 26 '15 at 11:59
  • 2
    Well, for one they aren't "working for free" because they are not doing work you need. The company does not profit from the work done. Are they being tested a full day? Yes. And it's a real option to say "no thank you, I will take the other job". In my experience, people don't. Because it's also a day where they can test the company. Where else do you get that? – nvoigt Oct 26 '15 at 12:11
  • In response to "working for free," it is essential that you not have the candidate do work that will wind up in production. What may be better is encouraging them to put the code sample or their finished product in their github repository so that there is value added to them candidate. – silencedmessage Oct 26 '15 at 15:59
  • 3
    I certainly would never consider a company that required a full day interview, that is just inconsiderate to expect that people who are looking for work don't already have jobs and work they have to do. It is hard enough to squeeze in several couple of hour interviews, several full day ones are impossible. – HLGEM Oct 26 '15 at 17:38

They often really don't get that nitty detailed at all. Many large tech companies test your analytic, coding and design skills. They probably evaluate whether you can take criticism of your code or algorithm and discuss it objectively without taking it personally (with the irony that the interview is the one time it very well may be personal, but it's up to the candidate to not flinch over that).

Your code tells more than you think. The interviewer will probably push on testing. You will have to answer both what tests you will run as well as how you will factor your code so that it is testable, which in turn says something about your engineering-organizational skills at large. You certainly answer how you think and communicate (to the arguable detriment of the most introverted candidates). A lot is happening over an interview.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .