After settling in London for 3 quarters, I’m happy to announce that I’ve finally landed a software engineering position in the city.

Last year, I decided to leave my previous company and hometown, and moved to London to seek new opportunities. The market, career paths, and software engineering requirements in London are very different from those in Hong Kong. Coupled with the economic downturn, it’s been challenging to find a software engineering job here.

During this period, I spoke with friends in both tech and non-tech industries and discovered that the hiring process for software engineers is much more complicated than for many other roles—even hiring a management consultant seems easier.

1. Applying for a Job

My first job was a graduate role I got through an internal referral, so I had no idea how the job application game worked. In my first week, I naively thought that all job posts on LinkedIn and other job boards were genuinely open. I selected a few and applied, but of course, I was either rejected or ghosted. I later realised that many of these postings were over 30 days old—expired or dummy listings.

In reality, when a software engineer job is posted in LinkedIn, there could be already over 100 applications submitted to the company.

Most companies now use Applicant Tracking Systems (ATS) like Workday. Many claim to use “AI” to screen candidates. Since these companies receive such a high volume of applications, some recruiters may blindly trust the system’s results. As a new immigrant, I didn’t have local academic or employment records on my CV. The ATS likely filtered me out.

2. Recruiter Screen

Most of my 68 applications were either rejected or ghosted at the first stage. Only a handful progressed to the next step.

The recruiter screen is usually a 30-minute conversation to check the candidate’s qualifications. This is typically the first human interaction. Having lived in the UK for nearly a year, I hadn’t had many long conversations in English. These recruiter screens gave me valuable experience in speaking and small talk. I also learned how to acknowledge and respond appropriately during conversations.

I’ve been asked numerous times why I’m now based in London – a question that still comes up whenever I meet new people in the company.

3. Online Assessment (OA)

This is a stage brought many tears and frustrations. Depending on the company, there are various formats. Some send an OA after the recruiter screen. Others issue right after the application submission. A couple of companies even sent pre-OAs before I submitted my applications.

3a. Data Structures & Algorithms (DS&A)

I’ve been working on LeetCode challenges since last June, and had learned most of the basics. I never got an interview FAANG, so I didn’t face any insane multi-dimensional dynamic programming problems.

However, the biggest challenge wasn’t the concept behind the DS&A, but the problem descriptions. Unlike LeetCode, platforms like SHL, Hackajob and HackerRank often present extremely lengthy, complex description. On LeetCode, the text editor focuses only on the function you need to implement. In contrast, the other plaforms often include full files with main() and other boilerplate code. Combined with the wordy instructions, it makes the problem more harder to understand.

My first OA was on SHL with 2 questions and a time limit of 45 minutes. I spent 35 minutes just trying to understand the problem description and inputs. It turned out to be a very basic two-pointer problem, but I only had 10 minutes left to implement and debug. An immediate rejection was received.

Since the OA format differs from LeetCode, I suggest trying all the known platforms beforehand. I spent 4 days familiarising myself with HackerRank before attempting an OA.

For me, LeetCode is for learning; the others are for job-seeking.

3b. Take-home Tasks

Take-home Tasks are controversial. You’re typically asked to build a simple RESTful CRUD app. The requirements seem minimal, but you’ll never know the interviewers’ actual expectations.

Some recommend completing it in 3 hours, while the others give no deadline. Some offer a starter kit, which might not be your usual tools, while others give nothing, requiring you to start from scratch.

None of the take-home tasks I attempted could reasonably be done in 3 hours. The brief was vague, and since you can’t ask for clarification, the definition of done is unclear.

You are applying for a senior role. Should you keep things simple to follow the KISS principle? You might be critised for lacking design patterns. But if you include design patterns, you risk being critised for over-engineering. It’s easy to overthinkg and delay submission.

As someone with minimal frontend experience, one of my take-home tasks required building a full-stack CRUD app. I received a starter kit but was unfamiliar with the tech stack. I ended up spending a week learning from scratch and implemented an React + Java app instead.

Take-home tasks aim to simulate the real-world work. Some may argue that DS&A isn’t relevant to most business contexts. But does building a basic CRUD app reflect daily work either?

Yes, take-home tasks are very consuming. They’re definitely not ideal for those currently working or with a family. As an ex-NEET, I had the time, and I did learn a lot in just two weeks:

• React
• Docker
• GitLab
• Spring Boot upgrade
• springdoc-openapi
• Gradle
• etc.

It’s up to you to accept the challenge. Feel free to withdraw the application if it’s not your dream job.

3c. Other Tests

There could be some other tests like aptitude tests, which I’m not going to cover them. If you’re like me and need to read 30 lines of text to answer 12 questions in 8 minutes, good luck!

4. Hiring Team / Manger Inteviews

The format, again, varies. Some companies break this stage into multiple interview, while others run a single 3-4-hour session.

4a. OA Review and Pairing

Since OAs are asynchronous, candidates may use ChatGPT or Copilot. Reviewing submission tests candidate’s understanding. Sometimes, interview will do pairing with candidates too.

I found DS&A reviews fun and challenging, as the problems aree based on standard concepts. You’d be surprised how creatively some interviewers try to link DS&A back to real-world scenarios.

In contrast, take-home task reviews were tricky. As mentioned before, these are open-ended with unclear expectations. Should you walk the interviewers through every detail like a beginner? Or summarise like facing an expert? The same presentation approach got me an offer at one company and a rejection at another.

4b. Technical Questions + Project Experience + Behavioral Interview

This is a Q&A session with randome topics. Some companies split it into several rounds. I was asked about:

• HTTP status codes
• Try-Catch-Finally
• Concurrency
• Primary/foreign key and database norminalisation
• How I led a product team
• Why I built Mahjong101
• Concern about stepping down from a leadership role to individual contributor (IC)
• Loads of “Tell me about a time when…”
• etc.

It’s important to treat interviews as two-way conversations. You’re not just being assessed – you should also be assessing whether it’s a place you want to work. I often wore my Agile Coach and asked about the company’s challenges to understand their culture and values.

5. System Design

Surprisingly, I never encountered a System Design interview. I spent most of my time on DS&A preparation and take-home tasks, and didn’t have time to prepare System Design interview.

But if I had been asked, I would’ve followed the Delivery Framework in System Design in a Hurry. It would have brought in many good conversations. Interviewers typically want to assess how you approach a problem, rather than actually solving it.

As you can see, getting an offer (or a rejection) often comes down to luck. You may get rejected at any stage for reasons completely unrelated to your performance. For instance:

• It was an internal hire.
• The interviewer had a bad day.
• ATS screening was flawed.
• It was a fake job post.
• There were too many applicants.
• It was a placeholder role.
• The interviewer only accepted one “right” answer.

After each stage, do a mini self-review. Learn from it. Forget the rejections if any.

I dedicated my last 2 months to interview preparation, and I finally finally landed on a role. It was a tough and draining journey, and I hope I wont’t have to repeat it soon. But it also gave me space to reflect.

In technical interviews, I realised how many technical terms I had forgotten – I could only explain the reasoning and actions, not the terminology. Preparing for behavioural questions made me revisit moments from my entire career and reflect deeply on what I might have done differently.

During the period, I paused all other activities: blogging, reading and Go learning. Now it’s time to resume them and continue learning.

That wraps up my 9-months career break.

A new chapter begins.