A Guy With An Idea

I feel interviewing is one of the biggest challenges that anyone in a management position is going to undertake.  Getting the right people on board is paramount.  And getting it wrong can have disastrous effects on an early-stage company.

At the beginning of my career I made the mistake of hiring people I liked, believing that “culture” was the most important goal.  In the middle of my career I focused on hiring for talent – only to find out that really brilliant developers who do not play well with others are a drag on the entire team.   Now my philosophy is a bit more nuanced.   I’ve done roughly 70 developer interviews in the past 6 months and the pattern between good developer and great developer (and team mates) has become much more clear to me.

So  – and because you asked, N.  – here is my list of what makes for a great interview.  In my experience, this more-often-than-not leads to making great hires.

For the Interviewee:

Be On Time:  This is just generally good life advice.  But for an interview it’s a no-brainer.  You’re being evaluated on (among other things) how trustworthy you are as a person.  If you can’t be trusted to show up on time to your own job interview how can your team trust you to deliver code when you say you will?

Be Honest: I know, I know.  We’ve all been in that position where the interviewer asks us: “So, tell me what you know about [shiny new technology]?”  We may have read all the specs.  We may have even installed [shiny new technology] on our boxes and built a Hello World app with it.  But unless you’ve built a production grade app with the tech and have deployed it to production and know the 17 different ways it breaks under load, do not pretend to have real world experience.

You have to assume that the question is being asked because, either, (1) the interviewer knows the tech very well and is level-setting you against their knowledge, or (2) they have a problem with this tech and are wondering if you’re the person to hire to come fix their problems.  Either way, being less than honest about your experience is only going to come back and bite you.  Do you really want the first month of your new job to be you getting called at 2AM every day to fix the problem with the tech you’re supposedly the expert on?

Be honest.  It’s really OK to say: “Great question!  I’ve read all the docs I can find on this tech and am really excited to learn more about it.  But so far I’ve only been able to build a simple little game app that me and my friends play with on the weekend.  I’d really like to learn more, though.  Do you use this tech here?”

Be Curious / Be Passionate:  The best developers in my experience are passionate people who are very curious about how things work.  The great ones I know have passion projects they use to teach themselves what they can’t learn in their day jobs.  I’m not saying you have to spend all of your free-time coding side-projects to stand a chance during an interview.  But you do need to have curiosities that support keeping you at the top of your game.

I think about professional athletes.  The great ones don’t just think about honing their craft when at team practices or games.  They’re at the gym in their off-time working to strengthen their weak areas.  They’re experimenting with diet and sleep patterns.  They’re paying attention to what’s happening in their industry and working to make it better.  They’re engaged – mentally and physically in the world around them.  Most of the best devs I’ve worked with have passions outside of development.  These passions have a way of finding their way back into making them better at their job.

The developer who spends his free time building intricate scaled models of ships from around the world has an eye for detail in code that is enviable.   The UX Designer who sketches in her journals every day has developed over the years a truly unique design style – one with soul -  that can’t be matched by her peers.  At the end of the day, you have to care deeply about something.  Make sure this comes across.  Curiosity and passion are contagious.

Be Yourself: Be authentic in every possible way.  Let that freak-flag fly!

If you’re the woman who takes out her nose-ring and covers up her arm tats when you go to a job interview – stop doing that!  If the hiring manager has a problem with who you are when conducting the interview, it’s only going to get worse if you’re actually reporting to that person daily.   In this regard, interviewing is a lot like dating.  Be who you are right from the start and good things can happen.  Hide who you are in the beginning then you have to maintain the facade, or plan for the big reveal, and why go through this?

If you’re the kind of guy who hangs out each day in a pair of shorts, flip-flops, and a ratty Napalm Death shirt you bought at their first concert – you should really rethink your decision to force yourself into a tie and a pair of slacks so you can apply to a Fortune 500 IT department.   Find your tribe.  Find the company that matches your vibe and share your vibe with them.  No job is worth sacrificing who you are just for a paycheck.

For the Interviewer:

Don’t Be an Asshole:  We all know, you’re a very busy and important person.  But these candidates are seeing you and your company for the first time during what is, for most of them, a very stressful situation.  Do you really want them leaving the interview and telling all their friends “I think I aced their technical questions – but, man – that manager is a real dick.  I don’t think I could ever work there.”

You are the face of the company in these situations.  Treat every candidate like you would treat a customer (or an investor, or a board member).

One of my first developer jobs I interviewed with a senior developer who (apparently) felt it was beneath him to conduct a junior dev interview.  The entire interview was a series of me answering his questions and he giving condescending (almost bored) responses.  I was offered the job but declined it.  And around 5 years later I was on the hiring loop at a different company when he applied for a position there.  A brief conversation with my manager later and his application was trashed.  I don’t know how many other doors this guy’s attitude closed for him in his career.  Always be playing the long game.

Ask Smart, Not Tricky Questions: We all have our favorite interview questions.  Whether it’s about when to use a Merge Sort for Linked Lists, or how best to find linked nodes in a Depth First Graph Traversal, there are questions that are go-to’s and we drag them out every interview.  They make us look smart as interviewers and make candidates sweat.

Should we even be asking these questions?  I haven’t had a strong need for a merge sort in about 10 years.  Not because it’s not a legitimate tool in the toolbox, but because the nature of the apps I’ve been building simply don’t have a production-based need for it.  It’s sort of like asking if a person has strong fax machine skills in the age of Slack.

An interview should be about can this person do this job at this time?  If not, can they learn quickly?  Are they adaptable?  In the world of startups, we rarely know what our application(s) will look like 6 months or 6 years from now.  We need to be flexible, adaptable, and above all capable of learning what we don’t know so we can get to where we need to go – and quickly.

I like to ask questions that start simply (What was the last difficult thing you built where you had to learn something new to build it?) and progressively dive deeper to get an understanding of how much the candidate relied upon their current knowledge vs. how much they had to teach themselves to get to a solution.  Questions like: Why did you make that choice? or How did you analyze the pros/cons of the different approaches? or What was your contingency plan if this didn’t work? will tell me much more abut the capabilities of the candidate than whether or not they know how to traverse a graph without first referencing Stack Overflow.

Look for People Who Don’t Look Like Your Own Reflection: In dating, we have a natural tendency to go for people who remind us of ourselves.  This subconscious DNA sniffing may have biologically-based reasons that lend themselves to propagation of the species.   But this built-in bias is a recipe for disaster when it comes to building a team.  Homogeny breeds narrow thinking.  And narrow thinking leads to sub-optimal technical solutions.  And sub-optimal technical solutions lead to poor products.  Etc., ad infinitum.

Teams need to reflect the community at large.  They should reflect the ideals of the company and what the company as a culture holds dear.  Ideally, they should reflect your current (or anticipated) user base.

Protect the Culture – Always: Highly effective teams are a lot like cults (the good ones).  People want to belong; they want to be a part of the experience.   Members feel they are involved in something bigger than themselves, while at the same time feeling that the group is dependent upon them to be successful.  They have a direct and tangible impact on the team.   They want to make the team better and dive-in to do their part to move the group forward.

Don’t take this for granted.  And for God’s sake, don’t fuck it up by putting someone without the same deep ethos onto the team just because you feel you need a butt in a seat to get product pushed out faster.  People who are not a good cultural fit act like a cancer on the organization, destroying in weeks what may have taken months or years to build up.  No product ship date is worth the damage that the wrong person on the right team can bring.

So, how do you know if they’re a good cultural fit?  There are no right answers, honestly, but here are 3 I always ask to level-set expectations:

1. Does this person pass the Don’t be an Asshole test?  It’s pretty simple.  They take responsibility for their mistakes, they don’t blame others, and they lend a hand – even if they don’t necessarily know how.
2. What will this person be doing – and does the team agree that this is a gap needing to be filled?  Most culture clashes, in my experience, are less about personality (if they’re not an asshole) and more about people feeling like their toes are being stepped on.
3. Can I see myself doing to karaoke with this person?  It doesn’t have to be karaoke.  But pick something where you typically feel vulnerable doing it and ask yourself if you can see this person stepping in to cover your back in that situation.  Because that’s what teams do.  They cover each other’s back.

In Summary:

Actually, I don’t have too much more to add.  Building great teams is hard work but worth every minute of it.  If done well, magic can happen.