Hiring Software Developers

I’ve been reflecting recently on my past few years working as a software developer. During those years I’ve had a lot of job interviews. I got many rejections, a few job offers and never heard back from some companies.

This is a review, from my own perspective, of what works and what doesn’t work when it comes to interviews and hiring processes for software developers.

The Programming Quizzes Interview

In this kind of interview you have to solve ACM kind of problems, brain-teasers, or general Computer Science quizzes. Things like finding the shortest path to traversing a graph. Any good Computer Science fresh graduate will probably be able to go through such interviews with ease. A few years later though you’ll struggle with answering most questions, simply because they have absolutely nothing to do with what you actually do in practice. Can you even remember when was the last time you had to write an algorithm to traverse a graph? Those interviews are the worst as they give absolutely no indication about how good or bad someone is going to be when they get hired.

You Seem Nice, Here’s a Job Offer

No technical interview, no tasks, absolutely nothing. This has actually happened a couple of times with me and they just left me baffled. If that’s how you have picked the rest of the team I will be working with, then thanks, but no thanks, I can’t work for you.

I’m not really sure how some companies decide to hire people entirely based on how nice their CVs look, or based on a short conversation they had. You’d be surprised by how often people make things up in their CVs.

Go Do a Task and Get Back to Us

I have encountered 2 different kinds of tasks that fall under this category. Some companies give you a generic task that they give to all candidates. Those tasks are usually designed to test your understanding about specific parts of the technologies they are using, your coding style, and how scalable and maintainable your code is. I like those kind of tasks as they show my skills in a much better way than answering some stupid questions on the spot.

What’s even better is the second kind. Your task is actual work on one of the company’s projects and your code might be used in production at some point. This not only shows your technical skills more accurately, but also shows how you communicate with the rest of the team, how you approach the problem and understand the logic business behind it. Most companies that do this kind of tasks pay you for it, whether you get accepted or not.

Come Work With Us for a Few Days

Some companies invite you to come work with them for a few days. You don’t have to be at their office 8 hours a day, but you have to show up at least a few hours everyday for 2 to 4 days. I believe this is the best way for a company to get to know candidates and see how they fit with the rest of the team, it’s also great for candidates to know the people they will be working with and see if they are comfortable working together and also get to experience everything about the work environment of the company. The only problem with this is that it’s often hard to do for candidates already working full-time at another company.


If you’re hiring a developer, specially in a startup, I urge you to ditch CVs and traditional interviews. Ask people for their Github accounts. Ask them to tell you about a personal project they have been working on recently. Invite them to come work with you for a few days. Whatever you do just make sure it gives you a meaningful indication about their skills, not how good they are with word processors or solving Computer Science quizzes.

Update: Thanks for the tree vs. graph heads up.

There have been some nice discussion about the article over at Hacker News. Make sure you check it out.

Update 2: Sunil Sadasivan has recently published a very interesting article about the hiring process at Buffer. Check it out on Medium.

9 Things I Learned as a Software Developer

I’ve been working as a software developer for a number of Egyptian tech companies for a little over 3 years, both on full-time basis and as a contractor, and I’ve learned a few lessons that I would like to share here.

I’m not in any way claiming to be an expert or that I’ve got software development demystified, so if you disagree with me please leave a comment and let’s discuss it.

Respect the technology

Your company might not be a software development house, and your main product might not be an app, but if you have an in-house development team, chances are your product relies heavily on technology. So respect the technology and learn to do software development properly. Don’t think that you’ll do just fine if you hire a few mediocre developers and a couple of managers with no technical background whatsoever.

Evaluate work properly

The best software developers aren’t the ones who write the biggest amount of code in the least amount of time. Assessing people by how fast they can get a job done with no consideration to quality is just wrong.

Hire product owners with technical backgrounds

In most companies I have worked with, I’ve seen a major problem with the role of product owners. People with no technical backgrounds struggle with this job. They have completely unrealistic expectations, and in many cases they insist on requirements that are just plain wrong for the technologies being used.

I believe those roles should be played by tech savvy people, preferably software developers who have the qualities needed to be product owners.

Project schedule is determined by the people who build it

A project’s schedule should be determined by people who are going to build it, not by project managers or marketing managers.

“But can’t we do better?”, the project managers will wonder as soon as they hear the developers’ estimates. If you’re working with developers who are really good, they will know how long to takes to finish a task, but they can’t change it, at least without compromising quality or changing the specs.

Trust your team

I know trust is earned not given, but you really can’t distrust people with basic stuff like the fact that will actually do work while working remotely. If you don’t trust me with that, just don’t hire me.

Fire people when you need to

I have never seen anyone get fired. Even people that cannot pull their own weight and it’s obvious to everyone that they are slowing the team down. Those should really be fired.

Fast and good is not cheap

Everyone seems to be ignoring the basic fast/good/cheap rule of software development. You can only maximize two of these while compromising on the third. You want a high quality product and you want it fast? That’s going to cost you a lot of money. You want it fast and cheap? It will be buggy. Of course these aren’t binary switches, and you could always find a balance between the 3, but you just can’t have all three.

Don’t give fake titles

Top managers should not be dictators. Hire good people and let them do their job. Don’t hire people that you use as a tool to turn your commands into code or artwork. Don’t give people fake managerial titles when they have no say whatsoever in decisions related to their work or the work of the people they are supervising.

Don’t expect people to use their own hardware

I can’t believe I actually have to include this, but a few companies believe that you should be using your own personal hardware (computer/phones/tablets) to get their work done. Should I pay my electricity bill too? This is completely unacceptable. If you can’t afford to buy your team the hardware they need, then you can’t afford to hire them. So simply don’t.

Don’t let this post make you think that I have had 3 horrible years in my career. These are just the things I don’t like, and I can’t deny that I have learned a lot at each company I have worked at.