Rounding Out January: Post-AWS Exam, and Restarting the Year
25 January 2026 — Post #2
This one is a bit late. I’ve been busy and no, it didn’t take me three weeks to write because I failed my AWS exam and my tears made it hard to find the keyboard. I passed. First attempt. You’re welcome to verify that on Credly.
Since getting my certification, I've had the opportunity to get involved with some more technical projects at work, and also happened to be having a conversation with a friend who recently broke into IT as a second career - so that’s what this post is about, especially as this is the time of year that has everyone thinking "new year, new me... new job?".
What follows is a reflection on interview questions, how I’ve been approaching them, and how the AWS certification prep has been more useful in that process than I anticipated. This is aimed squarely at people going for their first non-entry level IT role, so it’s deliberately lighter on hard technical depth and heavier on approach and mindset.
On Getting to the Interview
I’ll be upfront: I can’t help you get the interview in the first place. With AI-generated applications going up against AI-powered screening tools, breaking through that initial layer is largely a numbers game at the moment. But once you’re in the room — or on the call — there are a few frames I’ve found genuinely useful.
Strengths and Weaknesses
The classic. Two things worth keeping in mind here. First, nobody wants to hear that your greatest weakness is perfectionism — in 2026 that reads as “I either don’t have weaknesses, or I’m not going to tell you about them.” Second, and equally, they don’t want to hear anything that’s genuinely disqualifying.
What the question is actually asking for is an area you want to develop, and ideally, a credible explanation of how you’re already doing something about it. The format I find works well:
“I don’t have hands-on experience with enterprise systems maintenance yet. However, I’ve been running a home lab as a sandbox environment, I’ve been working toward [certification], and the day-to-day exposure in this role is exactly the kind of thing that will help me close that gap quickly.”
You haven’t admitted to anything embarrassing. You’ve shown self-awareness about where the gap is, demonstrated that you’re already doing something about it independently, and implied that hiring you is actually a reasonable bet. Interviewers going for a junior-to-mid infrastructure should hire knowing you won’t arrive fully formed, what they’re trying to assess is whether you’re the kind of person who will get there.
Tell Me About a Time You Dealt With a Difficult Customer
I know what you’re thinking: “I’m going to be working with servers, not people, that’s what the helpdesk is for.” It's worth disabusing yourself of this fairly quickly.
At the end of every infrastructure incident, there are people who can’t work. That’s either one very important person, or a lot of moderately important people... all of whom are now bothering someone important who wants to know when it’s going to be fixed. The further you move from the front line, the wider the business awareness you’re expected to have, and the customer impact runs through all of it.
The thing that will set you apart from peers who are purely technically focused is a genuine appreciation of the fact that the end user’s job is not to fix IT, and without them, yours wouldn’t exist. If you can articulate that in an interview, and back it up with a real example, you’ll stand out. Management notices the people who understand this.
Technical Questions
For a first infrastructure role, nobody expects you to walk in and triage a complex P1 on day one. What they’re looking for is a combination of conceptual systems knowledge and methodical troubleshooting, the kind that’s been tested and refined through first and second line support.
Show that you understand the shape of the organisation’s infrastructure, even at a high level, and then demonstrate how you’d approach a problem systematically. Step-by-step, process of elimination, thinking out loud. The actual answer matters less than showing how you get there.
This is also where the AWS certification prep has been more useful than I expected. Working through architectural scenarios, especially the habit of asking “why is this wrong” as much as “why is this right” builds exactly the kind of systems thinking that translates well to technical interview questions, even when the specific technology isn’t AWS.
A Note on Where This is All Heading
The AWS exam is done. The next post will get into the actual project; The mood tracking web app that I initially planned for this blog about, and what building it is starting to look like in practice.
January has been a slightly strange month to try and restart things in as ever. But it’s moving.
Until next time.
— Matt