First off, by coding skill, I mean the ability to translate an abstract description of a solution into clean, efficient, and working code.
In all of the tech-heavy interviews that I have conducted for junior engineer and research assistant positions, I haven’t explicitly checked for coding skills. Instead, I have done the following.
- See if the candidate had CS education/training. If so, then they often will be able to hone their coding skill if they come thru the interview as smart problem solvers with good grasp of fundamentals. Of course, as the interviewer, I have vetted the mentioned CS education/training is a sufficient indicator of the required coding skills.
- Examine the candidate’s software project portfolio. If they don’t have CS education, then I have asked for their software project portfolio, spent time examining the portfolio, and discussed the code (i.e., logic, code patterns, code structure, language features, libraries) in the portfolio projects. I have also asked about development practices, problem constraints, and alternative solutions, and if and how these influenced the code and their coding decisions.
-
Ask the candidate to study our code base. Not everybody has a software project portfolio. Also, neither of the above approaches may provide the required signals, e.g., the candidate hasn’t done Android programming and our code base is all about Android. In such cases, I have shared our code base (of course, being conscious about IP rights) with the candidate and given her ample amount of time to study it along with opportunities to contact my team or me with questions about the code base. Subsequently, I have discussed the code with the candidate to gauge her understanding of both the code and the system at large.
While this approach cannot directly assess coding skills, it can help assess a candidate’s willingness and ability to read and understand code; specifically, other’s code. It can also help assess a candidate’s ability to reason about and have intelligent conversations about existing systems. Candidates with these skills can easily hone their coding skills (provided they are open to learning new things).
Looking back, the above approaches have worked well for me :)
What about take-home coding assignments?
While I have not given take-home coding assignments, I like this practice as it allows candidates to demonstrate their development skills as they would on the job by using commonly used tools and information sources. However, for this to be effective, the interviewer should examine the candidate’s solution. If the solution is good enough, then she should discuss it with the candidate as part of the interview.
On a related note, here are the basic skills that I think are necessary to be a good software engineer.
Originally posted on Medium
Top comments (6)
The first question I would ask is
Of course we all know how horrible it is to make a mistake. And a horrible mistake for a company would be to hire people with the wrong skill set. That said, it seems the worst mistake ever if a software company hires people which can not program. That leads some of them to the conclusion that it might be a good idea to test whether there future employees are skilled in what they pretend to be. But I see a problem here. For one: The assumption is that you have already hired skilled programmers and not only are they skilled in such a way that they can do the coding for you; but you need them to be skilled enough that they are able to give qualified feedback not only on the code of other people but perhaps seeing potential in programming practice.
The next thing is: even when you have such valuable people which are able to judge others and hopefuly seeing their talent there are the average programmers which are hard to classify. While it might be easy to spot the geniusses during an interview; there is a big downside to geniusses: there aren't many of them. Say your company is in a mid size town and there are several software companies besides yours, chances are high, that you end up not getting all the geniusses.
But how to discern the average with potential from the average without potential? This is really hard. Finding those who can not code may be as easy as finding the geniusses. But to spot people who can not code you do not necessarily have to do coding exercises. Most of the time, I would argue, it is sufficient to talk with them for half an hour to see if someone has ever written a line of code.
That said. Even if you are a software company and have some kind of spidey sensors to detect the coding skill level of people the next question which comes to my mind is: Is it really smart to look for actual coding skills? Aren't other skills not more important like being a good teamplayer or being a good communicator or being good at picking new stuff up. So even if you hire unskilled programmers maybe you see potential in them and know that they may be part of a good team where each member compensates for the gaps of knowledge of others and each of one has the back of others.
I find for the average company are coding interviews way too overrated. I understand the fear of making wrong investments.
Thx for your post, here is another related thought:
We have been doing a 15 minutes max low level coding exercise in the language and tools of choice of the candidate very early in a lengthy process to "filter" candidates that don't have basic coding skills. And even though we encouraged the candidates to use all the sources and ask any questions they like to solve it, it did filter out people with bachelor degrees.
This way we didn't spend time for a two hours pairing session that most likely wouldn't have led to anything.
That being said we are currently trying to simplify/shorten/improve our interview process...
I agree this could work as well. However, IME I am yet to come across a CS major or a Software tinkerer who couldn't code.
A possibly related point is coding != programming. I view coding as the ability to express an abstract solution (aka pseudo code of algo+data structure) in code while programming as the ability to work up the abstract solution and then coding it. With this view, testing for coding skills can be separated from testing for programming skills; this will help interviews be more focused and quick.
No, I haven't considered coding with them. Here's the reason why. To me, coding is about being able to elegantly express an abstract solution in code; this is different from programming IMO. This depends on the fluency in a language. (What if the interviewer and interviewee have a common language? Can you program in Groovy? ;)) I believe such fluency can be acquired with curiosity, a bit of hard work, and transferring concepts from one language to another. So, I test for problem solving and approach to problem solving in in-person interviews, which will cover the above aspects.
Do I code with my team, review their code, and have them review mine? Yes.
One of these days I will have candidates play SpaceChem (or something similar).
Yeah, live coding interview can be great. Whiteboard coding exercises as well.