If you're a good developer, at some point someone (likely your boss or co-founder) is going to want to create more of you. And it'll probably be your job to do that. Here's the problem, just because you're an amazing programmer, doesn't mean you have the faintest idea of how to find more amazing programmers. Hiring (not scaling, not architecture, not fundraising) was the hardest skill that I had to learn as a technical leader. And some of my past employees would doubtless agree that I was Not Great At It. My guess is that it’s going to be your biggest challenge too.
If you make a good hire it can change your life; a bad one can sink it. Here’s what I’ve learned over ten years of interviewing:
The interview is your best chance to avoid management
The interview is your first line of defense. If you’re someone like me, the interview can be a very mysterious process. You’ve heard legends about Round Manhole Covers and Whiteboard Binary Trees but you’re not sure how that translates into a successful employee. Here’s how you should think about the interview: It’s your best chance to avoid management.
Good employees will make you feel like you have super powers. Bad hires will make you feel like you’re dragging a tire. They’ll make you read books about management, employment law, performance reviews, and conflict resolution. They’ll tear you away from what you actually need to work on and make you focus on them.
So when you conduct interviews, ask yourself: will this person work for me, or will I end up working for them. Will they make you great or will they make you a manager? Let me be clear: you don’t have time to be a manager. Make sure you aren’t hiring a one-way ticket to just that.
Good first impressions are probably wrong
Let’s mentally picture your first interview:
You’ve put out a job posting, you’ve gathered resumes and picked the ones that look promising. Now you’re in a coffee shop, clutching a notepad, waiting for your subject. You’ve been a little nervous about this interview. You’re an introvert yourself, which is probably why you chose a career that would let you hide behind a computer. Meeting strangers is definitely not something that makes you comfortable--much less meeting strangers to judge their merits. You’ve seen your interviewee on LinkedIn and exchanged some emails but what if they’re a weirdo? What if the conversation has a lot of awkward pauses? “Let’s have a conversation.” you told them. “Conversation”. That’s what you called it. You were too milquetoast to even call it an “Interview”. It felt too formal but what else is this? Every person who walks through the door you mentally compare to the LinkedIn avatar. Then with a little nervous twitch in your stomach, there they are. “Hi.” You extend your hand for a handshake, trying for a firm-but-not-aggressive pressure.
Some time later you’re shaking hands goodbye and this is much more comfortable. You sit back down in your chair and watch them leave the coffee shop and you find that you’re grinning. It ended up being a very pleasant forty minutes. Your interviewee was definitely not a weirdo. They were charming, impeccably dressed, oozing positivity and confidence.You shared some laughs and realized that you both had similar tastes in TV shows and politics. They seemed genuinely interested in everything you had to say. It really did feel like a natural conversation between two peers. They dropped a lot of phrases like “test-driven-development” and “functional programming”. Words appear in your mind “Great Teammate”. You picture them on the “About” page of your website. It seems like they belong there.
Pardon the vivid detail but this has been me during a number of interviews, which led to less-than-stellar hiring decisions. Frankly, it’s the easiest thing in the world to project positive vibes in an interview. Enjoy them while they last because those good vibes vanish quickly if the person is a bad hire. You’ll very quickly be wondering what happened to that charming person sitting across from you in the coffee shop and who is this vampire draining your lifeblood?
If you’re making your first hires, put all your good feelings to the side. Feelings are cheap and they aren’t a good indicator if the person is actually competent.
But I do have one caveat, listen to your bad feelings: If something feels off during your interview, if you had a hard time communicating, if you’re happy when it’s over--pay attention to that. It’s not going to get better. If you have a hard time communicating in an interview, it’s not going to get easier when you’re trying to explain the strategy. If they speak in a condescending tone or become combative, imagine how fun that’s going to be when you’re up late trying to ship a new feature.
So remember mere good first impressions are worthless. Bad first impressions are much more significant.
Conduct a live coding test
Maybe the idea of a live coding-test feels a bit heavy handed, a little bit awkward? Shove these feelings away and embrace your inner jerk. A live coding test is essential to making a good hiring decision.
My recommendation is to start your interview with the ice-breaking, conversational stuff to put you both at ease but quickly move into the coding test. What I really want to see when I do a coding test is what sort of programmer I’m sitting next to. Here’s my suggestions for conducting a coding test that yields real insights:
- Inform them ahead of time that you’re going to do a live coding exercise and give them an idea of what it will involve (front-end, back-end, algorithmic). Let them use their own laptop and editor.
- Test with real problems. If you aren’t doing a lot of algorithmic programming, don’t have them whiteboard an algorithm. The goal isn’t to have the programmer who can quickly recall their computer science coursework. It’s to find someone who can help you be Great At One Thing.
- Allow them to use the internet for reference. Honestly, I can’t imagine why you wouldn’t want to do this. Do you intend to force your team to code from memory? Then why act like this is important in the interview?
- Pick three problems for them to solve. Here’s a real set of tests from a session interviews that we did hiring javascript developers: https://codepen.io/collection/nkwJkb/ They range from simple to difficult. I wanted the first test to something that even a decent junior javascript developer would be able to solve. (You’d be shocked at how many got stuck on problem one.) After each test was complete, we’d review the results and talk about their decisions together.
An example task from an interview session:
/*
1. Load all of the URLs and detect their HTTP response code.
2. When they are all done report back to the interface how many of the functions succeeded and how many responded with status code that wasn't 200.
*/
const urlsToLoad = ["http://codsepen.io/jobs", "/about", "/spark", "http://codsepen.io//nothing-here-to-load"];
These are just suggestions. Maybe you don’t like them, maybe you do. But no matter what, just make sure that a live coding test is part of your interview. Watching how a developer solves a single problem is invaluable. You will save yourself from terrible hiring nightmares the second you start this practice.
Date before you marry
In highly-competitive environments, where engineering talent is scarce this might be hard to pull off but I recommend starting your employment relationship with a contract project. Pick a short project (six weeks, maximum) and see how they perform. Pay them a good rate. The goal isn’t to get cheap labor, it’s to make sure that they’re a good long-term decision.
After the contract is over, assess their work very carefully. Programmers are not static creatures, they will improve over time and add new skills, but don’t expect miracles if the project didn’t go well. If you had to jump in and get them unstuck at any point, that should be a deal-breaker. Difficulty communicating requirements should also be serious red flags. But in the best case scenario you should be able to proceed to full-time employment with high confidence that you’re making a great decision.
Interviewing, hiring is an art not a science, which may irk us technical founders, but there are principles and practices that will help you make good decisions and keep you from disaster. Invest time and energy in your hiring process. Don’t wing it. It’s worth the extra upfront work to find those ideal engineers who will help you be better than you could be on your own.
My name's Levi Nunnink. I've previously co-founded two tech startups and I'm working on a third. If you want to follow along with me as I build a static web host for creative people, sign up for the Wünderbucket beta. Let me know that you're from the dev.to community and I'll be sure to put you to the front of the line.
Photo by: Charles 🇵🇭
Top comments (0)