Interview guides · Built Technologies

Built Technologies Software Engineer Interview Guide

Built Technologies Software Engineer interview guide: three reported rounds, coding, API and SQL questions, debugging, behavioral prep and a 7-day plan.

The 60-second brief

Built Technologies makes software for the lending process in real estate and construction. Candidates describe the products as tools that move financial transactions along and give users a way to manage their workflows. A Software Engineer on that product designs, codes and tests features for financial applications, works with product managers and UX/UI designers on what to build, reviews teammates' code, and debugs problems that users report or that testing turns up. Candidates also describe agile ceremonies such as sprint planning and retrospectives as part of the job. The requirements candidates list name Java, C# or Python, web frameworks, RESTful APIs, cloud services such as AWS or Azure, and database management, with DevOps tooling, mobile development and data analysis or visualization tools as extras.

This guide is for candidates interviewing for a Software Engineer position at Built Technologies. It covers the three stages candidates report (a phone screen, technical interviews and a behavioral interview), the fourteen questions candidates report across coding, SQL, API integration, debugging, project discussion and behavioral topics, and a seven-day plan that sequences them. It does not cover other engineering roles, and it does not claim to know which question appears in which stage.

Candidates report three stages over roughly 3-5 weeks: a Phone Screen, Technical Interviews and a Behavioral Interview. Take-home assignments, code review and pair programming also come up in candidate reports.

Focus areas

Coding challenges
Take-home assignments
Code review

Overview

The work is product engineering on financial software: features are designed, built, tested, reviewed by peers and debugged when users hit problems. That shapes what to rehearse. You need clean code in a language you know well (the listed requirements name Java, C# and Python), a working grasp of REST APIs and relational databases, and the ability to describe how you would find a defect in an application you did not write.

The reported technical questions are a mix of fundamentals and experience. The fundamentals are a process versus a thread, slow-query tuning, a palindrome check, binary search and an algorithm of your choice. The experience questions are API integration, debugging strategy, a project you are proud of, what to do when code misbehaves, and how you would structure a new feature. The first group needs correct, rehearsed answers with edge cases. The second needs real stories with specifics, because a general answer to API integration or debugging sounds the same from every candidate.

Candidates also report code review, pair programming and take-home assignments among the topics. Treat those as formats to practise: review a short change out loud, write code while explaining it to another person, and keep a small, tested, readable solution habit for any assignment. The behavioral stage is described as a check on alignment with the company's culture and values, and the reported questions are about conflict, taking the lead, prioritizing across projects and analyzing a large dataset. Prepare four distinct stories rather than one story with four endings.

The loop is short, so every answer has to carry weight. Fix your language choice early, prepare one project you can discuss at depth, and run each reported question aloud until the explanation, the edge cases and the trade-offs come out in order without notes.

The Built Technologies interview process

Candidates describe three stages. Question types are noted per stage where the reports support it; no reported question is tied to a single stage.

Phone Screen

Candidates describe the Phone Screen as an initial call to gauge your experience and your interest in the position. Expect to summarise your background, the languages and tools you have used, and why this role appeals to you. Approach it as a short, structured pitch: your strongest language among the ones the role lists, one project you can go deep on, and a concrete reason for wanting to build software for real estate and construction lending.

What to demonstrate

How your experience maps to the requirements candidates list: Java, C# or Python, web frameworks, REST APIs, cloud services and databases
Your interest in the position and in this kind of product
How clearly you can summarise a project and the technologies you used

How to prepare

Write a short career summary that ends with one project and name its language, framework, database and cloud service. This is the same material the reported question about a project you are proud of asks for.
Prepare a sentence on why financial software for lending interests you, based on what the role actually involves: features, code review, debugging and working with product and design.
Have two or three questions ready about the team's agile practice, how code review works and what the first project would be.

Technical Interviews

Candidates describe the Technical Interviews as sessions that may involve coding challenges and system design discussions. Candidates also mention take-home assignments, code review, API integration and pair programming as topics, though reports do not pin each to a stage. The reported technical questions cover coding (palindrome check, binary search, an algorithm of your choice), fundamentals (process versus thread, optimizing a slow query), and experience (API integration, debugging, a project you are proud of, structuring a new feature). Approach coding by stating assumptions and edge cases before typing, then narrating while you write.

What to demonstrate

Working, readable code in a language you chose, with edge cases handled
Command of fundamentals: concurrency basics, query performance and data structures
Ability to reason about API integration and a feature's design, including trade-offs in technology choices
A methodical way of debugging and of explaining your thinking

How to prepare

Solve the palindrome check and binary search from memory in your interview language, including empty input, a single element, case and punctuation rules, and the off-by-one boundaries.
Be ready to explain a process versus a thread and a slow query. For the query, practise reading an execution plan and naming the index, rewrite or schema change you would try.
Prepare a real API integration story covering failures, retries, authentication and versioning, plus a debugging story with a clear sequence from symptom to root cause.
Practise reviewing a short pull request out loud and coding while someone watches, since code review and pair programming appear in candidate reports.

Behavioral Interview

Candidates describe the Behavioral Interview as a focus on alignment with the company's culture and values, and they report collaboration and communication as themes. The reported behavioral questions ask about a team conflict, a project you led, prioritizing across multiple projects, and a time you analyzed a large dataset. Approach it with four prepared stories that each show a decision you personally made, the trade-off involved and a result you can state. Rehearse them aloud so that none relies on 'we' for the key decision.

What to demonstrate

Collaboration with teammates, product managers and designers, as the role description frames it
Communication when there is disagreement or competing demands
Ownership: what you decided and delivered, as opposed to what your team did

How to prepare

Write one story each for conflict, taking the lead, prioritization and large-dataset analysis, using a situation, your action and a measurable result.
Pick the conflict story from a code review, design or priority disagreement with a peer, product manager or designer, since those are the working relationships the role involves.
Prepare an honest what-I-would-change line for each story.
Prepare questions about team dynamics and ongoing projects to ask at the end.

Where candidates lose points

Describing API integration as a list of technologies with no account of what failed

Prepare one integration with a concrete failure: a timeout, a duplicate request after a retry, an expired credential or an upstream contract change. Say how you detected it, what you changed (idempotency keys, backoff, versioning) and what you would do differently.

Answering the debugging and 'code is not functioning as expected' questions with 'I use print statements and breakpoints'

Give an ordered method: reproduce, shrink the case, check what changed recently, form a hypothesis you can falsify, bisect, then fix and add a regression test. Back it with one real bug where the first guess was wrong.

Writing the palindrome or binary search function without settling the edge cases

Ask whether case, spaces and punctuation count for the palindrome and what an empty string returns. For binary search, fix the loop invariant, the midpoint calculation and the exit condition, and test empty, single-element, first, last and absent targets before saying you are done.

Jumping straight to 'add an index' for a slow query

Start from the plan: find the scan or join that costs the most, check whether the filter can use an index, look for functions on indexed columns and row-count misestimates, then pick the change. Be ready to say what the index costs on writes.

Telling behavioral stories in the plural, where every decision belongs to 'we'

For each of the four stories write down the one decision you made, the alternative you rejected and the measurable result. Practise saying 'I decided' for that part and credit teammates for theirs.

Questions & practice

Explain the difference between a process and a thread.

Medium · Technical / Domain Questions

Approach

Start with the definition. A process has its own virtual address space, file descriptor table and security context, and holds at least one thread. A thread is the unit the OS schedules inside a process. It shares the heap, globals, code and open files with its sibling threads, and has its own stack, registers, program counter and thread-local storage.
Give the cost trade-off. Creating a process costs more: fork needs new page tables, though copy-on-write delays copying memory. Switching between processes changes the address space, which can mean TLB flushes. Switching between threads of one process does not.
Give the safety trade-off. Threads communicate through shared memory, which is fast but allows data races, so you need mutexes, atomics or immutable data, and you risk deadlock. Processes communicate through IPC (pipes, sockets, shared-memory segments) and isolate faults: a crash or memory corruption in one process does not take down the others.
Tie it to the languages listed for this role. In standard CPython, the GIL lets only one thread run Python bytecode at a time. Threads still help I/O-bound work, but CPU-bound work goes to multiprocessing or a process pool. Java and C# threads map to OS threads and are usually run through a pool (ExecutorService, the .NET thread pool and Tasks).
Close with a concrete choice. For example: I run a CPU-heavy batch job as separate worker processes so one crash stays contained, and I handle many concurrent network calls with threads or async I/O inside one process.

Follow-up

What happens when a multithreaded program calls fork(), and why is that risky?
Show a race condition on a shared counter and two ways to fix it.
For a Python web service, when would you scale with more processes rather than more threads?

Solve a problem using an algorithm of your choice and explain your thought process.

Medium · Coding / Algorithms

Approach

Pick a problem you can solve fluently that needs a real idea, in a language you know well (Java, C# and Python are the ones listed for this role). Longest substring without repeating characters works well: it moves from brute force to an optimal solution.
Clarify the input: character set, maximum length, whether the empty string is allowed. Then give the brute force: check every substring for duplicates, which is O(n^3), or O(n^2) if you extend each start with a set. Name the repeated work it does.
Optimise with a sliding window and a map from each character to its last index. For each right index, if the character was last seen at or after left, set left = last[c] + 1 (equivalently, left = max(left, last[c] + 1)). Record last[c] = right and track right - left + 1. This runs in O(n) time and O(min(n, alphabet)) space.
State the invariant aloud: the window [left, right] never contains a repeated character. Then trace it by hand on the empty string, a single character, all-identical input such as 'bbbb', and 'abba'. The 'abba' case catches the bug of moving left backwards.
Whatever problem you choose, keep the same order: clarify, brute force with its complexity, the insight, code, hand-tested edge cases, final time and space.

Follow-up

How do you change it to allow at most k distinct characters in the window?
The input arrives as a stream you cannot store. What still works?
Return the substring itself rather than its length. What changes?

Write a function that checks if a string is a palindrome.

Medium · Coding / Algorithms

Approach

Clarify the rules first. Is the check case-sensitive? Should spaces and punctuation be ignored, so that 'A man, a plan, a canal: Panama' counts? Is the empty string a palindrome? It conventionally is, so return true.
Use two pointers starting at the ends. Skip characters that are not alphanumeric (Python str.isalnum, Java Character.isLetterOrDigit, C# char.IsLetterOrDigit) and compare lowercased characters. Return false on the first mismatch and true when the pointers cross. This is O(n) time and O(1) extra space.
Mention the one-liner and its cost. In Python, cleaning the string and then comparing s == s[::-1] is also O(n) time but builds copies, so it uses O(n) extra space. Fine for short input, but the two-pointer version shows you can avoid the allocation.
Test the edge cases: empty string, a single character, even and odd lengths, a string that is all punctuation, and mixed case.
Know the Unicode caveat in Java and C#. Strings are UTF-16 code units, so comparing chars from both ends breaks characters made of surrogate pairs, such as emoji. Comparing code points fixes that. Combining accents may also need normalisation first.

Follow-up

Can the string become a palindrome if you delete at most one character? Keep it O(n).
Find the longest palindromic substring, and give its complexity.
Check whether a singly linked list is a palindrome using O(1) extra space.

How would you implement a binary search algorithm?

Medium · Coding / Algorithms

Approach

State the precondition: the array is sorted, or more generally there is a monotonic predicate to search on. The classic iterative version sets lo = 0 and hi = n - 1, loops while lo <= hi, and computes mid = lo + (hi - lo) / 2. It returns mid on a match, sets lo = mid + 1 when the middle value is too small and hi = mid - 1 when it is too large, and returns -1 when the loop ends.
Give the complexity and the overflow detail. It is O(log n) time and O(1) space; a recursive version uses O(log n) stack. Writing lo + (hi - lo) / 2 avoids int overflow in Java and C#. Python integers do not overflow, so it matters less there.
Show the lower-bound variant, which handles duplicates and insertion points. Use the half-open range [lo, hi) with hi = n, loop while lo < hi, set hi = mid when a[mid] >= target and lo = mid + 1 otherwise. This returns the first index whose value is >= target. If you instead write lo = mid, round mid up, or the loop never ends on two elements.
Know the library versions. Python's bisect_left and bisect_right return insertion points. Java's Arrays.binarySearch returns -(insertionPoint) - 1 when the key is missing and does not guarantee which duplicate it finds. C#'s Array.BinarySearch returns the bitwise complement (~index) of the next larger element's index when the key is missing.
Test edge cases: an empty array, one element, a target below the minimum or above the maximum, and all-duplicate arrays. Mention binary search on the answer, for example the minimum ship capacity that meets a deadline, whenever the feasibility check is monotonic.

Follow-up

Search a sorted array that has been rotated at an unknown pivot.
Return the first and last positions of a target that appears many times.
How do you search a sorted source whose length you do not know in advance?

How would you optimize a slow-running database query?

Medium · Technical / Domain Questions

Approach

Measure before changing anything. Capture the exact query with its real parameters and read the actual plan: EXPLAIN ANALYZE in PostgreSQL, the actual execution plan in SQL Server. Look for sequential scans on large tables, nested loops over many rows, sorts or hashes spilling to disk, and large gaps between estimated and actual row counts.
Fix access paths with indexes on the filter and join columns. In a composite index, put equality columns first and range columns after. Use a covering index (INCLUDE columns) to skip heap lookups. Know what stops an index from being used: a function on the column (LOWER(email) = ...) without a matching expression index, a leading-wildcard LIKE '%x', an implicit type cast, or a predicate so unselective that a scan is cheaper.
Rewrite the query shape. Select only the columns you need instead of SELECT *. Turn correlated subqueries into joins or EXISTS. Aggregate before joining, so a one-to-many join does not fan rows out. Replace a large OFFSET with keyset pagination (WHERE id > last_seen ORDER BY id LIMIT n).
Check the causes outside the SQL text. Stale statistics call for ANALYZE. An ORM can issue N+1 queries, which you batch into one IN query or a join. Lock contention from long transactions also slows queries. For heavy reports, look at a materialized view, a read replica, caching or date partitioning.
State the cost of each fix and how you verify it. Every index slows writes and takes storage. Re-run the plan after the change and compare p95 latency on production-like data, not on a small dev table.

Follow-up

The plan shows an index exists but the planner ignores it. What do you check?
How would you add an index to a large, write-heavy table without blocking writes?
The query is fast in development and slow in production. What explains the difference?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Describe your experience with API integration and what challenges you faced.

Medium · Technical / Domain Questions

Approach

Anchor the answer in one real integration: which external API, what your system sent or received, and your own part in it, in first person. Then cover authentication: API keys or an OAuth2 client-credentials flow, where secrets were stored, and how token expiry and rotation were handled.
Show how you handled failure. Set an explicit timeout on every call. Retry with exponential backoff and jitter, but only for idempotent requests or requests carrying an idempotency key. Honour HTTP 429 and Retry-After. Stop calling a provider that is down, with a circuit breaker or a queue.
Cover duplicates and ordering. A timeout does not tell you whether the provider applied the request, so a create or payment-like call needs an idempotency key or a lookup before retrying. Webhooks can arrive twice or out of order: verify the signature, store processed event ids, and apply events by their own timestamps or versions.
Name data-contract problems you hit: fields renamed or made nullable without warning, cursor pagination, unit or timezone mismatches, and sandbox behaviour that differs from production. Say how you caught them: contract tests or recorded fixtures, schema validation at the boundary, and a reconciliation job that compares your records with the provider's.
End with one measured result and one lesson. For example: after I added idempotency keys and a nightly reconciliation, duplicate records stopped, and I would add per-endpoint latency and error metrics from day one next time.

Follow-up

Your call timed out and you do not know whether the provider processed it. What do you do next?
How do you test this integration in CI without calling the real API?
The provider changes a response field without notice. How do you find out, and how do you limit the damage?

Can you discuss a technical project you are proud of and the technologies you used?

Medium · Technical / Domain Questions

Approach

Pick a project where you made the main technical decisions. Open with the problem and its hard constraint (scale, latency, correctness or a deadline) and state your role in first person, separate from the team's.
Sketch the architecture in three to five components: client, API layer, services, data store, background jobs. For each technology you name, give the alternative you rejected and why. Stick to technologies you can defend in depth, and connect them to the stack candidates describe for this role (Java, C# or Python, REST APIs, cloud services, databases) only where that is true.
Go one level deeper on the hardest part: the data model, a concurrency problem, a zero-downtime migration or a performance bottleneck. Be ready to sketch the schema or the request flow and explain the trade-off you accepted.
Quantify the outcome with latency, error rate, cost, throughput or adoption. Also name something that went wrong in production and how you handled it, which shows the project was real and you learned from it.
Avoid two common mistakes: a list of technologies with no reasons, and a story told as 'we' that never shows what you personally built or decided.

Follow-up

If you rebuilt it today, what would you change and why?
What broke first as usage grew, and how did you find it?
Why that database or framework rather than the obvious alternative?

How would you approach a situation where your code is not functioning as expected?

Medium · Problem-solving / Case Studies

Approach

State expected and actual behaviour precisely, then read the whole error message and stack trace. Reduce the problem to the smallest input that reproduces it.
Check the cheap assumptions first. Is the code you are reading the code that runs (correct branch, rebuilt artifact, deployed version, no stale cache)? Are the inputs what you think they are? Log or inspect them at the function boundary. Do config and environment variables match?
Narrow the location. Step through with a debugger, or put assertions or logs at the midpoint of the code path to rule out half each time. If it worked before, diff against the last good version or run git bisect.
Write a failing unit test that captures the bug, fix the root cause, then run the full suite to catch regressions. Explain why the fix works, not only that it makes the test pass.
Ask for help at the right moment. After a fixed timebox, explain the problem to a teammate with the hypotheses you have already ruled out. That often surfaces the answer on its own, and if not, it saves the other person's time.

Follow-up

Tests pass locally but fail in CI. What differences do you check?
Your change fixes the bug but you cannot explain why. Do you ship it?
How do you confirm the bug is in a third-party library and not in your own usage of it?

If given a new feature to implement, how would you structure your approach?

Medium · Problem-solving / Case Studies

Approach

Start with requirements. Clarify the user, the problem, the acceptance criteria, the non-goals and the edge cases (permissions, empty states, concurrent edits, failure modes) with product and design. Agree how success will be measured before writing code.
Write a short technical design. Cover data model changes, the API contract (endpoints, request and response shapes, error codes), where the business logic lives, the services it touches, and the riskiest unknown. Get it reviewed before building.
Plan schema changes to stay backward compatible: add a nullable column, deploy code that writes it, backfill, then enforce the constraint. That way old and new code can run side by side during the deploy.
Split the work into small increments that can ship behind a feature flag, and spike the riskiest piece first. Add tests at each layer: unit tests for logic, integration tests at the API boundary, and the edge cases from the requirements. Use code review on each increment.
Roll out gradually behind the flag, with metrics, alerts and a rollback plan. Afterwards, check the result against the acceptance criteria and write down any follow-up work.

Follow-up

Requirements change halfway through the build. What do you do with the work already done?
The deadline cannot hold the full scope. How do you decide what to cut?
How would you release a schema change for this feature with zero downtime?

What strategies do you use for debugging complex applications?

Medium · Technical / Domain Questions

Approach

Reproduce the bug first. Pin down the exact inputs, environment, versions and data, and reduce it to the smallest reliable case. If it only shows up in production, start from structured logs, traces and the request or correlation id of a failing request.
Ask what changed: deploys, config, feature flags, dependency versions, data volume or shape. For a regression with a known good commit, git bisect finds the breaking commit in about log2(n) steps. Inside the code path, put logs or assertions at a midpoint so each check rules out half the remaining code.
Match the tool to the symptom. Use a debugger with conditional breakpoints for logic errors, thread dumps (jstack, dotnet-dump) for hangs and deadlocks, heap dumps or allocation profiling for memory growth, a CPU profiler for slowness, and distributed tracing when the bug crosses services.
Test one hypothesis at a time and change one variable at a time. Keep the trigger (a deploy, a traffic spike) separate from the root cause. Confirm that your logging and metrics are correct before trusting the symptom.
Close the loop. Write a failing regression test, fix the root cause rather than the symptom, confirm with metrics after release, and record what you would monitor so the same bug is caught sooner next time.

Follow-up

The bug is intermittent and only shows up in production under load. Where do you start?
Memory climbs steadily for days until the service restarts. How do you find the leak?
Tell me about a fix you shipped that did not actually fix the bug. What did you miss?

Suggested practice checklist

The plan follows the three reported stages and the fourteen reported questions: coding first, then fundamentals and SQL, then API, project and debugging stories, then behavioral stories and a full run-through.

Day 1 — Map the loop and fix your language

Write the reported sequence (Phone Screen, Technical Interviews, Behavioral Interview) and list what each stage covers from the descriptions above.
Choose one language from Java, C# or Python for coding questions and write down the standard-library pieces you need: string handling, arrays and lists, maps and sets.
Write your phone-screen summary: background, strongest language, one project and why lending software for real estate and construction.

Deliverable: A one-page loop map, the chosen interview language with its standard-library cheat sheet, and the written phone-screen summary.

Day 2 — Coding questions in your language

Write the palindrome check in your chosen language and handle empty input, a single character, mixed case and punctuation.
Implement binary search both iteratively and recursively, then test empty, one element, first, last and missing targets.
Pick one array or string problem for the 'algorithm of your choice' question and explain its brute-force and improved complexity aloud as you write it.

Deliverable: Three tested solutions (palindrome, binary search and one algorithm of your choice) with a stated time and space complexity for each.

Day 3 — Fundamentals: threads and slow queries

Write a clear explanation of a process versus a thread covering memory, scheduling, communication, crash isolation and a race condition example in your language.
Take a slow query you have written or invent one, read its execution plan and write the changes you would try: index, rewrite or schema change.
Work through the reviewed SQL practice exercise on denormalising a column and backfilling it live, as extra query-and-schema practice.

Deliverable: A written process-versus-thread explanation, an annotated query plan with a tuning list, and a worked answer to the practice SQL exercise.

Day 4 — API integration and your project story

Write an API integration story covering the problem, the failure you hit, how you diagnosed it and the fix, with REST concepts such as status codes, retries and authentication in view.
Write your 'project you are proud of' answer: goal, technologies, your own decisions, one trade-off and the result.
Rehearse both aloud so that each runs through without notes.

Deliverable: Two written and spoken stories, one about API integration and one about a project you are proud of, each naming specific technologies and a trade-off.

Day 5 — Debugging and structuring a feature

Write your debugging sequence from symptom to root cause and attach a real bug as the worked example.
Write how you would structure a new feature from requirements through design, implementation, testing and release, naming where you would involve product and design.
Review a short pull request out loud, naming two correctness issues and one readability issue, to practise the code review format.

Deliverable: A debugging sequence with one real example, a feature-approach outline, and a recorded or written code review of a short change.

Day 6 — Behavioral stories

Write the large-dataset story: question, data size, tools and why, validation steps, result.
Write the conflict story and the take-the-lead story, each with your own decision and a measurable result.
Write your prioritization method and one example with a real trade-off, then say all four aloud.

Deliverable: Four written stories (large dataset, team conflict, leading a project, prioritizing) each with a decision, a result and a what-I-would-change line.

Day 7 — Full run-through

Run a mock loop: your phone-screen pitch, one coding question while explaining out loud, one fundamentals question and one behavioral story.
Do a small take-home-style exercise in your language: a short function or endpoint with tests and a brief explanation of choices.
Write the questions you will ask about the team's agile practice, code review and current projects.

Deliverable: A recorded or written mock loop with notes on weak spots, a small tested take-home-style solution, and a list of questions for the interviewers.

Four stories for the behavioral stage

Candidates describe the behavioral stage as a check on alignment with the company's culture and values, with collaboration and communication as recurring themes. For this role that means working with product managers and designers, giving and receiving code review feedback and handling competing priorities. Prepare four stories, each with a decision you made and a result.

Tell me about feedback you gave or received in a code review and what changed afterward.

Describe a time when you had to analyze a large dataset. What tools did you use?

Medium · Problem-solving / Case Studies

Approach

Choose an analysis that changed a decision or fixed a problem, and open with the question you were trying to answer and why the data size mattered. Say how big the data was in your own numbers (rows, files, memory limits) and what that forced you to do.
Explain the tool choice by what it was good for. For example, I used SQL to filter and aggregate close to the data, then pulled a reduced extract into Python with pandas for exploration, and used a charting tool to present it. Say why you did not use the alternative, such as loading everything into memory.
Describe how you verified the data before trusting it: counting duplicates and nulls, checking join keys for fan-out that inflates totals, and reconciling an aggregate against a known source total.
Finish with the result: the decision, fix or finding, who used it and how you showed it to them. The role lists data analysis and visualization tools as a bonus, so a clear chart or summary table is worth mentioning.
Avoid a tool inventory with no question behind it. A list of libraries is not an answer; the reasoning from question to method to conclusion is.

Follow-up

How did you know the numbers were correct, and what check caught a problem?
What would you change if the data were a hundred times larger?
How did you explain the result to someone who does not read SQL or code?

Tell me about a time you faced a conflict in a team. How did you handle it?

Medium · Behavioral / Leadership Questions

Approach

Choose a real disagreement with a specific subject, such as an API design choice in a pull request, a scope decision with a product manager, or a layout constraint with a designer. Avoid a trivial clash and also avoid a story that portrays the other person as the villain.
State the other person's position fairly in a sentence, then yours. Showing that you understood their reasoning is the core of the answer, and it makes the resolution credible.
Describe the steps you personally took: a one-to-one conversation first, bringing evidence such as a benchmark, a prototype, a customer report or a written trade-off list, agreeing on a decision rule, and involving a manager only after direct efforts stalled.
Give the outcome and the aftermath: what was decided, whether it worked, and how the working relationship was afterward. If you lost the argument and committed anyway, say so and say what you did to make the decision succeed.
The mistake that sinks it is claiming you have never had a conflict, or telling a story where you were simply proved right and nothing was learned.

Follow-up

What if the other person had still disagreed after you showed the evidence?
Have you ever committed to a decision you disagreed with, and how did you handle it?
What would you do differently if that situation came up again?

Describe a situation where you took the lead on a project. What was the outcome?

Medium · Behavioral / Leadership Questions

Approach

Pick a project where you owned the outcome: define the goal, the scope and your role in one or two sentences. Say what made it your lead, such as being the person who split the work, set the plan or made the calls when the team disagreed.
Show your mechanics: how you broke the work into tasks, how you handed pieces to others based on their strengths, how you tracked progress (for example through sprint planning and standups), and how you kept product managers and designers informed.
Include a setback and the decision you made under pressure, such as cutting scope, moving a deadline or changing an approach, with the reasoning and the trade-off you accepted.
State the outcome with something checkable: what shipped, what improved, what users or the team gained. Be honest about what fell short.
Say 'I' for the decisions you made and name your teammates' contributions accurately. A story where every decision is 'we' hides your own contribution.

Follow-up

How did you handle a teammate who was blocked or falling behind?
How did you decide what to cut when time ran short?
What would you change about how you led it?

How do you prioritize your tasks when working on multiple projects?

Medium · Behavioral / Leadership Questions

Approach

Answer with a method and then a concrete case. The method: list everything competing for your time, note deadlines and dependencies, compare impact against the cost of delay, and pick the order that unblocks other people first or protects the largest risk.
Show that you communicate, not just decide. Describe telling a product manager or teammate which item would slip, what you would deliver instead and when, so they can object or reprioritize before a deadline is missed.
Give a real example with two or three competing items, such as a feature due in the sprint, a bug reported by users and a code review that a teammate was waiting on. Say what you did first and why.
Describe how you handle interruptions: a production issue goes to the top, the rest are re-ranked openly, and you check the plan again at the next planning point or daily check-in.
Avoid an answer that is just 'I keep a task list and work hard'. The answer is judgment plus negotiation, and the example should include a trade-off that cost something.

Follow-up

Two product managers each say their request is the most urgent. What do you do?
How do you handle a production issue that lands in the middle of a sprint?
Tell me about a time your prioritization turned out to be wrong.