How to Tell If a Developer Knows What They Are Doing

Question One

What tools do you use?

It sounds like small talk. It is not.

You are not checking the answer against a list, because you cannot. You are listening for whether they can explain their choices in language you understand, and whether the reasons are about your problem or about their preferences.

A good answer sounds like: I would use this because it fits what you are doing, and here is the tradeoff. A worse answer is a wall of names with no reasoning attached, or visible irritation at being asked. Someone who cannot explain a tool choice to you now will not explain a delay to you later.

Question Two

What is your most successful project, in your opinion?

The last three words are doing all the work. You are not asking for the biggest budget or the most famous client. You are asking what they are proud of, which tells you what they optimise for when nobody is watching.

Listen for whether they talk about the customer or about themselves. Whether they mention what was hard, or what they got wrong on the way. Whether the thing is still running. Someone whose proudest project is one that quietly still works years later is telling you a great deal.

What Actually Separates People

Being honest about my own position: I am not going to tell you I do better work than everyone else. That claim is unfalsifiable and everybody makes it.

What I think genuinely separates the people who finish from the people who do not is knowing the best practices and applying them, being able to open an unfamiliar codebase and navigate it, and being fluent enough in the terminology, architectures, and harder concepts to make a real decision instead of guessing.

Then being realistic about what a project needs, and driven enough to actually finish it. Most software does not fail because somebody could not write the code. It fails because nobody drove it to done.

A Mistake Of Mine

A client came to me wanting to sell online. I scoped it, quoted it, and built exactly what was quoted. The site worked.

He was unhappy anyway, because he had understood that selling online included his products appearing on Amazon. That was never in the scope, and it had never come up, and I had not thought to raise it.

The fault was mine. Not the build, the expectations. Third party listing sites are each an entirely separate undertaking from having an online store, with their own rules, fees, and feeds. I know that. He had no reason to. I should have said it out loud in the first conversation, when it would have cost nothing.

Now I say the exclusions before the inclusions.

What To Take From That

The most useful thing you can ask any developer, including me, is what is explicitly not included, and what they think is most likely to go wrong.

• Someone experienced has a ready answer, because they have been burned and remember it.
• Someone who says everything is included has not thought it through, and you will meet the gaps later at their hourly rate.
• Someone who admits a past mistake without being asked is usually the safer hire, not the riskier one.

You cannot evaluate the code. You can absolutely evaluate whether somebody is straight with you before there is any money on the table.