How to Freaking Find Great Developers By Having Them Read Code
When hiring developers, there are many things we are looking for, but over the years I have found that raw coding ability is easily the most important quality to look for. I can quickly…
freakingrectangle.com
For most indie hackers, hiring a dev means hiring your first dev, in which case they'll be doing a lot more writing than reading of code. Both skills are crucial, but probably you want your interview to test for the same things this person will actually be doing on the job, which is creating a new product from scratch.
I'm a fan of mini projects. Literally have the dev work with you to build something small. Make it a short-term project, anywhere from a week to a month. Pay them, ofc. This will allow you to preview not only if they can build things quickly, but also how well you communicate and work together as a team. Which is crucial, because your first dev hire is close to being a cofounder.
If you're in a money pinch and don't have the funds to do this, your next best bet is to look at past accomplishments. You want devs who've built substantial products similar to yours, either solo or as part of a very small team.
Fellow indie hackers are ideal, because they'll understand more than just code, but also business considerations. Hiring "big company" devs who've worked at Google etc is a overrated for indie hackers, bc they're absurdly expensive, and bc they rarely have to wear all the hats necessary at an early stage startup.
Imo people are also too afraid of having bad code written early on. I frequently talk to successful founders who are doing rewrites years down the line because their early code was crappy. Stripe had some issues with this, too. My takeaway isn't that you should make sure to have perfect code initially. It's that you can clearly have crappy code from the outset and still build something amazing. So don't stress about this too much before you even have a business that's working.
How "mini" could a valuable mini-project be? I've been experimenting with multi-stage mini-projects that take you through (design -> implementation -> some kind of documentation/code review) within 60-90 minutes. Do you think that's too limited in scope?
The longer the better, for you at least. You'll get a lot more signal. That said, longer projects aren't necessarily great for potential hires, unless you're paying them + they're unemployed and not having to cram work into nights and weekends. So I err toward longer projects, and in fact structuring things as a trial hire period, but I don't do that unless earlier interviews have gone well and the two criteria I mentioned above are true.
That makes sense - my idea revolves around replacing those "earlier interviews" (usually LeetCode, which the author of this piece and I agree sucks) with these mini-projects that have the same time & effort footprint as a normal coding interview, but emit way more useful signals about actual programming and engineering capabilities. I just launched Scenario this week - I would love if you took a look at it!
As a programmer, I appreciate this approach. At least being taken through existing code let's you get an idea of what you're getting into. Also looking at the current open pull requests and closed pull requests to see the standard and speed of delivery is helpful. The truth is that programming often requires much more reading of code than writing of code. Being able to get your head around somebody else’s code salad is essential imo.
Not only that, it's more enjoyable and requires way less of a grind - if you have interviews that look like real software engineering, suddenly the two-track game of both being good at your job and being good at jumping through LC problem-shaped hoops turns into the single (meaningful) track of just being a solid engineer.
I totally agree! If you're a one-man/woman-band and only have one developer, the benefits of doing this might not seem so obvious. But as soon as your tech team constitutes more than ONE person, hiring developers who can decipher the code that someone else has written is super important. You want people/or want to be someone who can think on their feet when faced with fresh code they've never seen before.
Exactly - plus, he mentions "Reading code is probably 95% of what a developer does as part of their job." - it's just a more relevant skill than memorizing what you're going to write. I don't necessarily agree with what he says about:
"Reading puts candidates at ease compared to writing code. As an interviewer, stress is your enemy because it raises adrenaline which lowers IQ by several points, causing you to miss good candidates. " - I don't think reading code is less stressful than having to write it. I think, in the context of an interview, you can prepare for the latter by memorizing. With reading, you might have to read something you've never seen before and explain your reasoning. I think it's more hard core.
I agree re: stress - I don't think it's any more or less stressful to read or write code given that you're going to be assessed on your abilities either way (which is inherently stressful).
I do, however, think that reading code is significantly harder to game (like you mentioned) - if you practice by reading a ton of new/complex code and learning how it works, congratulations - you're just a better developer, and your interviewing skills will improve as a consequence!
This seems way more fun than being asked to write a series of functions out of context. Having to memorize functions Googled for the sake of getting through an interview is not only less interesting for a candidate, but it also doesn't let the potential employer know what a candidate's thought process is. Has anyone had to read code in an interview?
I 100% agree - playing around with some code in a meaningful context (ideally, in a context that looks similar to a company's actual codebase) is not only way more enjoyable as a candidate and as an interviewer, but also significantly more accurate than writing a little solution to a textbook problem. I haven't had to read code in an interview myself, but I have developed a whole interview platform based around this idea (that I will stop posting links to as to avoid spamming) :)
This is an awesome guide! I actually just launched a tech interview platform that pretty much integrates all of the advice/recommendations here. I think consuming existing code is a way more realistic assessment environment than writing any little algorithm from scratch. Check it out here: https://scenario.tech
consider instead having the candidate read existing code and talk about what it does and how it works.
There are a bunch of great ways to assess a candidate's ability to consume existing code: write tests for it; refactor it; debug it; write documentation for it; do a code review on it, etc.
yeah agree. Understanding code proves partly if the developers understand the solutions but to come up to that solution it is another story
I would also add, "make sure they really are into the problem/solution you are working on" It's no coincidence that the best developers are game developers. They live and breathe games. They are really passionate about it. Putting people to do what they really care/like is the best way to ensure great results. Just my humble opinion.
It's for this reason that it's so important that interviews actually reflect your company's codebase - if your interview is incredibly abstract / has nothing to do with your company's products, what utility is it in measuring a candidate's potential contribution to your company?
I do about 1 interview a week, for junior and senior frontend developers (yes the company I work for is expanding the team). I probably helped to hire about 15 people in the last few years.
I came to the same conclusion as the article. I also ask some underlying questions of the code they are reading (why something happens). The interviews didn't start out like this, and we had a big false positive. Right now, their reading code performance during the interview is 100% correlated with how they code on the job.
I really have "absolute" advice like this. Sure, you could find great devs by having them read code...but it depends on many factors.
What if the code is so badly written and this person has been writing a bunch of mini projects from scratch and spent almost no time editing other peoples' code? What if you need these types of mini projects for your own purpose? Then you might accidentally hire an "enterprise-grade" programmer who will over-optimize everything.
I like the gist of the article, though:
"What if the code is so badly written...?"
I think this question points toward the fact that interviews go both ways - if you as a a candidate are being asked to review a code snippet from the company's actual codebase (or at least something similar to what's in the codebase) and it's absolute garbage, you're better off for knowing this and can avoid going further down that road.
Re: someone who spends almost no time editing other people's code - I'm not sure this is a realistic scenario; any serious programmer is going to be engaging with at least the docs of open source projects, if not negotiating source code directly. If a candidate can't read and understand code simply because they haven't written it themselves, that's a huge red flag.