BigQuery already knows the answer. Every query can be submitted as a dry run, which returns the bytes it would process without executing it, at no charge. The gap is that dry runs live in the console or the API, not in the pull request where the decision is made.

Putting the number in the review

dbt-cost is a small Python CLI that closes that gap. It reads the compiled dbt manifest, resolves the models you ask for using dbt's own selector syntax, sends each model's SQL to the dry-run endpoint, and prices the result.

pip install dbt-cost
dbt compile
dbt-cost estimate "stg_orders+"

That gives a table of the selected models with bytes scanned and the estimated cost at the on-demand rate (default $6.25 per TB, changeable with --price). dbt-cost report does the whole project, grouped by layer, so you can see which marts are carrying the bill.

The useful command is diff. Compile the manifest on the base branch and on the pull request, then:

dbt-cost diff --base-manifest base/manifest.json --pr-manifest pr/manifest.json --format markdown --threshold 10

It prints the models whose cost changed, with before, after and the difference, as Markdown that a GitHub Action can post as a sticky comment on the pull request. With --threshold it exits non-zero when the increase crosses the limit, so the check fails and the reviewer sees why. The repository has a workflow that does the two compiles and the comment end to end.

What it cannot do

Dry-run mode is hard-coded. The tool cannot execute a query or read data; it needs only the BigQuery Job User role and read access to the tables the models reference, and it authenticates with Application Default Credentials by default. It is BigQuery only. And a dry run estimates bytes scanned, which is not the whole bill: slot-based pricing, storage and incremental models that scan less at run time than the compiled SQL suggests all need judgement on top.

Why bother

Because cost is a code review question. The engineer who removed a partition filter can put it back in a minute if the number is in front of them. Finding it on the invoice is a different conversation with different people in it.

The pattern generalises beyond dbt and beyond BigQuery: if a system can tell you what an action will cost before you take it, wire that into the place the action is reviewed.

Everything below has a source. Where a number comes from one aggregator, I say so.

Data engineer: pay flat, ads up

IT Jobs Watch tracks permanent job ads across the UK and reports a six-month window. For the six months to 27 October 2026, for permanent Data Engineer roles:

The median has not moved. It was £70,000 in the same window in 2025 and in 2024, and the non-London median has sat at £65,000 for the same period. If you were hoping a tight market would push pay up, the ads do not show it yet.

What has moved is volume. The same source counted 651 Data Engineer ads in this window in 2025 and 1,028 in 2024, against 2,213 now. That is one aggregator's count, and ad counts are noisy (reposts, agencies, the same role listed in three cities), so treat the direction as real and the multiple as rough. Data Engineer ads are 1.83% of all permanent UK vacancies in the window, which for one job title is a lot.

Two other cuts worth knowing. The North of England had 608 ads at a median of £66,805, not far behind the South East's £65,000 on 249 ads. And 565 ads were tagged work-from-home at a £70,000 median, the same as the national figure, so remote is not trading at a discount.

What the ads ask for

Share of Data Engineer ads mentioning each skill, same source and window:

SQL and Python first, as every year. Azure is the cloud that appears most; AWS next, GCP less often. One in five ads now mentions AI, which for a data engineering title is new. Read a few of those ads and it is mostly pipelines that feed models, not training them.

Data analyst: more ads, lower ceiling

Same source, same window, permanent Data Analyst roles:

Ad count was 504 in this window last year and 631 the year before, so analyst hiring has roughly doubled by this measure. The gap to engineering is the thing to notice: a £12,500 difference at the median and a £31,000 difference at the 90th percentile. The analyst ceiling is low. Moving from analyst to analytics engineer or data engineer is where the pay step is.

Analyst ads ask for SQL (32.1%), Power BI (26.7%) and Python (18.5%). Power BI, not Tableau, not Looker. If you are applying for analyst roles in the UK and have never opened Power BI, that is the gap to close first.

The Graduate visa shortens in January

If you are an international student or know one, this is the change that matters most this year.

From 1 January 2027 the Graduate visa, the post-study route most international graduates use to get their first UK job, drops from two years to 18 months for bachelor's and master's graduates. PhD graduates keep three years. People who apply before 31 December 2026 keep the two-year version. Freeths has the detail; check GOV.UK for the current rules before you rely on any date.

Eighteen months is enough, but it changes the plan. The first job search cannot wait for the dissertation to be marked. And the sponsorship conversation with an employer needs to start in the first year, not the second.

The bigger change in the government's 2025 white paper, the proposal to raise the settlement qualifying period from five years to ten, was still at consultation stage at the last update from the House of Commons Library. It is not in force. Anyone telling you otherwise is ahead of the law.

The ICO wants to hear about agentic AI

On 8 October 2026 the Information Commissioner's Office opened a call for evidence on how existing UK data protection law applies to agentic AI, systems that take actions rather than only generate text (Squire Patton Boggs, 20 October). No new rules yet. But if your job involves building agents that touch customer data, the questions the ICO is asking are the ones your own data protection officer will be asking next year. Worth reading the call itself.

What to do with this

• Pricing yourself: the medians above are what ads say, not what people get. Use them as a floor for the conversation, and remember the London premium is about £10,000 at the median for engineers and £5,000 for analysts.
• Choosing what to learn: SQL, Python, Azure, modelling. For analyst roles, Power BI. Everything else is secondary to the ads.
• On a Graduate visa: if you finish in 2026, apply for the visa before the year ends. If you finish in 2027, plan for 18 months and start applying in the final term.

Next month: the same numbers again, so the trend is visible, and whatever else moved.

Sources: IT Jobs Watch, Data Engineer and Data Analyst, six months to 27 October 2026; Freeths on Graduate visa changes, 11 February 2026; House of Commons Library briefing CBP-10267; Privacy World on the ICO call for evidence, 20 October 2026.

This post describes a workflow I use that takes around twenty minutes per application. It assumes you already have a decent master CV. If you do not, fix that first.

The rules before you start

Set these in your head before you open the assistant. They matter more than the prompts.

• Never fabricate. The assistant will happily invent tools, numbers and outcomes. Everything that ends up in your CV must be true and must be something you can talk about in an interview.
• Never paste personal data belonging to other people. No colleague names, no client names, no internal documents. Your own CV and a public job ad are enough.
• Keep a master CV. Tailored versions are derived from it and never replace it. Store it somewhere you will not accidentally overwrite.
• You are the editor. The assistant drafts; you decide. Every change gets read by you before it is saved.

Minute 0 to 5: extract the must-haves

Paste the job ad into the assistant and ask it to separate what the employer requires from what they would like. Most adverts bury the real requirements under boilerplate about culture and benefits.

Here is a job advert for a data engineering role. Read it and give me:

1. The must-have skills and experience, as a short bullet list, in the employer's own words where possible.
2. The nice-to-haves, as a separate list.
3. The three things this employer seems to care about most, based on what they repeat or emphasise.

Do not add anything that is not in the advert. If something is ambiguous, say so.

[paste advert here]

Read the output against the ad. If the assistant has added something that is not there, delete it. You should now have a short list, usually five to ten items, of what you need to show.

Minute 5 to 10: map requirements to real experience

This is the step that keeps you honest. For each must-have, write one line about where in your own history you have done it. If you have not done it, write "no" and move on.

Do this yourself first, quickly, in a plain text file. Then give the assistant your master CV and the requirements list and ask it to find matches you may have missed.

Below is my master CV and a list of requirements from a job advert. For each requirement, tell me which parts of my CV already provide evidence for it. Quote the relevant bullet or line.

Where my CV has no evidence for a requirement, say "no evidence found" and do not suggest anything to add. I will decide what to do about gaps myself.

Requirements:
[paste list]

My CV:
[paste master CV]

The phrase "do not suggest anything to add" is deliberate. Left to its own devices, the assistant will propose plausible-sounding experience to fill gaps. That is exactly what you do not want.

At the end of this step you know two things: which of your real experience to bring forward, and which gaps are genuine. Genuine gaps are fine. Most candidates do not meet every requirement. What matters is that you do not pretend to.

Minute 10 to 15: rewrite the bullets

Now you work on the CV itself. Three types of change are allowed:

1. Reordering. Move the bullets and skills that match the ad nearer the top of each section.
2. Rewording. Use the employer's terminology where it is accurate. If they say "ELT" and you have been saying "ETL" for a dbt-based pipeline, ELT is the better word and it is true.
3. Expanding. If a bullet is thin on something the ad cares about, and you have the real detail, add it.

One type of change is not allowed: adding anything that did not happen.

Ask the assistant for suggestions bullet by bullet rather than for a whole rewritten CV. Whole rewrites are hard to check and tend to drift. A good prompt looks like this:

Rewrite this CV bullet so it better shows the requirement below. Keep every fact exactly as it is. Do not add tools, numbers or outcomes that are not in the original. If the original does not support the requirement, say so instead of rewriting.

Requirement: experience designing pipelines with retries and alerting

Original bullet:
- Built the nightly load for the finance warehouse using Airflow, with task retries and Slack alerts on failure.

Compare each suggestion with the original. Accept it only if every claim in the new version is already in the old one or is something you know to be true and can add yourself. Reject anything that sounds better than what happened.

Also update the summary line at the top of the CV. Two or three sentences, specific to this type of role. It is the single highest-value edit you can make.

Minute 15 to 18: write the cover note

Most UK applications do not need a full cover letter, but a short note helps when there is a free-text box or a recruiter email. Keep it to about 120 words. Four short paragraphs:

• Which role you are applying for and one sentence on why it interests you.
• Two or three sentences linking your strongest matching experience to their main requirements.
• One sentence acknowledging a gap, if there is an obvious one, and how you would close it.
• A plain closing line.

Give the assistant the requirements list and the two or three bullets you want to feature, and ask for a 120-word draft in plain British English with no adjectives about yourself. Then edit it so it sounds like you. If you would not say "I am excited to leverage my skills" out loud, do not write it.

Minute 18 to 20: the honesty check

Before you send anything, read the tailored CV and the note once more with one question in mind: could I defend every line of this in an interview?

Specifically:

• Every tool listed is one you have used in real work.
• Every number is one you measured or can explain the basis for.
• Every outcome happened.
• Nothing has shifted from "I contributed to" to "I built" unless you did build it.
• The summary line describes you, not the job ad.

If a line fails, change it back. The whole point of this workflow is to present your real experience in the best light, not to manufacture a better candidate.

Save the tailored version with the employer's name in the filename, keep the master untouched, and send it.

Why this works

Twenty minutes is short enough to do for every application that matters and long enough to make a visible difference. The assistant does the reading, comparing and drafting, which is where most of the time used to go. You do the judging, which is the part that should never be delegated.

The version of you on the page ends up more accurate, not less. Tailoring done honestly is just editing with a clear audience in mind.

Next step

Take one job ad you are interested in and run only the first two steps. If the mapping shows you meet most of the must-haves, carry on. If it does not, that is useful to know before you spend any more time.

This post covers each family, how to prepare, and what a strong answer looks like. The sample questions are typical, not transcripts from any particular company.

1. SQL on the spot

Almost every process includes live SQL, either in a shared editor with a real database or in a document where you talk through the query. Either way, the interviewer wants to see that SQL is a tool you reach for without hesitation.

How to prepare

• Practise writing queries by hand, without autocomplete, for a couple of weeks before interviews.
• Be fast and correct on joins, GROUP BY with HAVING, window functions, CTEs and date handling.
• Be able to explain what happens to row counts when joins fan out.
• Know how you would find duplicates, the latest record per key, and gaps in a sequence.

Sample question

"Given a table of orders with customer_id, order_date and amount, return each customer's most recent order and the total they have spent."

Strong-answer outline

Talk as you write. State your assumptions. Then build the query in steps.

WITH ranked AS (
  SELECT
    customer_id,
    order_date,
    amount,
    ROW_NUMBER() OVER (
      PARTITION BY customer_id
      ORDER BY order_date DESC
    ) AS rn,
    SUM(amount) OVER (PARTITION BY customer_id) AS total_spent
  FROM orders
)
SELECT customer_id, order_date, amount, total_spent
FROM ranked
WHERE rn = 1;

Then mention the edge cases unprompted: ties on order_date, null amounts, and whether cancelled orders count. That separates a mid-level answer from a junior one.

2. Data modelling

Modelling questions test whether you can turn a business situation into tables that are easy to query and maintain. They are usually conversational.

How to prepare

• Be fluent in the basics of dimensional modelling: facts, dimensions, grain, surrogate keys, slowly changing dimensions.
• Understand when a wide denormalised table is fine and when it is not.
• Know the trade-offs between a star schema and a more normalised model in a modern warehouse.
• Have a view on how modelling changes with tools like dbt, where models are layered and tested.

Sample question

"We run a subscription product. Design the tables an analytics team would use to report on monthly active subscribers, churn and revenue."

Strong-answer outline

Start with the grain. Say what one row of the fact table means. For a subscription product, a daily or monthly subscription-status fact per customer is a sensible start.

Then name the dimensions: customer, plan, date. Explain how you would handle a customer changing plan and whether that history matters. If it does, that is a type 2 slowly changing dimension, and you should say so.

Finish with how the model answers the three questions, and what you would clarify with the analytics team before building.

3. Pipeline design and failure handling

This family separates engineers who have run things in production from those who have only built them. Interviewers want to hear how you think about reliability, idempotency, monitoring and recovery.

How to prepare

• Pick two pipelines you know well and be able to draw them from source to consumer.
• For each, know what happens when a source is late, a schema changes, a job runs twice, or a job fails halfway.
• Have clear definitions for idempotency, backfill and late-arriving data.
• Be comfortable talking about orchestration: dependencies, retries, alerting, SLAs.

Sample question

"Design a daily pipeline that loads supplier files into our warehouse. The files sometimes arrive late and are occasionally resent with corrections. How do you make it reliable?"

Strong-answer outline

Lay out the stages: landing, validation, staging, transformation, publish. Then address the problems in the question.

• Late files: do not couple the schedule to an assumed arrival time. Use a file-arrival sensor, and alert if the file has not appeared by the deadline.
• Resent files: make the load idempotent. Partition by business date and replace the partition, or merge on a stable key. Keep the raw file so you can reprocess.
• Validation: check row counts, schema and key uniqueness before anything reaches the warehouse. Quarantine bad files rather than failing silently.
• Observability: log every run, record row counts in and out, and alert on deviations.

Mention what you would do on day one versus later. That shows judgement, not just knowledge.

4. The past-project deep dive

At some point an interviewer will pick a project from your CV and dig in for twenty minutes or more. They want to know how much of it was really yours, what decisions you made, and what you learned.

How to prepare

• Choose two or three projects from your CV and prepare each in depth: the business problem, the architecture, your contribution, the hard parts, and what you would do differently.
• Be honest about the boundaries of your role. "I built the ingestion layer; a colleague owned the modelling" is a fine answer. Claiming the whole thing and then struggling on detail is not.
• Know the numbers on your CV and how you measured them.

Sample question

"Tell me about the pipeline rebuild on your CV. What was the original problem and what did you change?"

Strong-answer outline

Give the context in two sentences. Then the problem as the business experienced it. Then the decision points: what options you considered, which you chose, and why.

Spend the most time on the hardest part. Interviewers remember specifics. Explain one thing that went wrong and how you handled it.

Close with the result and one thing you would change with hindsight. A candidate who cannot name anything to improve usually has not reflected on the work.

5. Behavioural STAR questions

UK employers, particularly larger organisations and the public sector, lean heavily on competency questions. They want examples they can score. The STAR format (Situation, Task, Action, Result) exists because it makes scoring easy.

How to prepare

• Write down six to eight stories from your work. Cover conflict, failure, pressure, influencing without authority, learning quickly, and improving a process.
• For each, write a STAR version you can deliver in about two minutes.
• Keep the Action section the longest. That is the part about you.
• Practise saying them out loud.

Sample question

"Tell me about a time you disagreed with a technical decision. What did you do?"

Strong-answer outline

Situation: a team was choosing between two approaches to a shared transformation layer.
Task: I thought the chosen option would make testing harder and wanted to raise it without derailing the plan.
Action: I wrote up the concern with a small worked example, shared it before the next design review, and proposed trying both on one model. I made clear I would support whichever was chosen.
Result: the team adjusted the approach where testing mattered most and kept the original elsewhere. The compromise held up.

Note the tone. The strong answer is about raising a concern well and accepting the outcome, not about winning.

Putting it together

With a week before an interview, split it roughly like this: two days on SQL, one on modelling, one on pipeline design, one on your own projects, and one on STAR stories. Then rest.

You will not be asked everything. But if you have prepared across all five families, nothing in the room will surprise you.

Next step

Pick one sample question above and answer it out loud, timed. The gap between what you know and what you can say clearly is the thing to close first.

Length: two pages

Two pages is the norm in the UK for someone with a few years of experience. One page is fine if you are early in your career. Three pages is almost always too many.

Recruiters and hiring managers skim. A long CV does not make you look more experienced. It makes the good parts harder to find.

Ways to get down to two pages:

• Cut roles older than ten years to a single line each.
• Drop degree modules unless you graduated in the last two years.
• Remove any bullet that describes a duty everyone in that role has.
• Use the space you free up on your last two roles, which are what people read.

The summary line

Start with two or three sentences at the top. Not an "objective". A summary of who you are professionally.

A good summary answers three questions: what you do, what you are strongest at, and what kind of work you want next. Keep it specific.

Weak:

Passionate data professional with a proven track record of delivering results in dynamic environments.

Better:

Data engineer with five years of experience building batch and streaming pipelines on Azure. Strongest in SQL, Python and data modelling for analytics teams. Looking for a senior role where I own the platform end to end.

The second version tells a reader what to expect before they reach the detail. The first could belong to anyone.

Impact bullets: problem, action, result

Each bullet under a role should describe something you did that mattered. The simplest structure is problem, action, result.

• Problem: what was wrong, slow, missing or at risk.
• Action: what you built, changed or decided, and the tools you used.
• Result: what happened. Use a number if you have a real one.

Numbers are useful because they are concrete. But only use numbers you can defend in an interview. If you cut a job's runtime, say by how much. If you do not know the exact figure, give a defensible range or describe the result in words. A made-up percentage is worse than no percentage.

Before and after

Before:

- Responsible for maintaining ETL pipelines and fixing data quality issues.

After:

- Rebuilt a nightly ETL job that regularly missed its 6am deadline. Moved it from a single Python script to an orchestrated Airflow DAG with task-level retries. The job now finishes before 4am and on-call pages for it have stopped.

The second version is longer, but it tells the reader what the situation was, what you did about it, and what changed. It also shows tools in context, which is far more convincing than a list.

Aim for three to five bullets per recent role and fewer for older ones. Not every bullet needs a number. Every bullet needs a result.

The skills section

The skills section exists so that a person scanning the CV, or a system searching it, can confirm you have the basics. Order it by what UK job ads ask for most, not alphabetically and not by what you enjoy most.

Reading a lot of UK data engineering adverts, the usual order of priority is:

1. SQL
2. Python
3. Cloud: Azure and AWS most often, GCP less so
4. Data modelling: dimensional models, star schemas, slowly changing dimensions
5. ETL and ELT tooling: dbt, Data Factory, Glue or similar
6. Orchestration: Airflow, Dagster, Prefect, or the cloud-native equivalent
7. Databricks and Spark
8. Everything else: Git, CI/CD, Docker, Terraform, Kafka, testing

Group them under short headings so the section stays readable:

Languages: SQL (T-SQL, PostgreSQL), Python
Cloud: Azure (Data Factory, Synapse, ADLS), AWS (S3, Glue, Redshift)
Modelling and transformation: dimensional modelling, dbt, Spark on Databricks
Orchestration and delivery: Airflow, Azure DevOps, GitHub Actions, Terraform

Only list tools you could talk about for five minutes. If a tool is on your CV, it is fair game in an interview.

UK conventions

A few things that are normal elsewhere look odd on a UK CV:

• No photo.
• No date of birth, age, marital status or nationality.
• No full postal address. City or region is enough.
• No "References available on request". Everyone assumes this.
• British spelling: "modelling", "optimise", "organisation".
• Month and year for dates. Exact days are not needed.
• A PDF named with your name, for example jane-smith-cv.pdf, not CV_final_v3.pdf.

Keep the format simple. Single column, standard fonts, no tables for layout, no icons. Multi-column designs often break when parsed by applicant tracking systems, and they rarely look better to a human either.

Common mistakes

Listing duties instead of outcomes

"Responsible for", "worked on", "involved in". These phrases describe a job description, not a person. Replace each one with what you actually did and what it changed.

A skills section that lists everything you have ever touched

Twenty-five tools in a row tells a reader nothing about where you are strong. It also invites interview questions on things you used once, three years ago. Prune it.

No sign of scale

Data engineering is about scale and reliability. Readers want to know roughly how big the data was, how many pipelines you ran, how many people depended on them. You do not need exact figures. "Tens of millions of rows a day" or "around forty scheduled pipelines" gives useful context.

The same CV for every role

A platform-heavy role and an analytics-engineering role want different emphasis. The content stays true; the ordering and the summary line change. Keep a master CV and produce a tailored version for each application.

Buzzword inflation

"Leveraged cutting-edge technologies to drive business value" means nothing. Say what you built.

Burying recent work

Your most recent role is what gets read. If it has two bullets and a role from six years ago has six, swap the attention.

A quick checklist

Before you send a CV, check:

• Two pages or fewer.
• The summary line is specific to you and the type of role.
• Every bullet has an action and a result.
• Numbers are real and you can explain how you got them.
• Skills are grouped and ordered by relevance.
• No photo, date of birth, or "references available on request".
• British spelling throughout.
• The file is a PDF with a sensible name.

Next step

Take your current CV and rewrite just the top three bullets of your most recent role using problem, action, result. In my experience that one change does more than anything else on this list.