I've spent a long time thinking about what actually predicts whether someone will thrive in a role, and built a framework around seven signals that live below the surface of a CV or a standard interview.
In practice: a discovery call transcript goes in. What comes out is a complete search brief, meta-layer analysis, a signal-weighted scorecard, a candidate-facing job brief, interview structure, sourcing strategy, and market intelligence. All calibrated to the specific role, company, and moment.
What follows is a real example, anonymised. The company is Vitalco. The role is senior engineer. This is what the framework produces.
A note on what you're reading: this is the full framework, not an excerpt. The signal definitions, the scorecard, the interview architecture, the sourcing strategy, it's all here. What isn't here is the discovery conversation that makes it work. That's a structured 60 to 90 minute briefing that surfaces things a standard intake call misses entirely, the real constraints, the actual culture, the hiring mistakes already made. The framework is only as good as that input. That part doesn't transfer to a document.
Vitalco is an Australian healthtech scaleup that has spent the last three years rebuilding its foundations. What started as a scrappy direct-to-consumer wellness platform running on a founder-built monolith has been systematically modernised, new platform, new fulfilment infrastructure, new data stack. The rebuild is done. Now the focus shifts: get close to the customer again, ship fast, and use AI to do something genuinely useful in personalised health.
The engineering team is sub-50, organised into self-sufficient squads. Each squad has a tech lead, product manager, and designer. The team has been deliberately kept lean. Which means every hire has to matter.
The squad model has a problem. It's bottom-heavy, strong mid-level engineers, overloaded tech leads, not enough senior ICs in between. The tech leads are doing two jobs: leading the squad and being the most senior engineer in the room. That's not sustainable as the roadmap gets more ambitious.
The goal with these two hires is to add genuine senior weight to two squads, people who can own features end to end, push back on product, and start lifting the engineers around them. Not staff engineers. Senior Engineers on a Staff-track trajectory.
AI is the other thread. The VP of Technology has already run a small pilot, six engineers moved to an agentic workflow, AI-first. Pull request volume roughly doubled within the first sprint. The ambition is to scale that across the team.
Frontend-leaning, AI-adjacent. Recommendation and health assessment engine. Suggests the right products, plans, and content based on a member's specific health profile. Stakes: moderate.
Backend-heavy, high reliability. Recurring wellness plans, automated reorder logic, member lifecycle. A small bug means thousands of incorrect emails. Attention to detail is non-negotiable.
Before any signal is assessed, four questions are answered. The answers determine how the signals are weighted. The same signals apply to every search. The weighting changes entirely based on context.
RISK 1 The Operator trap. Looks senior on paper but has spent their career executing clear requirements in large teams where ownership was narrow. They interview well. They talk about scale. They disengage when nobody tells them what to do next.
RISK 2 The AI-sceptic. Technically strong but hasn't engaged with the new ways of working. Someone who needs to be convinced that agentic workflows are worth trying will slow this team down.
RISK 3 The enterprise refugee. Engineers from very large organisations where ownership was narrow and process was thick. The breadth of ownership expected here is a different job.
This isn't a job description. It's everything a candidate needs to decide whether this is right for them, including the parts that are genuinely hard.
Vitalco is a healthtech scaleup that has spent three years rebuilding its foundations. New platform, new infrastructure, new data stack, the hard unglamorous work is done. What's in front of us now is more interesting: get close to the customer again, ship things that matter, and use AI to do something genuinely useful in personalised health.
We're not a startup. There's a roadmap, there are squads, there are product managers. But we're not a big company either. The engineering team is sub-50. Your voice will be heard. If you see something broken, you can fix it. We have a deliberate 20% time carved out for engineer-led initiatives and nobody needs to approve what you do with it.
The team is moving fast in this direction. A pilot group has already shifted to agentic workflows, AI-first. Pull request volume roughly doubled within the first sprint. The ambition is to scale this across the whole team. If you're excited about working this way, this is a good place to do it. Curiosity is a requirement.
You care about what you're building. You push back when something doesn't make sense. You can own a feature end to end, not just the code, the outcome. You're honest about what you don't know. You're excited about AI because you've seen what it can do.
Your degree, or whether you have one. The specific language you've built in before. Whether you've worked in health before, good intuition for the user matters more than domain experience.
This is a good place to work if you want ownership, a mission worth caring about, and the space to work with AI in ways most teams aren't doing yet. It's not the right place if you want narrow scope, clear instructions, and someone to tell you what done looks like every sprint.
Base salary $165,000–$190,000 depending on level and background, plus superannuation. Sydney preferred, Australia-wide considered. Hybrid, roughly two days in the office. Moving quickly, someone in seat within 6–8 weeks.
Signals are not a checklist. They are a lens. The question underneath all seven is always the same, can this specific person do this specific job, in this specific environment, with these specific constraints, and not just survive it but thrive?
Something built outside of work because they couldn't help themselves. The content matters less than the impulse. Strong: almost embarrassed enthusiasm, explains the problem before the technology. Weak: "I followed a tutorial on machine learning."
"Tell me about something you built outside of work in the last 12 months. Why that thing?"
Quality of decision-making when information is incomplete, time is short, or the right answer isn't obvious. The counterfactual is the tell. Strong: the options considered, the one rejected and why. Weak: one polished story with no friction.
"What was the option you most seriously considered and why did you reject it?"
Their name comes up before you ask about them. Gathered through sourcing conversations and candidate-consented peer references only. Back-channel references without candidate knowledge are not used.
Not assessed through specific questions, observed across the entire conversation. Strong: the pause before answering, clarifying questions before committing. In system design: asks about scale and failure modes before touching the architecture. The VP said it directly: candidates who rush into a solution without understanding the problem are failing before they've drawn anything.
Not the companies or titles, the choices. Strong: outcome language over responsibility language. "I built a feature that reduced member churn by 18%" not "I was responsible for the retention platform." Flag: large enterprise experience where ownership was narrow, not a disqualifier, but probe for what they found frustrating and what they did about it.
The difference between genuine depth and performed depth. Smooth narratives are a flag. Real depth has rough edges. Three-layer test: what did you build / why those specific decisions / what went wrong and what would you change.
"Walk me through the specific decision you owned that had the most impact on that outcome."
An accurate model of reality in both directions. Can hold "the environment was genuinely difficult AND here's my part in how it unfolded" at the same time. Combined tell: listen to how they attribute credit in a success story, then how they attribute blame in a failure. The gap between those two is the most reliable self-awareness signal in the conversation.
"What would be genuinely hard about this role for you? Not challenges you'd overcome, things that would require you to grow or get support."
Three stages. Designed to be condensed, strong candidates have options and long processes lose them.
Mindset, motivation, AI baseline. One job: figure out whether this person is worth the team's time. Assess archetype fit, check for the Operator trap and the AI-sceptic flag.
Do not send to next stage: anyone dismissive of AI. Anyone whose answer to the tweet question is "not my problem." Anyone who can't give a specific answer about a constrained environment they've shipped in.
Mutual assessment. The candidate evaluates the company as much as the company evaluates the candidate. The hiring manager's job is not just to assess, it's to make the right person want to work here. Share the AI pilot story. Tell them about the engineer who moved the app store rating from 3.2 to 4.1 over a weekend without being asked.
Part A, Take-home review (20 min): candidate brings a simple working application. The point is not what they built but how they talk about it. Assess ownership language, depth of decision-making, honesty about rough edges.
Part B, Live extension (35 min): deliberately complex, not achievable without genuine AI tooling used well. The point is not to complete it. Watch: do they ask what "done" looks like before starting? Do they use AI fluidly as part of how they think, or to generate code they can't explain?
Part C, System design (40 min): a real problem from Vitalco's infrastructure, simplified. The assessment is not the solution. It's the quality of thinking before the solution. Speed is a flag here, not a feature.
Panel note: a real failure mode was identified in Vitalco's own process, interviewers redirecting rather than following when candidates took a different approach. Strong candidates felt it. The instruction for Parts B and C is explicit: you are assessing the journey, not the destination. Independent scoring before group discussion.
A senior engineer from a product-led startup or scaleup, somewhere between 30 and 200 engineering staff, who has owned features end to end, worked in a squad or cross-functional model, and has started genuinely engaging with AI tooling in their day-to-day work. Not from a large enterprise. Not a pure ML researcher. Not someone who needs to be handed requirements to function.
The AI pilot story is the hook. Not "we're hiring senior engineers", "we've already doubled pull request volume by shifting six engineers to agentic workflows and we're looking for people who want to be part of scaling that." That sentence finds the right people and filters out the wrong ones before a conversation starts.
AVOID Enterprise refugees from large organisations where ownership was narrow. Not because they're not talented, often they are, but because the breadth of expectation here is a different job.
AVOID AI sceptics. There's a meaningful difference between an engineer who hasn't gone deep on AI tooling yet but is curious and open, and one who has decided it's overhyped. The latter is the wrong person for this team right now.