Amazon BIE Online Assessment: SQL Challenge, Working with SQL, and Work Styles

The Amazon BIE online assessment officially includes SQL Challenge, Working with SQL, and Work Styles. Prepare to write queries, inspect their results, and describe your working preferences honestly. A query that runs is only a starting point: joining one order to two refunds can quietly double its sales amount.

This guide separates official facts, candidate reports, and preparation recommendations. Sources were checked on September 8, 2026. Public reports do not establish one current question count, timer, or passing score across BIE hiring routes. The SQL exercises below are original PracHub practice, not reconstructed Amazon assessment questions.

Use the worked example first, then explore Amazon BIE SQL questions on PracHub for additional practice. Those records cover reported interview topics; they do not predict your OA.

What Amazon officially confirms about the BIE OA

Official facts: Amazon names three required parts and an optional closing survey. Its BIE preparation page says all required sections must be completed for successful submission. It publishes a seven-day completion window from the invitation and a two-business-day notification expectation after completion. Check your invitation and recruiter for application-specific instructions or delays.

The inspected page does not provide a detailed blueprint distinguishing the two SQL sections, a universal per-section duration, or a passing threshold. Do not treat the following preparation map as a confirmed description of their interfaces.

The first two recommendations deliberately reinforce each other. Writing a solution and diagnosing a flawed solution expose different weaknesses, even when both use the same tables.

What candidate reports add—and cannot settle

Candidate report: A historical 2025 L5 interview account describes SQL multiple-choice questions and four SQL coding tasks in its initial assessment. That is one candidate’s account, not a current standard for every BIE application.

Candidate reports: A recent BIE OA discussion, checked in September 2026, contains inconsistent descriptions: one commenter emphasizes multiple choice, while another mentions two SQL coding questions and work-style questions. The original request for advice is not itself evidence of having taken the test.

We did not establish two detailed, independent reports from the same recruiting cycle. This article therefore focuses on the official module names and transferable preparation. It does not reconstruct an exact current test. Differences could reflect role, location, recruiting route, or incomplete recollection; that explanation is an inference, not a verified cause.

A software-development OA account also cannot establish the BIE format. Start from the role on your invitation, not the assessment advice with the most replies.

SQL Challenge practice: report net sales without multiplying orders

Original exercise: A marketplace team wants net sales by seller for completed orders placed in June 2026. Subtract refunds recorded before July 1 for those orders. Return only sellers with qualifying orders, including sellers whose net sales are zero. Sort by net sales descending, then seller ID ascending.

All dates are already UTC calendar dates. Amounts are non-null integer cents in one currency. Order IDs and refund IDs are unique in their respective tables; refunds reference existing orders. An order may have several legitimate refunds. Ignore taxes, exchange rates, and later refunds for this exercise.

Input table orders:

Input table refunds:

Before writing SQL, name the output grain: one row per seller. Before grouping sellers, keep one row per qualifying order. Refunds must first become one row per order, or the join will repeat gross sales.

WITH refund_totals AS (
    SELECT order_id, SUM(refund_cents) AS refunded_cents
    FROM refunds
    WHERE refund_date < '2026-07-01'
    GROUP BY order_id
), order_net AS (
    SELECT o.order_id, o.seller_id,
           o.gross_cents - COALESCE(r.refunded_cents, 0)
               AS net_cents
    FROM orders AS o
    LEFT JOIN refund_totals AS r
      ON o.order_id = r.order_id
    WHERE o.status = 'completed'
      AND o.order_date >= '2026-06-01'
      AND o.order_date < '2026-07-01'
)
SELECT seller_id, COUNT(*) AS completed_orders,
       SUM(net_cents) AS net_cents
FROM order_net
GROUP BY seller_id
ORDER BY net_cents DESC, seller_id ASC;

The query was executed locally with SQLite using ISO-format date strings and integer amounts. This verifies the example’s results, not compatibility with an undisclosed Amazon assessment engine. Adapt date literals and types to the environment you are actually given.

Expected output:

Seller A contributes 7,000 from order 101 and 5,000 from order 102. The July refund is excluded by the stated reporting cutoff. Seller B’s cancelled order and July order are excluded. Seller C remains because a fully refunded completed order still belongs to the requested population.

The final total is 20,000 cents across four completed orders. Check those totals independently; a sorted table can look convincing while hiding duplicated revenue.

Working with SQL practice: diagnose four plausible wrong answers

Preparation recommendation: Use this section to practice result reasoning. We are not claiming these are Amazon’s actual Working with SQL questions or answer choices.

1. Seller A shows 22,000 cents. What happened? A direct left join to the two June refund rows repeats order 101’s 10,000-cent gross amount. Subtracting each refund from its joined row gives 8,000 plus 9,000, then order 102 adds 5,000. Aggregate refunds before joining. COUNT(DISTINCT order_id) can repair an order count while leaving the revenue sum wrong.

2. Seller B disappears. Is an inner join equivalent? No. B has no matching refund, so an inner join removes its valid order. A left join retains unmatched orders, and COALESCE supplies zero for the absent refund total. PostgreSQL’s join documentation explains this preservation behavior.

3. Seller A shows 11,500 cents. Which business definition changed? The query likely included the July refund. That number could be valid for a later reporting cutoff, but it is wrong for this prompt. Distinguish the order cohort from the refund observation window. “June sales” alone does not resolve both dates.

4. Seller C is missing. Where would you look? Inspect a HAVING SUM(net_cents) > 0 condition or a filter excluding refunded orders. Neither belongs in the requested output. Zero net sales is a legitimate result, not missing data.

A useful response names the faulty assumption, gives the smallest counterexample, and proposes a correction. “The join is wrong” is weaker than showing that one order became two rows and tracing the duplicated amount.

Extend the exercise before adding harder syntax

Change one assumption at a time. Predict the new output, then run the query. This helps distinguish reasoning from memorizing the supplied solution.

Add a second, distinct 1,000-cent refund to order 101 before July. A should fall to 11,000 cents, with two completed orders unchanged. Both refunds count even if their amounts match: SUM(DISTINCT refund_cents) would incorrectly merge equal amounts from separate events.

Move order 105 from July 1 to June 30. B should become two completed orders and 15,000 cents, moving above A in the ranking. This checks both the date boundary and the requested sort order.

Remove every June order for seller C. C should disappear because the prompt includes sellers with qualifying orders, not all registered sellers. A request for every seller would need a seller dimension as the starting population.

Finally, imagine duplicate records introduced during ingestion with the same refund ID. That violates the exercise’s uniqueness assumption. You would need a documented deduplication rule before aggregation. Do not quietly discard rows based only on their amount.

For additional SQL foundations, SQL for Data Analysis develops broader query patterns. For this OA preparation, prioritize explaining why each intermediate table has the expected number of rows.

Prepare honestly for Work Styles

Official context: Amazon’s Leadership Principles describe expectations such as Customer Obsession, Ownership, Dive Deep, and Earn Trust. They provide context for understanding the organization; they do not supply an answer key to your assessment.

Preparation recommendation: Read the principles, then reflect on how you actually work. Think about a time you challenged an unreliable metric, admitted an error, balanced speed with validation, or followed through on a problem outside your immediate task. Use specific memories to clarify your habits, not to invent a personality you think Amazon wants.

Consider an original reflection scenario: a stakeholder needs a sales dashboard shortly, but two reports disagree. What would you normally do first? Which evidence would you inspect? How would you communicate uncertainty and choose a safe interim action? This is a discussion exercise, not a reproduced Work Styles item or a scored model answer.

Avoid simplistic rules such as always agreeing, always escalating, or always choosing speed. Context matters: the cost of an incorrect number, reversibility of a decision, and available evidence affect responsible action. During the assessment, follow the actual instructions and answer about yourself honestly.

For later conversational interviews, concrete examples can become stories. Keep that separate from the OA’s response format; a Work Styles section is not automatically a request to type STAR essays.

Check the environment and the final output

Before starting, read the invitation for deadline, timezone, available database, permitted resources, and any setup requirements. Do not assume another candidate’s proctoring or tool rules apply. Resolve unclear instructions with the recruiting contact before beginning.

During SQL practice, make your final review mechanical: check column names, column order, grouping level, sorting, missing rows, NULLs, and numeric units. If the sample matches but a test fails, examine edge cases before concluding the platform is broken. A matching sample is evidence about that sample only.

Check whether a numeric result should be cents, currency units, a fraction, or a percentage. Converting the exercise’s 12,000 cents to 120 changes representation, not business value, but can still violate an expected output contract. Preserve the requested representation.

When time is short, prefer a readable correct solution you can validate over an elaborate rewrite. Reserve time to inspect results and the submission state. An unfinished required section is a different problem from one imperfect SQL answer.

After submission, use the invitation and application portal to track your status. Amazon’s published notification expectation is guidance, not evidence that silence proves rejection. If that window passes without an update, contact the recruiter rather than inferring a hidden score from elapsed time.

Practice five Amazon BIE question types

These verified PracHub records support the skills above. They include interview practice beyond the OA and should not be treated as a promised assessment set.

Choose one task from the Amazon BIE SQL collection. Write the expected output for a tiny dataset before running your answer. Then explain one change that would make your query wrong. That is a concrete way to practice both query construction and result verification.

Sources and Further Reading

• Amazon BIE interview preparation — official OA structure and published process guidance.
• Amazon Leadership Principles — official workplace expectations.
• Amazon BI engineer L5 interview experience — historical candidate account, not a universal current format.
• Amazon BIE OA discussion — recent, inconsistent anecdotal descriptions.
• PostgreSQL table expressions and aggregate functions — SQL semantics and reference material.