The technical screen did not get easier because models can write SQL — it moved. Less recall, more judgment: can you read a query and see it is wrong, can you frame an ambiguous request, and can you say what you validated rather than what you produced.
The interview practices described here are drawn from widely reported industry patterns and from the methodology we teach, not from a study of any one market. Our labour-market evidence is specific to British Columbia; if you are interviewing elsewhere, treat this as a preparation framework rather than as a claim about your local employers.
What changed, and how sure we are
We publish no interview-trend statistics because we have verified none. What follows is a qualitative description of widely reported practice. If you see an article claiming a precise share of employers now do any of this, ask where the sample came from — we looked, and we could not find one we would stand behind.
With that said, the pattern people consistently describe looks like this:
- The technical screen moved into a shared editor. Live coding and screen-shared query writing, rather than a quiz you could have memorised.
- Take-homes got messier on purpose. Deliberately dirty data, ambiguous requirements, and a short window — testing judgment about what to fix and what to flag.
- SQL stayed. Joins, window functions and query efficiency remain near-universal, and are now more likely to be probed for reasoning than for syntax recall.
- A new line of questioning appeared. How you work with AI tooling: what you use it for, what you check, and what you would never paste into it.
- More weight landed on framing. Translating a vague stakeholder request into an answerable question, and saying which question is actually worth answering.
There are three different people in the room
The most useful preparation shift is to stop treating an interview as one conversation. It is usually three, with different people optimising for different things. This is the panel we simulate, and we are describing it precisely because knowing which one is talking tells you what a good answer looks like:
The technical lead
Probes hands-on depth — the tools you actually used, the trade-offs you made, how you built and debugged the thing. Asks a follow-up whenever an answer is vague, which means vagueness costs you twice: once for the non-answer and once for the follow-up you now have to survive.
The hiring manager
Cares about ownership, collaboration, communication and business impact, and will typically ask behavioural questions in a structured format. This is where a well-built story about a real project outperforms a technically impressive answer with no context.
The sceptical stakeholder
The one people are least ready for. We model this as a dismissive senior stakeholder with about ten seconds of patience who is looking for reasons to say no — pressure-testing claims, challenging anything unquantified, blunt but never abusive. If your answer only works when the listener is generous, it does not work.
Most people prepare a single set of answers and deliver it to all three. The technical lead finds it shallow, the hiring manager finds it context-free, and the stakeholder finds the weak claim you did not notice you had made. Prepare the same project three ways.
The SQL screen got harder, not easier
The naive expectation is that models made SQL screens obsolete. What actually happened is that recall got cheap, so the screen moved to the thing that is still expensive: knowing when a query that runs is nonetheless wrong.
These are the claims we expect a student to be able to defend after the first SQL week — verbatim from our syllabus:
- I can read a schema diagram and tell you, from the keys alone, how customers, orders, and products relate before writing a single query.
- I build queries in layers — SELECT, then WHERE, then GROUP BY — and I run each layer so I know exactly which clause produced the number I am reporting.
- I know the difference between INNER and LEFT JOIN and can show you a case where choosing the wrong one silently drops or duplicates rows.
- I can find customers with no orders using a LEFT JOIN anti-join, and I can explain why the status filter has to live in the ON clause, not WHERE.
- I use AI to draft and explain queries, but I verify every column against the real schema and can defend each clause aloud before I trust the result.
Every one of those is a judgment claim rather than a syntax claim, and every one is answerable out loud without a keyboard. That is the level the screen is now aimed at.
The new question: "how do you use AI?"
This one catches people because both obvious answers are wrong. "I do not use it" reads as either dishonest or incurious. "I use it for everything" invites the follow-up you cannot survive.
A good answer has three parts, in this order:
- What you use it for. Be specific and unembarrassed — boilerplate, unfamiliar syntax, explaining an error, drafting a first pass.
- What you validate, and how. This is the part that earns the job. Name the actual check: you ran it against the real schema, you reconciled the total a second way, you re-read the docs.
- What you would never do. Paste proprietary or personal data into a public tool. Ship a patch you cannot explain aloud. Report a number you have not checked.
If you want the longer argument behind that answer, it is in why fundamentals still matter when AI can do the job.
You are being graded on four things
When we score a practice answer, we score it on four dimensions. We are publishing them because knowing the rubric is most of the benefit of having one:
- Structure. A clear situation and task, the actions you personally took, and the result. Most weak answers are missing the middle — they describe a context and then a happy outcome with no visible agency in between.
- Specificity. Concrete detail rather than generality. "We improved the reporting process" scores near zero; naming the tool, the failure and the fix scores well.
- Impact. A stated outcome. If you have a real figure, use it. If you do not, say what changed in plain terms rather than inventing one.
- Relevance. Does it answer the question that was actually asked, about the role actually being discussed.
Do not invent facts about yourself. Every piece of coaching we give is bounded by what a candidate actually did — we will help you frame real experience and we will not help you manufacture it. An interview answer that survives the sceptical stakeholder is one that was true to begin with.
Résumés and the questions before the interview
Most rejections happen before anyone speaks to you, so the same discipline has to hold earlier. The bullet structure we teach is problem, context, achievement: what was wrong, what constrained you, and what changed because you acted.
The tailoring rule is narrower than most advice you will read: mirror a job description's exact terminology only where your real experience truthfully supports it. If the posting wants something you have not done, leave it out. Do not pad the gap. A résumé reframes real experience; it never manufactures it.
The screening questions you cannot answer honestly yet
Application forms and screeners ask things you may genuinely not know yet — availability, notice period, work authorisation, and what you expect to be paid. The temptation is to invent something plausible. The discipline we teach instead is to mark it and resolve it deliberately: write a placeholder like [confirm: your number] in your draft, and do not send it until you have replaced it with something true.
We publish no pay figures in these guides, deliberately. What we will point you at is the sourced wage data on our roles and market data page, where every band is published with the caveats its own publisher attaches to it — including which comparisons it does not support. Go and read the caveats, not just the numbers, before you answer this question in a screener.
Write your own defence
The single highest-return preparation exercise we know is the one embedded in every week of our syllabus: for each thing you have built, write five first-person claims you could defend if someone pushed back on them. You have seen several sets of these above.
They are hard to write, which is the point. A claim you cannot phrase precisely is one you cannot defend under a follow-up, and discovering that at your desk is considerably cheaper than discovering it in the interview.
- Write five sentences that each start with "I can" and name something specific.
- For each one, write the follow-up question a sceptical stakeholder would ask next.
- Answer that follow-up out loud, without notes.
- Delete any claim that did not survive, and go and make it true.
What we do not know
We have no measured data on interview formats, pass rates, or how many rounds are typical in any specific market, and we are not going to estimate. Two related gaps we did try to close and could not:
Whether AI, prompt or RAG literacy appears as a stated requirement in ordinary analyst and developer postings, and how often. We found it absorbed into other roles rather than posted as its own, but we could not establish a rate.
Source: Roles & market dataApplicant-per-posting ratios and 2025–26 B.C. technology-sector layoff data specific to junior roles. Nothing survived verification.
Source: Roles & market dataIf you want the rest of what we checked and failed to verify, it is all published on the roles and market data page.
We publish no interview-trend statistics, because we have verified none. Everything in the first section is qualitative and should be read that way.
We have not placed graduates yet, so none of this is derived from our own hiring outcomes. It is our methodology plus widely reported practice.
We publish no pay figures in these guides. The sourced wage bands live on the roles and market data page.
Common questions
Do I still need to learn SQL if AI can write it?
Should I tell them I used AI on the take-home?
What do I say when they ask about pay expectations?
How many interview rounds should I expect?
What is the most common mistake in a data-analyst interview?
Try the free course — no card, no cohort
AI at Work is our free short course on directing, prompting and verifying AI on real business tasks. It is the discipline this guide argues for, and you can start it right now.
Start AI at Work — free Or see the programs