Why the founder of Rails automatically rejects 80% of Software Engineer applicants
I recently sat down with David Heinemeier Hansson to ask him why he hired certain Software Engineers over others.
If you don’t know him, David is the founder of Ruby on Rails and CTO of Basecamp.
His answers outright shocked me.
Not because of the methods he uses, but because of the mistakes 80% of applicants make that automatically cuts them out of the pool.
The remaining 20% gets cut for reasons that are even more shocking.
(I know 80+20 is 100%. I’m rounding up assuming 1 person out of 150+ gets accepted)
The good news? These mistakes are easily avoidable once you know about them. This means you can easily get through the first 2 steps of Basecamp’s hiring process (for Software Engineers, at least).
Sure, the third and last step is more challenging (as you’ll see), but you drastically increase your odds if you get past the first 2 steps.
I had to write this article, because it almost feels like I have insider information that could give me an advantage over the majority of other applicants.
Sharing information is my mission for ScaleYourCode in the first place — to give you access to information from experts, no matter where you live or what your financial means are.
Let’s get to it.
Resume and Cover Letter — 80% fail this
I’m sure you’ve seen a ton of resume and cover letter advice on the internet.
Yet, 80% of people get cut out of the selection process just because of their resume and cover letter. So obviously, this still needs to be mentioned.
The crazy part is that I’ve had multiple “technical recruiters” give me advice in the past to “improve my resume”, and their advice is the opposite of what David looks for.
Things like:
- Education should be at the top
- Add your GPA
- List places you’ve worked at in reverse chronological order
If you want a job at Basecamp, that’s not going to cut it.
First of all, David has not found education indicators to be helpful when hiring programmers. The same goes for people who have worked at prestigious firms.
Second of all, none of those things provide actionable information.
“What am I going to use that for? I think resumes in the general sense are pretty worthless when they come to assessing the capabilities of a programmer.”
Before you wave your fists at me and tell me this is wrong because company X wants GPAs listed, or company Y wants education on top, read this next paragraph.
With cover letters, the main reason for rejection comes from the fact that people just send generic resumes. They don’t show an interest in the company itself. The same thing goes for your resume. It needs to be tailored to the company.
How is what you are listing on your resume relevant to the company you are applying for? Do your research on the company and figure out what they are doing, then highlight how your experiences and interests align with that.
Your code looks terrible! — 20% fail this
You can usually make an opinion of someone’s skill after seeing a substantial amount of their work.
- How much does the person care about the presentation of their code?
- How diligent is the person with the quality of their code?
“A lot of people fail that test”
A lot of code is poorly indented, poorly named, and poorly scoped.
They’ve even had people submit files with commented out lines of code!
“They submit a piece of code without cleaning it up. It’s kind of like inviting your prospective employer over to your house and you didn’t fucking even clean up. You had some people over last night and there’s all sorts of crap all over the floor.”
This one really blew my mind. I even tried to make excuses for this by asking if he had just pulled up someone’s GitHub account randomly, but he assured me that these files were submitted to them.
Your Code is Clean, But Not Great
“What do you mean my code isn’t great?”
It’s impossible to answer this question in an email. Think of it like a short story, and the author asks why you think it sucks. You can’t really point to a paragraph, because the entire story doesn’t sound right.
Improve your code.
How bad would I be if I just left it at that ;)?
I would never do that… I’ll just charge you $100 if you want to know what I mean by bad code ;)
Alright, alright, enough joking around…
‘Bad code’ is mostly just basic level stuff, like:
- Having methods that are 15 lines long and do 5 different things
- Tons of global variables
- Poorly named variables
- Poor commenting
So how do you learn and improve your code?
Practice, practice, practice. And read.
David personally recommends Smalltalk: Best Practice Patterns. I recommend Clean Code by Robert C. Martin. Here’s another one: Refactoring: Improving the Design of Existing Code.
A reader also recommended Practical Object-Oriented Design in Ruby by Sandi Metz.
These books are kind of like books that teach you how to write well. They talk about proper naming, and proper composition, for example. This means going through lots of code examples, not just theory.
Bonus: Open Source Contributions
While David emphasized that you do not need to have contributed to open source projects, it can be very beneficial. Not only does it give you extra practice at making your code better, but you also make connections.
Example:
For the last test of their hiring process, Basecamp makes you write code for them. They pay you to work on a side project so they can judge you on your skillset.
Once you go through that process with a number of candidates, it’s very clear who you need to hire. You get to see how they work, think, and solve problems.
Some people, however, have been hired straight from the Rails core group of contributors. This makes sense, because David can easily judge someone’s skills if they’ve contributed to Rails.
Actions to take now
Before you send your resume and cover letter, ask yourself this: How does this information relate to the company/job I’m applying to/for.
Before you show off code to an employer, go through it line by line and clean it up: Have more meaningful names, delete commented out lines of code, leave meaningful comments but don’t overdo it.
To improve your code: Obviously, code more. But don’t just blindly code more…follow standards even if it takes more time and slows you down. Read books like Smalltalk: Best Practice Patterns, Clean Code by Robert C. Martin, Refactoring: Improving the Design of Existing Code.
If you have any other book recommendations, I’d love to hear about them and add them here!
