Jun 03, 2017

|

by: james

|

Tags: Hiring, Interviewing

|

Categories: Hiring

Interviewing: The SharpEcho Way

Interviewing: The SharpEcho Way

We’ve had a good bit of hiring activity lately and I thought I’d share some thoughts about our process and interviewing in general.  Our process hits across several key points, and while I don’t think we are entirely unique, we do hit on some things that other firms may gloss over.  We’re looking more for talent than specific skillset.  We look for well rounded folks with a strong technical background, good communication skills, and a passion for software development and learning.

People often will ask how we define “strong technical background” and I tell them all the time that to us it doesn’t mean 10+ years working with a specific language or technology.  I’ve interviewed candidates with dozens of years of experience that I would not trust to write “Hello, World!”, and we don’t field many requests to write applications as simple as that!  A strong technical background to us means that someone has a good foundational knowledge of a language and can code his or her way out of any obstacle.  It means having enough intuition to know that there probably is a better way of implementing something but not letting that be the excuse for implementing nothing.

To demonstrate this, we ask candidates to write some code on the whiteboard.  I know there are a lot of people are not fans of this.  In fact, I’ve had more than one person walk out of an interview because of this step.  I attribute it to a poor prior experience with an interviewer that was looking for some proof of something that would probably be better suited with a different exercise.  For us, we want to ask someone to write a simple method that they’ve likely never written before and deprives them of google and intelisense, so they have to fall back on some primitives.  We tell them: “Hey, we know you’ve never written this, but that’s why we ask”.  We want them to ask questions.  We want to collaborate and help them.  It’s an experiment in working together.  Sometimes the experiment fails.  Sometimes they stare at the whiteboard waiting for the optimal solution to hit them.  Sometimes they implement something that clearly shows they don’t understand the problem.  Sometimes they simply can’t write “Hello, World!”.

But, other times we get good solutions, and we get to do some real-time code review and ask them to make their code better, faster, or more maintainable.  Sometimes, we get really great implementations.  Sometimes, we have to throw in another whiteboard question because their code is just that good, it’s suspicious.  And, in both of these cases, that’s when we know we have someone with the technical chops that we are looking for.

This often leads to a spirited discussion about the how’s, why’s, and what’s regarding their code and various technical tradeoffs.  When those conversations get going, we start seeing the other aspects that we are “testing” for: communication and passion.  We can easily spend 15-30 minutes talking about various data structures that might be useful or other ways that we might consider implementing if we were optimizing for speed or space, how various framework level collection classes might be implemented, why one way might be better for a read heavy system versus a write heavy system, design patterns, general principles of software construction.

In short, we can take a 5 minute whiteboard session and have it spread to an hour long discussion that we really enjoy versus a checklist of asking about skills that might not even be material in whatever project we are getting ready to kick off.  That earnest discussion usually reveals a lot about someone – and I think it reveals a lot about us as well — when it’s fun and light, that tells us what we need to know and we hope it tells the candidates “interviewing” us what they need to know, too.