💋 How to hire actually good engineers

I didn't bother making a Hacker News profile until someone made a comment that was so wrong that I lost it. Thus ending my long tenure as lurker.

Today, someone said that it is bad to ask engineers to bring their own code to an interview. That person is wrong, Internet.

How to conduct a technical interview

1. Tell interviewee to bring code they wrote
2. They share their screen as they talk about it
3. Interviewer will ask casual questions

You can tell a lot about a person’s personality by how they describe their work. Are they enthusiastic? Do they cast blame to others on bad code or practices? Do they gloss over details that are important? Are they defensive? Are they a fraud? You can gleam little hints that will tell you what they actually want.

You get sentiment, ethics, communications. You get to see if they are an asshole, if they are funny.

No interview panel

After 90 minutes of this, you don't need an interview panel. You know the person well enough to make a decision. So make a decision and you're done before lunch.

Lots of companies want to spread the blame of a bad hire across a committee of 4 or 5 people. That is also wrong.

Sometimes you will want to scale hiring, so you can have two rounds in order to train another interviewer. Better yet, let the interviewer interview you and record it for future reference. Now it's part of onboarding. Look at you, smart stuff.

Rarely, you actually are on the fence and you want a second opinion. Do that.

What if the candidate has no code to show

If they don't have code to share for whatever reason, like it is owned by their previous employer or they are fresh out of school with no code to show, pass on them.

Sorry to be blunt, but chances are they aren't very good, and they are definitely not as good as they think they are.

But surely you will miss some really good engineers who don't have any code that they can show you over a zoom call, right?

Yep, you might. I read about this one teenage girl who fell out of an airplane at 30k feet and not only survived the fall but 10 days in the Brazilian rainforest before being rescued. Exceptions are fun.

It's unethical to share code from a previous employer

No one is asking to share an entire codebase, but if you feel strongly about this point, that's fine. You have other code to share?

The code doesn't have to be good or the same tech stack

One of my favorite interviews ever was a person talking about his tmux+vim setup. 90 minutes of pure nerding out. He went on to work with me for 6 years in 3 different companies.

The interviewer needs to ask hard questions

We must go deeper — A movie quote

If you do not know if you want to work with a person after 90 minutes with them, then the interview needs to be done again, wasting everyone's time. The way to get to a conclusion quickly is to ask deep questions quickly in the process.

No. Fluffy. Questions.

Here are some sample questions:

• Let’s start with what the project does. Can you describe the product?
  • Why is that important to the user? Was the project a success? How did you know? What metrics did you look at? Why did you choose the technology you did? Is there anything you could have done better if given more time/money? How long would that take to build? What kind of team would you need to build it?
• Let’s look at the config files. Can you tell me how the project is setup?
  • What does package x do? Why did you choose it? What not build from scratch? How do you manage updates? How do you check for security issues in it? How do you debug it? How can you tell if it’s slowing the app down?
• Let’s look at the database. Walk me through your schema.
  • Why did you choose this data store? What others did your consider? Did you structure your data this way for a reason? Ease of querying? Query number reduction? How do you solve a slow query? How do you move data into a micro service? If I wanted to store pageviews for every page on the site, where would I put it?
• On the front end, let’s chat about your setup.
  • Why did you choose technology X over Y? Tell me about your build process? Does this have a downside? What about for mobile or slower internet speeds? Older browsers? What’s the trade off to polyfills? Describe your preferred component structure. Does this fall apart when you have a team of 10 or more engineers? How do you test?

Don't forget about cultural assessment

Sometimes a conversation doesn't hit all the points. Don't be afraid to step out of the code review and ask culture questions.

Some examples:

• Why do you want to work at Reforge? I’m looking for a glimpse into what really drives you. I’ll tell you my reason to help you understand what I’m looking for. I was the 10th employee at Eventbrite and it gave me Imposter Syndrome, but also a deep love for very early stage companies. I thrive off learning about the users, really nailing product-market fit, and creating something that rapidly increases in value. Back to my Imposter Syndrome, the single biggest cure for it was being able to explain my learnings about Eventbrite and other startups, learnings like frameworks and well-structured thoughts. Reforge epitomizes taking something nebulous and creating something comprehensible. This really resonates with me. Combine that with Reforge being very early stage, and it is basically the perfect company for me. This was my reason when I first joined, but I have so many more reasons to want to work here at Reforge now. My personal goal is to turn it into a $100M company. (Now they answer)

Follow up questions:
- Oh, because of Matt’s recommendation? Why is his rec important to you? What qualities about working with him do you enjoy to make you want to work with him again? Are there other checkboxes on your list that you are looking for? What are they?
- Oh, because of the Reforge reputation? Why does that align with you? Is the reputation a stepping stone for your own personal reputation? Tell me more about your goals.
- What is on your list of things you avoid in a workplace?
- Why does thing X irk you? Do you think that thing X provides any value in the company? Describe a time where you had to handle tough situations where you are forced to deal with thing X?
- What are you looking for in your next role?
- Oh, a team? Oh, to become a leader? Oh, to disrupt education? Oh, to do X? Why is that important to you? Did you have an experience in the past that made you decide this was important? Tell me about it.

This doesn't scale

Large companies don't hire this way because it's hard. They stop when they grow to a large size. They do it because frankly hiring good engineers is no longer the top priority (it's typically quotas AKA butts in seats).

Companies want to standardize their hiring when really they should be looking to customize it to each candidate.

You should be asking, "do we really need to hire?" If you need more than 3-4 engineers per team, you're doing it wrong.

Show the candidate your private parts

If you have time and you are going to extend an offer to them, show them your code. Let them see what they are getting into. Let them interview you. Most of all, let them see you're not a whiteboarding, take-home-test-giving, shitty company.

Having an interview like this lets actually good engineers realize that you aren't going to hire actually not-good engineers, upping your chances of them wanting to work at your company.

Okay, internet. That is all.