The pipeline design was solid. Partitioned, idempotent, well orchestrated, sensible storage format. Then the interviewer asked what happens when a product team upstream renames a column, and the candidate said the job would fail and they would fix it. She asked how many downstream dashboards would be broken in the meantime, and by whom they would be noticed, and whether anyone would have been told — and it became clear that he had designed a pipeline rather than a product.
That distinction runs through Atlassian data engineer interview questions. Atlassian's data work is internal-platform-shaped: your consumers are dozens of other teams who build on what you produce, so schema changes, contracts, documentation and blast radius carry unusual weight. And the loop ends with a values interview that is genuinely scored and genuinely rejects people.
The loop
- Recruiter screen — level calibration. Ask whether the role sits in the central data platform or in product analytics; the emphasis differs meaningfully.
- Coding and SQL round — Python at roughly LeetCode medium, plus real SQL rather than a token question.
- Pipeline design round — batch versus streaming, orchestration, idempotency, backfills, and change management.
- Data modelling round — grain, dimensional design, and how consumers query what you build.
- Values interview — behavioural questions mapped to Atlassian's published values. Not a formality.
Our Atlassian interview questions guide covers the company-wide loop and the Atlassian backend engineer guide covers the services side.
SQL and coding
The SQL is real. Expect window functions, deduplication with ROW_NUMBER partitioned by a business key, join fan-out and how you detect it, date logic including a date spine, and incremental logic handling late-arriving data. Our SQL window functions interview questions guide covers the highest-yield sub-topic.
Python sits at LeetCode medium with a data flavour — parsing, aggregation, deduplication, streaming counts. Finish each problem by answering the scaling follow-up aloud: what changes if this is a stream, what changes if it does not fit in memory.
Pipeline design, with consumers in the room
The distinguishing round. Prompts look like: design the pipeline that powers product usage analytics, or a system that ingests events from many services and serves them to many teams.
- Start with the consumers. Who queries this, how often, how fresh does it need to be, and what breaks for them if it is late. Naming the consumers before drawing boxes is the single strongest opening here.
- Batch versus streaming, chosen rather than defaulted. State the freshness requirement that justifies the choice, and the operational cost of streaming that batch does not have.
- Idempotency and reruns. Every orchestrator retries. A pipeline that double-counts on a rerun is the classic failure. Our Airflow interview questions guide covers the orchestration layer.
- Backfills. How you reprocess history without breaking live consumers, and how long a full backfill takes — an answer that shows you have actually done one.
- Schema change and contracts. The question from the opening. Expected answer: schema-on-write contracts with the producing team, additive-only changes as the default, expand-and-contract for anything breaking, automated compatibility checks in CI, and a deprecation window with actual notice to consumers. This is where the round is won.
- Data quality. Freshness, uniqueness, referential and volume checks — plus the more interesting question of what fails a run versus what raises a warning, because a check that fires constantly gets ignored.
- Cost. Storage format and partitioning, file sizes, and why scanning less is the main lever.
- Lineage and discoverability. Who can find out that this table exists, what it means, and what breaks if it changes.
Our data engineer interview questions guide covers the role-general bank and analytics engineer interview questions guide covers the transformation layer above.
Data modelling
- Declare the grain out loud for every fact table — "one row per issue transition" — because an undeclared grain is the source of most double counting.
- Star schema versus wide tables on a columnar warehouse, with an honest position on the tradeoff.
- Slowly changing dimensions, and when type 2 history is genuinely required rather than assumed.
- Semantic consistency. Where a metric definition lives so that two teams cannot compute "active user" differently — a very Atlassian-shaped problem, given how many teams consume the same data.
- Event modelling. Product analytics data is event-shaped; sessionisation, deduplication of retried client events, and late-arriving events all come up.
The values interview
This is the round to take seriously, and the one technically strong candidates most often fail.
Atlassian publishes its values, and the interview maps questions to them fairly directly. Prepare specific stories for each theme — a decision you made for the customer's benefit at a cost to yourself, a time you disagreed openly and then committed, something you built that you deliberately kept simple, a time you helped someone else's project at the expense of your own visibility, and a mistake you owned publicly.
Two things fail this round reliably. Lone-hero answers — stories where you did everything and nobody else appears — score badly against a values set that explicitly prizes team outcomes. And generic answers with no specific person, decision or consequence in them. Say who else was involved and what they contributed; it is both more honest and better scored.
How to prepare
- Week 1 — SQL to real depth: window functions, dedup, fan-out detection, date spines, incremental logic. Plus Python mediums with scaling follow-ups spoken.
- Week 2 — pipeline design out loud, starting from consumers every time, with idempotency, backfill and schema-change answers in each.
- Week 3 — modelling: grain declared aloud, SCD tradeoffs, event modelling and sessionisation.
- Final week — five values stories with real numbers and other people in them, rehearsed to two follow-ups deep, plus two full spoken mocks.
Where each option actually helps
- Atlassian's published values — read them properly and map three stories to each. The highest-yield hour for this specific loop.
- Designing Data-Intensive Applications — for the consistency, batch-versus-stream and failure vocabulary.
- The dbt and Airflow documentation — enough to speak concretely about transformation and orchestration.
- A pipeline you have actually run a backfill on — the difference between a textbook answer and a credible one.
- ChatGPT — good for generating design prompts and schema-change scenarios. It will not notice that your story has no other people in it, which is what fails the values round.
- Greenroom — the spoken layer. Ari, the AI interviewer runs the design and values rounds out loud and pushes for the specific instance, which is exactly where generic values answers stop. Honest tradeoff: Ari cannot give you the backfill experience — a real pipeline can.
Frequently asked questions
What is the Atlassian data engineer interview process?
Candidates report a recruiter screen for level calibration, a coding and SQL round with Python at roughly LeetCode medium plus genuine SQL rather than a token question, a pipeline design round covering batch versus streaming, idempotency, backfills and schema change, a data modelling round on grain and dimensional design, and a values interview mapped to Atlassian's published values. The values round is genuinely scored and rejects technically strong candidates more often than they expect.
What pipeline design questions does Atlassian ask?
Prompts look like designing the pipeline behind product usage analytics, or a system ingesting events from many services and serving many internal teams. Strong answers open by naming the consumers and their freshness needs before drawing anything, then cover a justified batch or streaming choice, idempotency so reruns do not double-count, backfill strategy without breaking live consumers, schema change management with contracts and expand-and-contract, data quality checks with a distinction between blocking and warning, cost through partitioning, and lineage.
How do you handle an upstream schema change in a data pipeline interview?
Treat it as a product problem rather than a job failure. The expected answer covers schema contracts agreed with the producing team, additive-only changes as the default, expand-and-contract for anything breaking so both old and new consumers work during the transition, automated compatibility checks in CI so the change is caught before it ships, and a deprecation window with actual notice to the teams that consume the table. Saying the job would fail and you would fix it misses what the question is testing.
What is the Atlassian values interview and how do you prepare?
It is a behavioural round mapped directly to Atlassian's published values, and it is a real filter rather than a formality. Prepare specific stories for each theme — a decision made for the customer at a cost to yourself, a disagreement voiced openly followed by genuine commitment, something you deliberately kept simple, help given to another team at the expense of your own visibility, and a mistake owned publicly. Lone-hero stories where nobody else appears score badly against a values set that prizes team outcomes.
What SQL is asked in an Atlassian data engineer interview?
Real SQL rather than a token question: window functions including ranking and running aggregates, deduplication using ROW_NUMBER partitioned by a business key rather than DISTINCT, join fan-out and how you detect that a join silently multiplied your measures, date logic including generating a date spine so gaps still appear, and incremental logic that correctly handles late-arriving records rather than filtering on a strict watermark.
What data modelling questions come up at Atlassian?
Declaring the grain of every fact table explicitly, since an undeclared grain causes most double-counting; the tradeoff between a strict star schema and wide denormalised tables on a columnar warehouse; slowly changing dimensions and when type 2 history is genuinely needed; where a metric definition lives so multiple teams cannot compute the same measure differently; and event modelling specifics such as sessionisation, deduplicating retried client events and handling late arrivals.