For my next blog post, I wanted to talk about programming interviews. When I graduated from college in 2001 and got my first job, the technical interview process was fairly straightforward. The interview process would typically begin with a brief talk with a recruiter or a member of Human Resources. If they liked you, you would then go on to have a technical phone screen. If you were able to pass the phone screen, you would then be brought in to do a face to face with technical managers, maybe do some white boarding and this would complete the interview process.
In the last 5-7 years, I have noticed that many employers are now requiring developers to write code during the interview process. I remember reading an article about ThoughtWorks, a software consultancy and a company known for its rigorous interview process. When asked why ThoughtWorks makes its prospects write code during the interview process, the person being interviewed responded by stating, “If you were going to hire a Violinist, wouldn’t you want to see how well they played the violin before hiring them?”.
I believe Programming Interviews are important, relevant and a good idea when implemented properly. I wanted to take some time to talk about my thoughts about Programming Interviews and my experiences with them.
What are the goals of Programming Interviews?
Programming Interviews should measure a candidate’s skill level in a certain technology. Programming Interviews should be created and implemented in a way that aligns with the job description and should allow an interviewer to determine how proficient a candidate is in a given technology. Also, it should help the interviewer determine how well the candidate follows instructions, their logic and reasoning skills, how they go about solving problems and how quickly are they able to solve problems.
Some in employers make the mistake of implementing a “one size fits all” Programming Interview and I believe that a Programming Interview for a Junior level candidate should be different than someone who is applying for a Senior or Architect level position.
How should Programming Interviews be Implemented?
Most of the Programming Interviews that I have taken part in were remote, using various software programs that allowed the interviewer to view my desktop as I was attempting to complete the assignment. Also, your employer will have to determine how much time will be given to the candidate to complete the Programming Interview. I have done Programming Interviews where there was a 1 hour time limit and others, where the employer gave me the assignment and told me to complete it in a week.
Personally, I am a much bigger fan of Programming Interviews that allow the candidate to do the work on their own computer, that are not timed and the the candidate is given a few days to finish the assignment. The reason I believe this is that first, I am a big fan in trying to simulate real working condition as much as possible when interviewing a candidate. When someone works for you, they are going to be creating software on a machine that is configured in the way they are most comfortable. Also, very rarely will there be working conditions where an employer will stand over an employee’s shoulder, observe them for an hour until they complete a task. In most cases, an employee is going to have more than an hour to complete a task and someone is not going to be standing over their shoulders while working on their task. If Programming Interviews are implemented in a way that allows candidates to use their own tools and candidates are given a few days to come up with their best solution, this would provide better insight into the candidate’s skill level.
Eat your own Dog Food
When an employer decides to make Programming Interviews part of the interview process, they should ensure that the employees that are responsible for giving Programming Interviews have actually taken the interview themselves. How can a interviewer have a reasonable idea about how long a Programming Interview should take and evaluate the quality of the submitted solution if they themselves have not attempted the assignment?
Several years ago I remember I had an interview with a company in North Dallas. It was a very intense interview process and the last portion of the interview was a Programming Interview. The interviewer brought in his laptop and it had at least 20 browser windows open making it very hard to navigate between Visual Studio and a single browser. It was also going to be Test Driven Development and we were to pair program to simulate a “Cuckoo Clock”. The “Cuckoo Clock” Programming Interview was the very first interview that I didn’t complete. I felt that the employer had too many criteria and that it was a little too complicated to be able to be completed in 1 hour.
After the interview was over, I asked the interviewer how long it takes most people to complete the assignment and he responded by stating that he didn’t know because he had just come up with this Programming Interview assignment earlier today and he himself had never taken it to establish some type of baseline. He jokingly stated that he could tell that I was the type of person who would go home and complete the assignment because I didn’t finish it. He was exactly right as I went home and completed the assignment in the comfort of my own home, on my own computer and did it in a reasonable amount of time, which is much closer to the daily working environment of this company. After completing the assignment, I mailed the solution to the Consulting Firm I was trying to join but I am not sure if they forwarded it to their client I had interviewed with.
Is this what I will be doing at your Company?
If your company decides to incorporate a Programming Interview, one item to consider is to make sure that it will not be perceived that this is the type of work a candidate will be doing at your company. Most of the Programming Interviews I have been involved in have focused primarily on how well I write code, architecture, logic, reasoning and problem solving skills. Very rarely will a Programming Interview involve some of the more advanced concepts of a technology because typically you have already gotten a feel for the level of the candidate from the phone screen and many feel that clean code, logic, reasoning and problem solving skills are a lot more important then knowledge gaps in a given technology. I once had a Programming Interview where I was only given 4 hours to create a Front-End Application and a REST Service that would allow a user to upload an Excel Spreadsheet and this Excel Spreadsheet then had to be converted to a CSV file in memory and returned back to the browser. Whether it was true or not, my perception was that this Programming Interview was indicative of the type of work I would be doing at this company and I decided to drop out of the interview process.
Treat your Programming Interview like it’s the Constitution
What I mean by this statement is that when your company decides to implement a Programming Interview, at some point, word will get out about the specifics of your Programming Interview. Like the U.S. Constitution, to prevent candidates from being able to crack your Programming Interview solely because they had the details beforehand, you need to consistently amend your Programming Interview, create new challenges and have enough material so you can rotate your Programming Interviews. There is one very well known Consulting Company that has an office in North Dallas that gives out the same Programming Interview to each of its candidates and now, many candidates already know what to expect. After I completed the Programming Interview with this company, I literally Googled the assignment, one, to see if it was out there and two, I was curious to see how my solution stacked up against others and to my surprise, it was right there on the Internet for anyone to gain access to it.
Your Programming Interview is not God
If your company is going to implement a Programming Interview, take care to ensure that the results of the Programming Interview is not viewed as the “end all be all” when deciding if a candidate would be a good fit for your company. In the world of Software Development, technical skills are paramount but you also have to take into consideration a candidate’s soft skills, personality, work ethic and the interviewing conditions. Some candidates don’t do very well when they are timed. Other candidates may have trouble working when people are watching them code. I tend to get very nervous when someone is watching me code because I feel like I am being judged and that I am going to be finally exposed for the Imposter that I am.
At one consulting company that I worked for, I worked with a consultant that aced our Programming Interview. Unfortunately, as a consultant, she had a hard time completing tasks, taking ownership, taking initiative and had a very poor work ethic. This individual was eventually fired but I know one of the main reasons she was kept around for so long was because management kept saying, “We can’t let her go, she did great on the Programming Interview!”.
I had a friendly debate with a fellow Architecting Innovation consultant about Programming Interviews. He felt that if you couldn’t complete the Programming Interview then you shouldn’t be hired. I understand this form of thinking but I believe that it is somewhat flawed. As stated, I think you have to take into account several variables when evaluating a candidate. I quickly retorted, “Just because you can’t pass a Programming Interview doesn’t mean you won’t be a great employee and just because you can pass a Programming Interview, doesn’t automatically mean you will be a great employee”. After pondering my retort, he actually agreed with me but stated that he would need to see why they were not able to complete the Programming Interview to make a final decision.