Tax, headhunting, then a career break that turned into code

Six months in tax, then a leap of faith

Adrian's first job was in tax. He joined Deloitte, working in transfer pricing, and it took about six months for the truth to settle in. "I think that was when I realised it's not for me," he says. So he took what he calls a leap of faith and joined a friend in headhunting.

The gamble paid off. He did well in recruitment. "Very well, actually," he adds. But after a year and a half, he could see exactly where the road led, and he didn't like it.

The next rung on the ladder was managing people, and that was the problem. "After a certain level of the job, your next step is to lead people. And I thought, if I jump into that next step, I'll be stuck in that place forever." It felt less like a promotion and more like a trap closing.

So he left that too, without a firm plan, and took a short career break. "During that career break I discovered Sigmaschool, and then my coding journey began." Right after graduating from the bootcamp, he got a job in software development.

The recruiter who noticed which team placed the most

The idea of tech didn't come from nowhere. As a headhunter, Adrian had a front-row seat to the hiring market. His firm ran separate teams: one recruited for sales roles, one for accounting, and one for tech.

He noticed which desk was busiest. "The people who headhunted for tech had the bigger sales. They headhunted the most people. I'm like, oh okay, the market is booming, people are constantly finding jobs." There was an aura to it too: "It's a fancy world, right? When you're not in tech and you hear tech, you're like, oh wow."

The timing lined up with a bigger wave. The post-COVID boom in tech jobs was still running, and learning to code online had become popular, especially abroad, so the idea had been sitting at the back of his mind for a while. "Honestly speaking, right place, right time," he says of finding Sigmaschool during his break.

Underneath the timing was a more deliberate calculation about durability. "Anything can use tech. Anything can eventually fall into the tech space. I thought it was a very good way to future-proof my next journey." Whatever he did after this, the skill would still be relevant.

“Be religious in coding. If you don't code for one day, you would know. If you don't code for two days, your boss would know. If you don't code for one week, everybody would know.”

All in, sleeping on top of the blanket

Adrian describes his own working style as obsessive, and it shows up in every chapter of his story. In tax, he was constantly thinking about new transfer pricing policies. In headhunting, he tracked which companies were going through retrenchment and which were newly arrived in Malaysia and hiring.

Tech turned the dial up further. There was so much to absorb that he engineered his own sleep against himself: instead of getting under the covers, he slept on top of his blanket, on top of the mattress, so he wouldn't be too comfortable. That way he could still wake up on time after coding late into the night.

He doesn't present this as a method anyone should copy. But it explains how a tax associate with no technical background could compress a career change into a few months. When he commits, he commits completely.

Your code needs to pass

Ask Adrian why anybody can transition into tech and he answers carefully, from his own lane. He knows how to code; he won't claim to speak for cybersecurity or anything else. But within coding, he thinks the path is open to anyone willing to repeat the work.

His logic is simple. "In order to accomplish anything in coding, your code needs to pass. You can only say you've completed a project once it runs smoothly. So if you have done multiple projects, all your code would have passed, and you would be able to code. It's just repetition."

Anyone who keeps practising will eventually make it in, he says. And he suspects the principle isn't unique to programming: put in enough time and effort, and most skills give way.

Why can't I centre this button

The hardest part of learning to code, for Adrian, was never a particular topic. It was the way an unsolved bug takes over your head. "When you get stuck on something, it's stuck in your head, and you'll forever be thinking about it. In the shower, when you're eating. Why is it breaking? Why can't I centre this button?"

He's honest that this never really went away. "It doesn't change. I think all coders will understand." Sometimes the answer arrives in the shower; sometimes it evaporates the moment you step out and the dog runs past.

His way of coping was a reframe rather than a fix. All that background churn is problem-solving happening in your free time, which is technically good for you. "Think of it as a brain exercise. Just look at it positively."

He also flags the trap on the other side, when the bug finally dies. "The bad part is when it works, you're like, okay, it works, full stop, move on to your next task. When what it's supposed to be is, oh, it works, let me find out why it works. Because that's when you learn."

A weekend, a new language, a job

His job hunt after graduating was, in his words, the most natural thing in the world. He applied online, interviewed at a few companies, and chose the one he liked. It helped that interviews held no fear for him at all.

That confidence was earned in his previous life. "My job required me to prep my own candidates that were represented to my client. Being the one who has taught people how to interview, I felt I could interview quite well." The headhunter had spent a year and a half coaching other people through exactly this moment.

The technical bar was another matter. One company gave him a take-home project: two days, over a weekend, in a programming language he had never used, structured around object-oriented concepts he hadn't worked in. And it wasn't a website; it was a small system to fulfil a contract. He taught himself enough of the language, built it, and that was the job he got.

He credits the format of his training for surviving that weekend. "The work that Sigmaschool gives is mostly hands-on, project-based, instead of theory. Being familiar with working on projects already helped a lot." After three months of being pushed hard, two more days of pushing was just more of the same.

Thrown to the lions

His boss did not ease him in. For his very first assignment as a developer, Adrian was handed a big project. He jokes about the logic of it: "You throw your son to the lions and you hope your son survives." And if he didn't, well, someone was getting fired.

The system itself was a tangle. There was a global database and a global backend in one codebase, a separate codebase that served as a library, another backend that used the global database but lived on its own, a front end for users, and a separate front end for admins. "It's like a very convoluted Venn diagram. Inside this, inside this."

He survived the lions. He implemented every new feature he was asked for and fixed all the bugs, and in the process grew from front-end work into a full-stack role, picking up backend development and PHP along the way. "I successfully completed all that was given to me. I was very proud of myself."

Four days on someone else's bug

The sharpest lesson of his developer job came from legacy code. Part of the system was an old codebase written around 2021 and untouched until 2024, and when something broke, Adrian faced a question with no obvious answer: was the fault in his new code, or in the old code underneath it?

He dug for a full day, then kept digging. Four days in, he finally went to his boss, who happened to be the CTO. "I had to ask the CTO this junior question," he says. The answer came back quickly: the problem wasn't in Adrian's code at all.

Then came the part that stuck. When Adrian admitted he'd been stuck on it for four days, which was why his work was delayed, the CTO was blunt: "Don't spend more than two hours on this." Adrian's reaction was a stunned "what?"

The lesson reshaped how he works. "Some things you need to find out yourself. Some things you need to ask other people, because it saves you time, and also you will never be able to solve them yourself. Finding out the difference is the skill." People do want to help when you ask, he points out; if he'd stayed silent another week, he might have been fired for taking two weeks to solve something that wasn't his bug. The work followed him into sleep, too: he once dreamed about a problem, solved it in the dream, and had his answer the next day.

A manager who knows what an object is

By the time of this interview, Adrian had moved again. He had joined an AI-powered job-search SaaS startup in a project manager and managing role, running the developers, keeping launches on time, and focusing on the product. He has since moved on once more, into career development at Boston Consulting Group.

Learning to code, he says, helps him manage in an indirect way. "When you code, you naturally sort things into categories in your mind. That level of sorting gave me the experience to put people in certain spaces where they can probably achieve more." The mental habit of organising objects became a habit of organising a team.

The direct benefit is more obvious: when his developers talk shop, he can follow. Even the most basic vocabulary matters. He laughs about the alternative, the non-technical project manager who hears "the object isn't working" and asks if they need to buy a new one.

Coding memes and the AI question

Adrian doesn't follow a curated list of industry websites to stay current. His feeds do the work: his phone's news feed is tailored to his interests, tech included, and his YouTube recommendations follow suit. His most reliable source is less orthodox. "I like to look at memes of coding. It just pops up other related news at the same time."

He is genuinely excited about AI, and wants more of it woven into daily life, automating the small things. But on the claim that AI will replace developers, he doesn't hedge. "People who say AI will replace developers don't know how to code, or have never tried using AI to code. Because those who have tried know that the code sucks." You end up recoding everything anyway, and to do that you need to know how to code.

On whether a degree is necessary, he gives what he calls a controversial answer. "A degree is good for, number one, the discipline. To pass your degree you need the discipline to sit down and study for three years and eventually get rewarded. But if you have that discipline without slacking, and you have trust in yourself, then without the degree, I guess it's fine."

He'd recently read a story that summed up his view of skills versus credentials: a hacker who broke into a blockchain network, and instead of prison got community service and a job offer from the company he'd hacked, as their chief security adviser. The market, in the end, pays for what you can do.

Be religious in coding

Asked what he wished he'd known before his interviews, Adrian lands on expectations rather than tactics. The landscape for software developers has shifted in the last two or three years, he says, and newcomers should walk in with their eyes open. Manage your own expectations, and the rest is workable.

His advice for current students is the line he opens the interview with. "Be religious in coding. If you don't code for one day, you would know. If you don't code for two days, your boss would know. If you don't code for one week, everybody would know." The skill fades fastest when you're new, so daily practice isn't optional.

His personal goal is specific: retire before 35, which gives him eight years from the time of the interview. The plan has no tricks in it. "Own more assets. There are no shortcuts in life, right?" Just keep working hard and rising up the ranks.

Looking back at the whole run, from tax to headhunting to code, the interviewer offers the word "hardships" so as not to scare anyone off. Adrian corrects it with a grin: "Sigmaschool tortured me." Three months of it, and it got him exactly where he wanted to go.