More on Hiring Software Developers

I wrote a blog post a few months ago about hiring software developers. After which I decided I no longer want to do programming puzzles interviews. I believe the best way to show my skills to a potential employer is to either do a task related to what I would be working on and submit for evaluation, or to work with them for a few days on a actual project.

I’ve recently done an interview that involved a task, and it proved to me that even tasks can be screwed up in a way that shows nothing about the potential hire and does not evaluate their skills in any way.

My task was to request a feed, parse it, and display 3 pieces of information and an image in a list. This task was way too simple to prove anything. Any beginner iOS developer can do this and I thought I would finish it in a maximum of 15 to 20 minutes.

That particular company’s APIs use JSON but they can’t give me access to the APIs, which I do understand. So instead I was given a URL to an RSS feed to work with. While that makes the task a bit harder for me since I never had to parse RSS feeds before, it also makes it even more pointless.

To me it was like going for a driving test, and being told that all I need to do to pass the test is to start the car. That doesn’t prove in any way that I can or cannot drive. To make it even worse, instead of giving me a car, they would give me a truck. Now I need to figure out how to start a truck, to prove that I can drive a car.

I took me 2 hours to figure out how to parse the RSS feed, extract the data I need using regex (since it was all inside a single tag) and present it in a table view.

I ended up being rejected. When I enquired more about the reason I got rejected I was told that it was because of my speed. Again, that is totally pointless. Does completing the task in one hour instead of two prove I’m a better engineer? I would have taken far less time if I worked with RSS before. So was the task’s main goal to test whether I can work with RSS or not? Also pointless, since they don’t need that particular skill (which anyone can learn in a very short time anyway).

I thought that programming puzzles interviews make companies miss out on good engineers because they don’t show their real skills, and that tasks were much better. Turns out you can make tasks dumb enough to do the exact same thing.

Join the discussion below or on Hacker News.

Software Estimates Suck

People suck at estimating how long a task will take. We are often off by a factor of two or more when estimating seemingly simple everyday tasks, like running errands, so imagine how bad we are at estimating complicated tasks like building a new software feature.

Now imagine estimating a set of features instead of just one, or even a whole project upfront. Time estimates in such cases quickly become pointless. The biggest challenge in my opinion about estimating a whole project upfront is that you don’t know the complexity of the problems you are trying to solve until you actually start solving them. Moreover, those problems you are trying to solve never stays the same. Requirements change, problems get more complex and projects often suffer from feature creep.

You’ll be inclined to think that if a task is very similar or identical to a task you have done before, then it’s going to take exactly the same time. You’re wrong. It’s very unlikely that 2 tasks are identical. Chances are the requirements are going to be slightly different, design will change a bit, you’ll be working with different people, etc. These are all things that will increase (or decrease) the time required to finish the task.

One more thing that always make time estimates highly inaccurate is the time needed to fix bugs. You can’t leave that time out, but you also can’t estimate how long it will take to fix bugs you don’t have yet, and there’s no one-size-fits-all time frame that you could assign to bug fixing that would work for all tasks. Sometimes you spend days debugging a single nasty bugs, how could you estimate that kind of stuff?

Moreover, people always ignore the time needed for daily communication. A lot of friction may happen in human interaction, especially if it’s across teams. There is usually misunderstanding and confusion that leads to a lot of delays.

So estimates suck, but they are a necessary evil,  so now what? I like to take Jason Fried’s and David Heinemeier Hansson’s advice from Rework. Never estimate a bulk of tasks. It’s much easier to divide into smaller tasks and put estimates separately. So break the project into many small projects. Your estimates will still be wrong but you’ll be a lot less wrong.

Also, if you’re working in a large development team, you’ll often be surprised at how different estimates from multiple people for the same task could be. My favorite way of dealing with those situations is to play a game, a Planning Poker game. In my opinion, it’s the most efficient way to get people to agree on a reasonable estimate for a single task.

One last thing, never give in to your Pointy-haired Boss‘s request to do the same task in half the time because “you’re a smart engineer, you can do it”. It just doesn’t work that way. While your estimates are probably wrong, they are still your guess of how long it would take to finish that task. No one can simply jump in and ask you to finish in less time, unless they have a very good reason, and of course an arbitrary deadline is never a good reason.

How do you deal with estimates in your team? Let me know in the comment below.

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.

TracKit 1.0

I’ve shipped the first version of my new app, TracKit, today. It’s a little tool that I personally love to use.

iOS Simulator Screen shot Sep 11, 2013 10.27.39 PM

I  love tracking things, lots of things. I might even be guilty of overdoing it. I like to track the number of hours I sleep, how many kilometers I manage to get out of each tank of gas, the time I spend commuting and lots of other stuff. If at this point you think I’m weird then this app is definitely not for you.

The reason I track this kind of stuff is to be able to get a quick overview of how I’m doing at anytime, and try to optimise it. I built an iPad app a long time ago that I used for this purpose, but it was far from perfect, even for my own needs. So I never even thought about releasing it. A few weeks before WWDC when iOS 7 was announced, I was seriously considering building a new version which does the same thing with a few extra features. By the time iOS was first previewed I had already made up my mind and started building it as soon as I was able to download the new SDK after the keynote was finished.

The goal was simple. Build an app that would help me track all the crazy things I like to track, visualise my performance with a graph, and show me stats that would give me a quick overview about how I’m doing with what I’m tracking. And the result was TracKit.

I might be the only crazy person that likes to track things happening in their life, or their might be a lot of other people who also need this app. In either cases, I’ll keep building TracKit until I’m personally satisfied about it. So I have a lot of exciting features planned for the next few months. In the mean time, go get it from the App Store and let me know what you think.


Mobile Operators Spam Has to Stop

If you live in Egypt you have probably received numerous unsolicited commercial advertisements through SMS. This has got to be the worst form of advertising and it has to stop.

You might think that the phone numbers that receive these messages are picked randomly, or through curated lists of phone numbers like what happens with spam email, but it’s much more than that. This service is actually provided by mobile network operators in Egypt. They sell your information to advertisers to send you spam SMS based on your location, the value of you phone bills, your interests – which you are asked about when you open your online account – and other criteria. So advertisers are not only spamming you with unwanted messages, but they are also doing it through the mobile network operators, which you as a subscriber never gave them permission to sell your information or to send you unsolicited promotional SMS.

It’s not like mobile network operators are providing you a free service that they have to somehow cover its cost with an alternative source of revenue. You pay monthly subscription fees and service charges to the mobile network operator and you have the right to demand this to stop. This kind of messages should be opt-in, if they exist at all, and as far as I know there’s currently no way to opt-out of it.

In the United States, EU and Australia SMS spam is criminalised and violators may face substantial costs which has reached up to $175 in some cases for each spam SMS sent. Operators like AT&T, T-Mobile, Verizon and Spring in the US allow you to report any spam SMS you receive by forwarding it to a number. Reported spammers are then disconnected from the network and faced with legal charges.

I can’t see this being criminalised in Egypt anytime soon as the mobile network operators could easily lobby the government out of making such rules and regulations, but at least we should get a way to opt-out of it.

What are your thoughts on SMS spam. Does it really bother you? And what can we do about it? Leave a comment below.


Turns out that on Vodafone you can call customer support and request to be unsubscribed from all the promotional messages and calls sent by Vodafone. This only solves a small part of the problem, but still worth doing.

Not sure if this is available on other networks or not.