Hiring a developer in Algeria without being able to read code

You will not read the code, and you do not need to. What you can judge is the work: what the person shipped last, who uses it, what broke, and what they did about it. A process built on those questions finds a builder faster than any test you cannot grade, and it filters on the thing that matters — whether anyone has ever been responsible for something running.

What do you ask instead of a technical interview?

Ask them to walk you through the last thing they shipped, then follow with three questions no tutorial answers: who uses it, what broke in the first month, what changed because of that.

Someone who has run something in production replies with specifics and volunteers the parts that went badly. Someone who has only followed courses describes the technology and stops. The difference is not knowledge; it is the experience of being the one who gets called.

Then ask what they would do differently today. A vague answer means nobody has thought about it since. A good one names a single decision and its cost — "we stored prices in the app, so every change needed a release". That sentence is worth more than a certificate, because it was paid for.

Which two artefacts beat a CV?

A repository with a readable history, or a system in production that someone can name.

Artefact	What it shows	What it cannot show
A repository	How the work progressed: small steps, messages that explain why	Whether anyone uses it, or whether it holds up
A named system in production	That something survived contact with real users	How much of it was this person's work

A CV lists technologies; both artefacts show judgement instead.

For the repository, ask them to open it and explain one commit that fixed something. Four hundred messages reading "update" tell you about discipline, not skill — but be careful with the inference, because plenty of good developers work in repositories they are not allowed to show. The trial then replaces the artefact.

For the production system, ask for one person who uses it, then ask that person what happens when it breaks.

What does a fair trial look like?

A small paid task, with a written specification and a deadline.

Paid, because an unpaid task selects for people who can afford to work for free, which is not the same population as people who are good. Small, because a task that takes a week is a job, not a trial; an afternoon shows how someone thinks and how they write.

Take a real problem that fits on a page: importing a supplier's price list, or fixing a form that loses entries. Write the specification yourself — the input, the output, what "done" means, the deadline, and how the work is handed over.

Then judge the questions asked before starting, whether the deadline was met or missed early enough to be useful, whether the handover note can be read by someone else, and whether the result does what the spec asked, boring cases included.

What separates a builder from a follower of tutorials?

The questions about failure. Ask what happens when two users edit the same record at the same time, what happens when the connection drops mid-save, where the customer data lives and who can read it, and what happens in two years when a library the project depends on stops being updated.

A builder answers "here is what I would do, and here is where it breaks". A follower answers with a product name and no failure mode.

Then ask them to explain one answer in plain language, because you are the test. A developer who can describe a locking problem to a shop owner in three sentences will not hide behind vocabulary when the project is late.

Finally, ask what they will not do. "I do not do design", "I have never built offline sync" — those answers make a plan possible. A yes to everything makes one impossible.

Which warning signs have nothing to do with skill?

Four, and each is about how the next six months will feel.

• No questions about the business. If they never ask what the shop sells, who enters the data or what happens at month-end, they will build exactly what they were told.
• "Leave it with me, I will handle it." A person who will not explain the plan is asking for trust they have not earned. The plan is the deliverable you can read.
• No written estimate anywhere. Not a price — a shape: what is included, what is excluded, what happens when it changes, and what date. Verbal scope is how a two-week job becomes four months.
• Discomfort at the question of who else can read the code. If the answer is "nobody, it is mine", you have found the single point of failure before signing.

How do you run the process?

1. Write the job as an outcome: what must be true in three months that is not true now.
2. Ask every candidate the same questions, in the same order.
3. Request one artefact — a repository or a named system — and have them walk you through one commit or one incident.
4. Write the trial specification yourself, one page, with the deadline and what "done" means, and pay for the work.
5. Judge the trial on the questions asked, the deadline and the handover note, not on elegance.
6. Settle ownership before work starts: accounts, repository, keys, and what is handed over at the end.
7. Call one reference and ask what it was like when something went wrong.

Where this goes wrong

• The CV is read as evidence. A list of technologies says nothing about whether anything was finished.
• The trial is free and open-ended. Good people decline it, and the ones who accept are being selected for availability.
• The specification lives in a conversation. Two people remember two different tasks, and the trial becomes an argument about scope.
• The person who will write the code never speaks to you. A salesperson answers until the contract is signed.
• A promise replaces an estimate. No document, no date, no list of exclusions, and no way to tell a delay from a disagreement.

What this does not cover

It gives no salary figures and no view on what the market pays: they move by city, sector and month, and a number in an article is stale before it is read. It does not judge diplomas, certificates or training routes, and it is not legal advice on an employment or freelance contract — ownership and exit clauses belong to a lawyer. Nor can it replace a technical reference on a large system. This finds a competent builder for a business system; it does not qualify a specialist for a hard domain.

We build the systems these questions are about, and we will sit in the room while you ask them.