Andrew: For me, projects and hands-on experience are far more important than an AI degree. AI is evolving so quickly that practical experience carries much more weight than formal qualifications. Hopefully everyone working in tech today is already experimenting with AI as part of their day-to-day work, and if not, I'd encourage you to do it in your own time. The tools are incredibly accessible, and what really stands out is someone who's building, learning, staying curious, and developing that engineering mindset.

Tian: QA engineers still have a hugely valuable role in the software development lifecycle. There are now many powerful tools and MCPs that can help automate testing, enhance test suites, and speed up quality assurance. Rather than focusing only on manual testing, testers should think more like automation engineers: using tools like Playwright, headless browser testing, and AI-powered workflows to automate repetitive testing and iterate continuously.
‍
Andrew: I completely agree. Just as we're seeing product and engineering become more integrated, we're seeing the same happen with testing. The old model of developers throwing work over the fence to a QA team quickly becomes a bottleneck in an AI-enabled environment. Teams need to take shared ownership of testing throughout the development lifecycle, with automation built into the process. SDETs and automation specialists become the people driving best practices across the team rather than acting as a final checkpoint.

Tian: What differentiates candidates isn't simply that they use AI, it's whether they understand how it works underneath. Read the documentation, understand the mechanics behind the tools, and learn how to steer AI effectively rather than expecting it to solve everything for you. AI is an incredible accelerator for learning, so use it to speed up your understanding, build projects, experiment regularly, and stay curious. That practical experience and willingness to keep learning are what demonstrate genuine AI fluency.

Andrew: For us, the underlying technology stack is still incredibly important. We work primarily with Java and Angular in a highly regulated banking environment, so strong technical knowledge remains the foundation. AI sits on top of that foundation, it doesn't replace it. Engineers can absolutely learn new languages over time, but we still place significant value on candidates who deeply understand the technologies they'll be working with.
‍
Tian: I completely agree. Strong engineering fundamentals are still the key to building maintainable, readable, principle-driven code. AI helps you move faster, but it can't replace a solid understanding of your stack or solve every real-world edge case. AI should be viewed as an enhancer that amplifies your skills, not as a substitute for them.

Tian: The evolution of AI has really pushed engineering forward significantly. When looking at engineers today, especially from a fundamentals and architectural understanding standpoint, that should be the basis, but what AI has truly transformed is that entire life-cycle train of thought: that product mindset, understanding what a customer would need (internal or external), knowing how the product itself will shape. Rooting everything into your engineering fundamentals, leveraging AI, and building forward with a full life-cycle picture, that's what really stands out. Code is becoming a lot cheaper, but you still need the capability to understand what's scalable at an enterprise level and what users need.

Andrew: I echo a lot of what Tian said. Architectural thinking is a big part of it for us: that end-to-end thinking of how what you're doing impacts the overall platform and the customer. We work in a highly regulated space, a zero-risk environment, so a security mindset has to be there, on top of an AI-enabled SDLC that's evolved enormously even over the last six months. So it's the ability to adapt and sit comfortably within that, which comes through curiosity and ability to learn. Industry knowledge matters too, back-end tech across verticals is fairly similar these days, but understanding the industry and how customers operate within it is where the nuance is. Judgment, ownership of what everybody builds — every line of code you own, whether you wrote it or an agent did. It's almost a collapsing of engineering and product, engineers thinking like product people and vice versa, which is probably where we were about 15 years ago before agile and product management created that separation. I think that separation is disappearing.

Tian: It comes down to what I mentioned earlier: you've got the engineer using AI tools, which will remain valuable, and then you've got the AI engineer, where you're tapping into people's creativity. Take a mathematician or someone with a high statistical inclination, they perform significantly more powerfully building AI-powered tools for a specific feature. The same applies to law degrees, there's a different train of thought, adjacent to engineering, about how to spot little issues and bugs. Graduates from disciplines other than CS often come through with a different problem-solving mindset than a typical engineer, and that extra shift in perspective is a valuable asset to the team.

Andrew: I think it's a bit of both. The core of engineering is largely the same, but the bottlenecks have changed: previously it was about production of code, now it's judging it as well, so it's a shift from coder to architect. Two real examples from our team: one of our newer engineers spends time literally arguing with AI, not just accepting what comes through, because AI is very confident but not always correct. And from a team perspective, the level of collaboration has accelerated massively: people sharing learnings and failures in real time. It's almost like the joy of engineering has come back into the industry. Engagement and motivation across the team have gone through the roof.

Tian: Impact.com has a stance similar to how AWS thinks about junior engineers. One of our graduates started around October/November last year, took about two months to onboard, and after that shipped nearly nine AI solutions that saved hours of human time. Juniors with two to three years' experience are performing at a level engineers with 20 years' experience did five years ago. Part of it is that they've leveraged AI during their studies, and part of it is the curiosity to build cool personal projects at night or on weekends and bring the proven, safer parts of what they learn back into the workplace, something more experienced engineers tend to do less.

Andrew: It's largely about how the team operates around them. We've effectively compressed the foundational ramp-up from six to twelve months down to weeks, with the right guidance, coaching, and mentorship, people are now fully into the code within a month of joining. But that doesn't mean skipping the foundational knowledge; our senior team coaches step by step, asking questions and having juniors go solve things themselves rather than just telling them what to do. For junior engineers in the industry generally: look beyond companies just waving the 'AI' banner for cost savings, and toward companies genuinely building AI into their frameworks, tooling, and product. Curiosity, a builder mindset, and product thinking are what we're looking for and I'm genuinely optimistic about what this is doing for new people coming into the industry.

Andrew: I'd be surprised if anyone isn't using AI, we'd be looking out for that. The test itself doesn't have to be 100% accurate or perfect. What we're more interested in is the human in the loop: the direction the engineer gave, their judgment on what the AI came back with, how they changed things, whether they own the code, can call out gaps, and would do things differently. Once someone can demonstrate that, it's a tick in the box.

Tian: For AI engineer roles specifically, we do a roughly 90-minute interview with a screen share. It doesn't have to work, break, or be fragile: we're gauging the on-the-spot, solution-driven mindset. Are they just prompting an AI to spit something out, or are they using the underlying mechanics; skills, agents, markdown files to set coding principles and standards? Are they giving one big instruction, or staying in control? It's the same human-in-the-loop point Andrew made, you're still the one signing off on AI-generated code. It's like when autocomplete arrived years ago, now you're using AI to move faster on top of your engineering foundation.

Tian: Go and play, build, learn by doing, don't over-rely on AI. Read the documentation and understand the tool itself, whatever IDE or AI tool it is, and know how to leverage hooks, loops, and agents to enhance you as an engineer. See AI not as a shortcut but as an enhancement, and to see it that way you need to understand it's fundamentally a statistical/algorithmic engine at its base, not clever until you know how to use it to your benefit.

Andrew: Echo all of that. AI fluency is the baseline now, so simply saying 'I use AI' in an interview isn't enough. It comes back to judgment: 'I did X because of Y, it went wrong, I fixed it.' Communication matters;, not polished salespeople, but the ability to articulate why something went wrong. Domain knowledge helps too, even without direct industry experience, doing research into the space (e.g., payments, banking) shows curiosity. And taste, knowing what good looks like, not just shipping functionality but functionality that's valuable, performant, secure, and well-crafted. Don't tell us you use AI: tell us how you use it, what you caught, and what you changed.

Andrew: ...can tell the difference between confident and correct.

Tian: ...are able to leverage AI and not just use it, but become augmented with it.