For reasons outside the scope of this post, I am putting the feelers out there to explore the market.

My last interview was back in November 2023, which in this day and age can be appropriately measured by available LLM models: Claude 2.1, GPT 4-Turbo and Gemini 1.0 Pro. Yes, that long ago.

As Seneca says, "Luck is where opportunity meets preparation". This post covers my attempt to reconcile previous approaches to software interviews alongside any tidbits of information I can find from my network and beyond.

I will be covering resources around the following topics:

Given the scope of software engineering, there is no point in pretending there is a one-size-fits-all scope.

Instead, this post is more of an anchor that links out where appropriate and gives my two cents (it is my blog after all).

Before going any further, there is a quote from a tweet that I have been thinking about a lot:

In this day and age, this hits hard.

AI is tool to be used, but it can be a slippery slope. You need to best be able to determine when the use and costs are a net win and have the discipline of when to say no.

My current mindset: there is a place for delegating, vibe coding and multitasking, but it is your responsibility to be aware of the where and when. When it comes to guiding AI for anything mission critical, you need to be the driver. Don't slip into the habit of spinning the poker machine.

We will touch on AI a bit more later, but I think addressing the elephant in the room early is an appropriate starting point.

TrueUp is a great companion on our search to understand the job market. It scans the tech job market in realtime and provides a trends section.

Some of the positive notes (from the time of writing):

Although it's from 2025, The Pragmatic Engineer's blog post State of the software engineering job market in 2025, part 1, what the data says provides some insightful bonus graphs on job available by senority and the type of company.

Without spoiling too much, it looks positive for the entry-level and mid-tier job market.

More specifically within my market (the Australian market), a useful pulse check is the Government Jobs and Skills data on software engineers website.

The latest data here from April 6th, 2026 indicates that in Australia there are 55,200 employed software engineers.

Based on TrueUp's data, there looks to be around 663 software engineer jobs advertised, which would indicate ~1% of the total employed work force.

As a not-very-science-y pulse check on LinkedIn for software engineering jobs in Australia, I paginated through ~34 pages of 20 jobs each (680) and they all still had "engineer" in the title. Make of that what you will (I will come back with a better approach when I get a free moment in future).

All-in-all, if you have come here fearing doom-and-gloom then fear not my friends. Our time is coming again!

As for finding available jobs, here is a list of potential job search websites (in no particular order):

Some colleagues also shared some sites:

A list of Australian-specific options:

If you are interested in specific companies, then I also recommend going straight to their own advertised jobs board.

If you are open to any jobs and don't mind someone coming to you with options, chat to a recruiter.

In my general experience, the bulk of the interviews you will do are this:

Depending on the your field of engineering (e.g. if you are a solution's engineer), you may find some variance but these have been at the core of my experience.

This looks to be aligned with the Tech Interview Handbook, a guide that I came across which has a walkthrough on interview preparation.

The link also contains some really good links to courses and preparation tools, but my own personal comments on that link from my own experience:

It also recommends a coding interview study plan of 11 hours a week for three months. In my honest opinion, that feels overkill (assuming this is not your first time with preparation).

What I would do before committing to a timeline is look for feedback on the existing interview processes of the jobs you are interested in and then narrow down what you need to be prepped for.

An example: In Australia, one job link shared with me was a role as a Software engineer at Macquarie Group. I'm not personally interested in this role, but assuming I am then I generally do a few things:

As an example (from the above three links), I can grok the follow for mid-level software engineers:

Understanding this process goes a long way to getting a better idea about the process prior to your initial contact.

Technical interviews

My honest experience with technical interviews is this: if I grok the question and can quickly ascertain the correct path to go down, it's normally pretty straight forward. If I don't, it's a massive slog and sometimes a miserable failure.

Few love the idea of writing code under interview conditions, but it is still something best to prepare for.

For Leetcode-style interviews, Algomonster have a "return on investment" style layout for tech interview preparation that reflects a lot of my own experience.

It outlines problem-solving approaches and your likelihood to run into those style questions:

If you are short on time, I recommend at least working through the high ROI problem solving approaches.

Some websites with an array of problems on those topics:

These same websites can also provide varying levels of online content for learning as well.

In addition to the above websites, I've also found ByteByteGo to be a great resource for books that comes with great visual guidelines.

Each of these are paid solutions which come with their own cost. Over the coming weeks I will also likely introduce my own online blog resources to help with some interactive learning.

Most of my personal experience with technical interviews have been fairly straightforward, but you need to be able to ask the right questions and quickly identify which approach to take. There have still been times when I've flunked straightforward questions.

Admittedly, I've never had to do any interviews when I "invert a binary tree" or anything of the sort. Seems impractical to test on but there are horror stories out there.

System design interview

For me, system design interviews feel like my bread and butter. I find them much more practical in my day-to-day work and I find them more intuitive to reason through.

My experience is normally to follow my own acronym CASMHDR:

The acronym itself is not something that I've taken from a course. It's just my lightweight go-to approach for something short like system design interviews.

I've personally committed the analogy of "crossing the chasm in high definition" to memory in order to remember the acronym, and so it's something that is always in my back pocket for working through problems.

System design interviews are generally open-ended and are an open discussion with the interviews. Working through clarifying the problem with clear communication (to me) feels like half the battle.

Some resources:

I don't have a table to indicate any return on investment for resources here, but some key topics it is worth getting a high-level overview of at a minimum (based on my experience):

Most of my system design interviews have focused on implementation of high-level systems. There requirements have never been as extreme as what is covered in the system design books and courses I have taken.

My general guideline would be this:

My experience is that there is never really a "right answer". It more of a conversation with the interviewers around what solutions would you suggest to look into based on X requirements.

Behavioral interviews

This one for me has always felt more vague than the others. When most companies ask "why do you want to work for X company?", my honest answer has been "to keep a roof over my head" but that doesn't fly so well.

I find the list of questions on the tech interview handbook website covers basically every question I've ever received.

Some other tidbits from my experiences here:

This is where my experience screeches to a halt. From conversations with peers, some key points that they have mentioned:

Another peer shared through a LinkedIn post on 20 AI fluency interview questions. Some of the slides to me feel a little off but I think understanding some of ubiquitous language used around AI is important for expressing your own experiences with it.

Concepts around agents, memory, harnesses, skills, tools are all key concepts to know, and safely executing agents is another hot topic right now.

If you haven't spent time working with AI, dip your toes in and form your own opinion.

Assuming I am to talk about my use of AI tooling in upcoming interviews, I would probably be honest and just refer to the challenges and benefits I have personally seen.

Some key experiences off the top of my head:

I will update this section in future as I begin the interview process and give some updates on when AI comes into the process.

For this section, I would take anything I say with a grain of salt. I am constantly hounded in my reviews about how my resume looks so you are better off deferring to others on this boat.

Online guides that I will be referencing:

This has been my own guidance to software engineering interviews in 2026 built upon previous experience and my own expectations of what to expect in the upcoming process.

My hope is that there are some nuggets of wisdom embedded within this that can assist in your own search for work.

I will continue to update this page as the process goes on or as I get more feedback from peers. If you have any recommendations that you aren't pushing for your own agenda, send them through and I will update the page.