Interviews have always been built around one question: can this person solve the problem in front of them. That question isn’t wrong. It’s just no longer sufficient, and we think it’s worth being direct about why we’re changing how we hire because of it.
A hackathon win is a short window, not a full picture
A hackathon gives you a problem and a deadline. An interviewer shortlists based on the result. Historically, that’s been a reasonable proxy for skill, because getting to a working solution required understanding the problem deeply enough to code your way through it. That correlation is a lot weaker now. With AI in the loop, there are more paths to the same working output than there have ever been with traditional code alone, and not all of those paths reflect the same underlying skill. You can look genuinely strong to an interviewer for the length of a single assessment without any of that holding up once the environment changes around you. That’s not a criticism of candidates. It’s a real limitation of an assessment built for a different era, and it means the interview process has to change on both sides of the table — employer and applicant alike.
Check the prompt, not just the outcome
If we’re going to call someone a prompt engineer, the actual skill worth assessing is control: the ability to reduce hallucination through how a problem gets structured, not the ability to arrive at an acceptable output once, under conveniently favorable conditions. Two candidates can hand us the exact same working demo. Only one of them can explain why they broke the task into the steps they did, why they constrained the model where they did, and what they’d do differently the moment the output came back wrong. That difference is exactly what an outcome-only interview can never see, and it’s exactly what we now ask for directly, instead of trying to infer it from a polished result that might have taken ten lucky attempts to produce.
This is also where we draw a hard line between real skill and what’s being sold as skill. A great deal of prompt engineering marketing treats the discipline like a trick you learn once and reuse everywhere, and we don’t buy it. What we’re actually looking for is closer to systems thinking: someone who understands a problem well enough to guide a model through it deliberately, and who can explain their reasoning at every single step along the way. That’s not something a placement-guarantee course teaches, no matter what the sales page promises. It’s something that shows up only in how a person actually works, and it’s what our process is built to surface now.
Workflow is where AI credits actually get spent
Workflow discipline isn’t just a quality signal to us. It’s a cost signal, and we take it seriously as one. How efficiently someone utilizes AI credits — and whether they can guide a system toward the intended outcome without excessive retries, dead ends, or wasteful over-processing — is a direct function of how well they structured the problem before they ever started prompting. Two people can land on the exact same result at wildly different cost. We care, deeply, about which one we’re hiring, because that gap compounds fast the moment it’s running across a real team on a real product, not a single interview exercise with no consequences attached.
Cost-to-outcome is the metric that matters for platform and infrastructure roles
This becomes sharper the moment you move into platform-as-a-service or infrastructure-as-a-service work. When you’re building the systems other teams and products will run on for years, the question isn’t only “does it work.” It’s “what did it actually cost to get here, relative to what it delivered.” Cost-to-outcome is the metric we weight hardest for these roles specifically, because inefficient workflow at the infrastructure layer never stays contained — it gets inherited, silently, by everything built on top of it afterward.
What this looks like in practice
For candidates, this means showing up ready to walk us through your process, not just your result. Be ready to show us how you structured a problem before you ever touched a model, how you caught and corrected a hallucination mid-task, and how you’d honestly account for what a solution cost to produce. For us, it means our interviews now look closely at process artifacts — prompt sequences, iteration logs, the reasoning behind a decision to constrain or reframe a task — sitting right alongside the finished work, never instead of it.
Problem-solving still matters. It always will, and we’ll never stop caring about it. But in an environment where more people can arrive at a similar-looking answer than ever before, workflow is what actually tells us whether that answer was engineered with intent or landed on by chance. That’s the distinction we’re hiring for now, and we don’t think we’re wrong to.
Before you apply
For job applications, provide credible references with LinkedIn profile links, a working email address, and a contact number. Include your present-day PIN code. Incomplete applications will not be processed.
Leave a Comment