Services | Coding Interview

When hiring software engineers, organizations need to assess each candidate’s problem solving, design, and implementation abilities while also getting a feel for how s/he might fit into the team and the organization’s overall culture.  Early in an organization’s history, each hiring decision may represent the organization’s ultimate success or failure.

Organizations try to do all this in a number of different ways, many of which end up testing things that don’t really matter and that may be perceived by candidates as irrelevant and even as annoying or insulting.  This is a crucial phase where inadvertent miscommunication can lose valuable talent.

It’s important to be clear by keeping the most important things front and center.

My tests are administered online and typically consist of a set of carefully written instructions describing a business scenario.  Then I ask the candidate to use a simple diagramming tool to create a simple entity-relationship diagram (ERD) representing the important business entities described in the scenario and how they relate to and depend on each other.  Finally, I ask the candidate to create code that addresses the scenario.

I don’t like in-person whiteboard tests, and I’ve never met a technologist who does.  Face-to-face discussions about problem solving too often tend to devolve into vocabulary or obscure coding syntax trivia tests, neither of which is really a meaningful test of problem-solving ability.

• Reading and comprehending the instructions, however, is vitally important since the requirements s/he will be implementing will be delivered in written form as user stories, etc.
• A clear and correct diagram based on the scenario described in the instructions shows me that s/he can reason abstractly, identifying and beginning to develop the entities, their important attributes, and how they relate.
• And code that is well structured with descriptively-named variables and methods and commented to provide context and/or insight into the engineer’s thought process that I would not otherwise be able to understand from the code indicates that s/he is aware of her/his audience and possess enough empathy and long-term concern to ensure that others can understand and perhaps maintain or extend the code in the future.
• Performing all work that might result in a runtime exception inside a try/catch block illustrates that s/he has developed and ingrained good coding habits that aren’t abandoned even under the time pressure of a test.

Many years ago, I interviewed a candidate for a junior software developer role.  She struggled with the coding portion of the test and asked permission to take the test home, finish it overnight, and come back the next day with her solution.  No one had ever asked to do this before, and the role was new to our organization, so I said yes.

The next day I was extremely impressed with the work she had done, but she admitted guiltily that she had looked up examples in books.  Note: This was long before Stack Overflow and coding examples jammed the Internet.

I asked her to walk back down the hallway leading to my office, looking into each office.  When she returned, I asked her what she’d seen.  “A lot of books“, she said.  “Any of them open?” I asked.  “All of them“, she said.  Yup.  I hired her on the spot.  She’s gone on to a very successful career because she understood that knowing the answer is not nearly as important as really understanding the question or the goal and being able to deliver the best answer.

Isn’t this the kind of person you’d prefer to add to your team?

Let’s find these spectacular people and fill your organization with talent who can help to find and deliver the answers that you and your customers need!