There was no strategy. I took a small job on Fiverr, it turned into a bigger one, and the bigger one turned into working full-time on a CRM for a company I'd never have found otherwise.
That's the whole path. But a few parts of it were less obvious than they look.
Small gigs are auditions
The Fiverr project was tiny. Not a portfolio piece, not something I'd have listed anywhere.
It was also the only thing that mattered, because a client who has already paid you a small amount and had it go fine is the cheapest possible way for them to find out whether you're worth a real contract. Nobody hands an unknown developer a full-time engagement. They hand you something small enough that being wrong is survivable.
So the question isn't how to win the big project. It's what happens after the small one.
What actually got me hired
Not my portfolio. I think it was the live coding assessment.
Screen share, my own machine, code being written while someone watched. And the thing that seemed to land wasn't the code itself — it was that I moved through it quickly. Knowing my way around my own setup, finding the file, switching tabs, not fumbling for the terminal.
Which sounds trivial and isn't. Anyone can polish a repo before an interview. You can't fake being fluent in your own environment while someone watches, and it's a reasonable proxy for how you'll actually work on a Tuesday afternoon.
The other half was talking. Not small talk — being able to describe my own past projects properly. What the thing was for, what I chose and why, what broke and what I did about it.
That's a separate skill from building, and a lot of developers who can build are bad at it. They either list technologies, or they narrate every detail with no sense of what the listener needs. Both leave the interviewer unable to tell whether you understood the problem or just finished the ticket.
Being able to walk someone through a decision you made two years ago, and defend it, is most of what a client is buying. They can't inspect your code. They can listen to how you think about it.
If you're preparing for a live coding round: spend less time rehearsing algorithm questions and more time being genuinely fast in your own editor — and more time still being able to explain, out loud, why your last project is built the way it is.
The part that ended it
Timezone.
I work 10am to 6pm. The CEO expected me around at midnight. The work itself was manageable — semi-complex, nothing I couldn't handle — but the schedule wasn't a detail to solve, it was the shape of the job.
I lasted a year.
I don't think that was anyone behaving badly. It's what happens when nobody names the overlap expectation before the contract starts, and both sides quietly assume their own normal is the default. The technical fit was fine. The hours were the thing, and hours are what you actually live in.
The second time
The next role came through LinkedIn. Interview, assessment, contract — same shape as before, and the assessment mattered the same way.
What's different is the arrangement. Eight to five, no weekends, and both US and European holidays are observed. That last part sounds minor and isn't: it means the calendar was actually thought about rather than left to whoever's timezone happened to dominate.
The work is comparable in difficulty to what I was doing before. The difference isn't the code. It's that the hours were defined instead of assumed.
My take
Three things I'd tell someone starting from here.
Take the small job. It's not beneath you, it's the interview.
Get fluent at explaining your own past work out loud. It's a separate skill from building, and it's the one being tested when someone asks about a project from two years ago.
And settle the overlap hours before anything else. Rate, stack and scope are all negotiable later. Whether you're expected online at midnight is not — and it's the thing that decides whether you're still there in a year.