I don't take interns. Not out of principle — out of lifestyle. I like slow mornings, a coffee, a cigarette, and a schedule that answers to nobody. An intern in the room turns that into a workshop, or worse, a school. Someone has to explain things. Someone has to check in. That's not the pace I've built for myself, and for years I've said no to every request that came my way.
This summer I said yes to three at once. Not because I changed my mind about the lifestyle — I didn't — but because friends asked, and they were doing someone else a favor by asking me. I couldn't find a clean way to refuse without sounding petty about it. So I accepted, and immediately decided that if I was going to do this, I wasn't going to do it the way everyone else does.
Why I Don't Usually Do This
The standard internship model is a kid sitting next to a senior, watching him work, occasionally being handed a bug fix. It looks like mentorship. It's mostly babysitting with better optics. The intern learns how one person works, copies a few habits, and leaves without ever having owned a decision.
That model also costs me exactly the thing I protect most — my time and my pace. I wasn't going to trade my mornings for a seat-next-to-me arrangement that barely teaches anything. If three people were going to occupy a room in my office for a summer, they were going to do something that actually mattered — to them, and ideally to a real business.
The Rules I Gave Them
I put all three in one room and laid out the plan on day one:
In software development, we solve problems for businesses. We take a real problem, think through a practical solution, and build something the business will actually use. So that's what they'd do — start to finish, with no senior standing between them and the outcome.
- Go talk to the business owner directly. If he has a problem, collect everything about it yourselves.
- Sit together and come up with a solution — not the first idea, a workable one.
- Build a demo. Present it to the owner. Repeat until everyone agrees on the direction.
- Divide the work however you want. Work together or split it — I don't care.
- Use AI, use Stack Overflow, use whatever you need. Just own the code you ship.
- Track every cost and every hour, day or night, no exceptions.
A timeline without milestones is just a guess. So is a budget nobody tracked. I wanted them to feel both.
The Business: A Driving School
I pointed them to my brother. He runs a driving school, and his real problem is scheduling — lessons, reschedules, and keeping every instructor's calendar in sync without three different people editing three different versions of the truth. It's a genuine problem. It's also not a complex one, which mattered — three interns with no professional experience needed something solvable in a summer, not a system that would still be unfinished in five years.
They went, they talked to him, they came back with real requirements instead of assumptions. That part alone put them ahead of plenty of professionals I've worked with.
What They Actually Learn
Every week we met, and I explained one concept — not from a book, not from a YouTube tutorial, but tied directly to something they'd just hit in the project. Clean coding. System thinking. How to tackle a problem when the requirements change halfway through, because they always do.
You don't learn system thinking from a slide deck. You learn it from watching your own design fall apart and figuring out why.
I also told them, explicitly, that this project is theirs. When the internship ends, they can take it with them. They can finish it, polish it, and sell it to other driving schools if they want. That's not a consolation prize — it's the actual incentive. But I was honest about the condition: for that to be worth anything, it has to look good, function well, and be easy to use. Nobody buys software that only works if you already know how it works.
Where It Stands Today
More than a month in, and it's still early. The task wasn't complex, but three people with no prior professional experience move at a different speed than a team of seniors, and I never expected otherwise. Their expense list keeps growing. The hours keep piling up, some of them well past what a normal workday looks like.
What they're getting in exchange is something no classroom gives you: what it actually feels like to sit across from a client who doesn't know what he wants until you ask the right questions, to be wrong about a solution and have to rebuild it, and to solve problems as they show up instead of the tidy ones printed in a textbook.
The project isn't finished. It doesn't need to be, not yet. What needed to happen already has — three people who'd never built anything real now know what it costs, in time and money, to build something that works.
