Amerisave Mortgage Software Engineer Interview Guide

The 60-second brief

Amerisave Mortgage works in mortgages, and candidates describe the Software Engineer role as building and maintaining the software behind the mortgage process that loan applicants go through. Reported duties include designing and developing applications, gathering requirements with cross-functional teams, reviewing code and troubleshooting defects. The requirements candidates describe name Java and SQL as the core skills, with Git for version control. Familiarity with AWS or Azure, microservices, JavaScript or Python, and Agile working is listed as a plus.

This guide is for candidates interviewing for the Software Engineer role at Amerisave Mortgage. It covers the five reported rounds (Initial Screening, Technical Assessment, Technical Interviews, Coding Challenges and Experience Discussion), the Java, SQL, debugging and coding questions candidates report, the behavioral prompts, and a seven-day plan. It does not cover other roles or teams, and the exact format can differ by team.

Candidates report five rounds over roughly 4-6 weeks: a recruiter screening, a technical assessment (a take-home or a proctored online exam), technical interviews with team members, coding challenges, and a discussion of past experience and projects.

Focus areas

• Java
• SQL
• Database querying (joins, SELECTs, predicates)

Overview

The reported question set is narrow and built on fundamentals. On the Java side it is object-oriented programming, abstract classes versus interfaces, and common performance problems. On the SQL side it is join types, finding duplicate rows and tuning a slow query. Add a debugging walkthrough, a Java linked-list reversal and a medium algorithm problem, and you have most of the technical surface candidates describe. Prioritise depth on these fundamentals over breadth: practise explaining why an abstract class and an interface differ in design terms, or why a query is slow, before you spend time on extra frameworks.

The role description candidates report is application work on mortgage processes: building features, reviewing code, working with cross-functional teams on requirements, and debugging defects. Use that when you prepare answers. Show that you can read a requirement, choose a sensible structure, write correct Java and SQL, and explain a defect from symptom to cause. Loan and borrower records make natural examples, so duplicate rows, joins that fan out and slow queries are good topics to have ready.

The loop also has a stage devoted to past experience and project work, and the behavioral prompts candidates report are about teamwork, feedback and adapting to change. Prepare two projects you can explain end to end, including your own decisions, plus three short stories. Keep Git fluent, since version control is a listed must-have, and if you have touched AWS, Azure, microservices, JavaScript, Python or Agile teams, have a one-sentence concrete example for each.

Reports describe the technical assessment as either a take-home or a proctored online exam, with Examity named as one platform. Practise both modes: untimed careful work with tests and a readme, and timed work in a plain editor without your usual tooling.

The Amerisave Mortgage interview process

Candidates describe five stages, and the process can vary a little by team. Treat the order and format below as a reported pattern, not a fixed schedule.

Initial Screening

Candidates report that the process starts with a screening by a recruiter. Nothing more is reported about its content, so use it as a chance to ask which format the technical assessment takes and which language it allows, and keep a short account of your own background ready.

What to demonstrate

• No detail is reported on how this screening is assessed, so treat it as a first conversation with the recruiter
• Java, SQL and Git are the skills candidates describe as core, so be ready to speak plainly about your own experience with them

How to prepare

• Write a two-minute walk through your career that names where you used Java, SQL and Git, and one outcome from each.
• Prepare a single honest sentence for each nice-to-have you have really used (AWS or Azure, microservices, JavaScript or Python, Agile), and say nothing about the ones you have not.
• Ask what the technical assessment looks like and what you need to set up in advance.

Technical Assessment

Reports mention either a take-home or a proctored online exam, with Examity named as one platform. Which one you get may depend on the team. In both formats, aim for correct, readable code. Java and SQL are the skills candidates say the technical stages test.

What to demonstrate

• Java proficiency, one of the two skills candidates name for the technical stages
• SQL querying, including joins, SELECTs and predicates, which candidates list among the tested topics

How to prepare

• For a take-home, practise delivering a small Java project with unit tests, a short readme that states your assumptions and a tidy Git history.
• For a proctored exam, do two timed practice sessions in a plain editor with no autocomplete, covering the SQL duplicates and join questions and a Java problem.
• Read the platform instructions as soon as you receive them and test your camera, browser and connection beforehand.
• Rehearse the abstract class versus interface comparison and the join types so they come out without notes.

Technical Interviews

Candidates report one or more technical interviews with team members. Java and SQL fundamentals are the reported question topics overall: object-oriented principles, abstract classes versus interfaces, common Java performance issues, join types, duplicate records and slow-query tuning. Reports do not say which stage asks which question, so use these topics as preparation for this round. Answer them with structure and a concrete example, not a bare definition.

What to demonstrate

• Java fundamentals such as object-oriented programming
• SQL: writing queries and tuning them for given scenarios
• Clear explanation of technical thinking, a communication area candidates report

How to prepare

• Give each fundamentals answer a fixed shape: one-line definition, a small code or query example, a trade-off and a case where you would choose the other option.
• Prepare a Java performance checklist covering object churn, string concatenation in loops, boxing, collection choice, N+1 queries, locking and leaks.
• Run EXPLAIN on a slow query of your own and narrate the plan out loud.
• Prepare the technical-problem story so it names a symptom, a hypothesis, the evidence and the fix.

Coding Challenges

Candidates report that coding challenges may come up during the process, and that coding can be live or a take-home. The reported coding questions are a medium-level algorithm problem from LeetCode, to be solved on a whiteboard or in a coding interview, and a Java function that reverses a linked list. If you work one live, say your reasoning aloud.

What to demonstrate

• Coding skills, which candidates describe as tested through live exercises or take-home work
• Algorithmic thinking: how you approach a problem and structure a solution
• Explaining your approach clearly while you code

How to prepare

• Write the iterative linked-list reversal in Java from memory, then do the recursive version, then trace both on a one-node and an empty list.
• Practise a few medium problems on arrays, hash maps, two pointers and trees, stating brute force, then the improvement, then complexity before you write code.
• Do at least one session on paper or a whiteboard without running the code, and finish by hand-tracing a test case.
• Rehearse the debugging walkthrough so that you can narrate it step by step on a live problem.

Experience Discussion

Candidates report a stage covering past experience and project work. The behavioral prompts (teamwork toward a shared goal, handling feedback, adapting to a significant change) and the technical-problem question are reported for the process as a whole, and they are good material to have ready for this conversation. Know your own decisions on each project well.

What to demonstrate

• Ability to describe technical work clearly
• Examples of past teamwork, which candidates are advised to prepare

How to prepare

• Pick two projects and write for each the goal, your exact role, the stack, one hard decision and the result.
• Write three short stories, one each for teamwork, feedback and adapting to change, in situation, action, result form with first-person verbs.
• Prepare an answer on code review, since reviewing code is a reported duty of the role.
• Practise cutting each story to the essentials and know the longer version for follow-ups.

Where candidates lose points

Defining abstract class and interface by textbook sentence only

Give the design reasoning: an abstract class shares state and partial implementation within a family of types, while an interface defines a contract that unrelated classes can implement, and a class can implement several. Mention default methods and a case where you would pick each, with a short code example.

Writing the duplicates query without saying what counts as a duplicate

Ask which columns define a duplicate first. Then show GROUP BY on those columns with HAVING COUNT(*) > 1, and a ROW_NUMBER() OVER (PARTITION BY ...) version for when the rows themselves are needed, for example to delete all but one. Remember NULLs group together in GROUP BY.

Saying add an index when asked how to optimise a slow query

Start with the execution plan, then check predicates for sargability, join order and row estimates, and select only needed columns. If you propose an index, state the trade-off: it speeds reads (and the row lookup for UPDATE and DELETE) that match its first columns, but adds cost to every INSERT and to updates of indexed columns. Confirm the read gain by re-running the plan and comparing timings, then check the write path.

Reversing the linked list with pointer errors or missing empty and single-node cases

Keep three references (previous, current, next), save next before rewiring, return previous at the end, and hand-trace an empty list, one node and two nodes. State O(n) time and O(1) extra space for the iterative form and the stack cost of the recursive form.

Giving behavioral answers where the group does the work and you are absent

For the teamwork, feedback and change stories, write them in first person and name your decision, the cost or friction and the result. Rehearse each aloud until it runs briefly, and keep detail ready for follow-ups.

Questions & practice

Solve a medium-level algorithm problem from LeetCode on a whiteboard or during a coding interview.

Medium · Coding / Algorithms

Approach

1. Clarify the input size and constraints before coding. They set the target complexity: around 10^5 elements rules out O(n^2) and points to O(n log n) or O(n).
2. Say the brute-force approach and its complexity, then match the problem to a pattern: a hash map for lookups and counts, two pointers or a sliding window for contiguous ranges, sorting for intervals, BFS/DFS for grids and graphs, a heap for top-k, binary search on a monotonic condition, dynamic programming for overlapping subproblems.
3. In Java, pick the right library types: HashMap/HashSet, ArrayDeque as both stack and queue (not the legacy Stack class), and PriorityQueue, which is a min-heap by default (pass a comparator for a max-heap).
4. Before calling it done, test edge cases aloud: empty input, a single element, duplicates, negative numbers and int overflow (use long). Dry-run one small example, then state the final time and space complexity.

Follow-up

• Can you reduce the space complexity of your solution?
• How would your solution change if the input arrived as a stream?
• What is the worst-case input for your approach, and how does it perform there?

Write a function in Java to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Define the node class (int val; ListNode next) and confirm it is singly linked and should be reversed in place, returning the new head.
2. Iterative version with three pointers: prev = null, curr = head; in the loop save next = curr.next, set curr.next = prev, then advance prev = curr and curr = next. Return prev. This is O(n) time and O(1) extra space.
3. Cover the edge cases: a null head and a single node both come back unchanged from the same loop with no special-case code. Trace a three-node list on the whiteboard to show no node is lost.
4. The recursive version (reverse the rest, then set head.next.next = head and head.next = null) is also O(n) time but uses O(n) call stack. On a very long list in Java that can throw StackOverflowError, which is why I default to the iterative one.

Follow-up

• Reverse only the nodes between positions m and n.
• Reverse the list in groups of k nodes.
• How would you check first whether the list contains a cycle?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

What are the different types of joins in SQL, and when would you use each?

Medium · Technical / Domain Questions

Approach

1. Go through each join by the rows it keeps. INNER keeps only matches. LEFT keeps every left row and fills NULLs on the right. RIGHT is the mirror of LEFT. FULL OUTER keeps unmatched rows from both sides. CROSS returns the Cartesian product. A self join pairs a table with itself, such as an employee with their manager.
2. Give a mortgage use case for each: INNER for loans with their borrowers, LEFT for applications with no uploaded documents yet, FULL OUTER to reconcile the loan-origination system against the servicing system, CROSS to generate every date-by-loan-product combination for a report.
3. Cover the anti-join: rows with no match come from LEFT JOIN ... WHERE right.key IS NULL, or from NOT EXISTS. Avoid NOT IN when the subquery can return NULL, because it then returns no rows.
4. Point out the ON vs WHERE trap: a condition on the right table placed in WHERE after a LEFT JOIN discards the NULL-extended rows and effectively turns it into an inner join. Put that filter in the ON clause instead.
5. Warn about fan-out: joining a one-to-many relationship before SUM or COUNT multiplies rows. Aggregate the many side first, or count distinct keys.

Follow-up

• MySQL has no FULL OUTER JOIN. How would you get the same result there?
• How does the database actually execute a join: nested loop, hash join or merge join, and when is each chosen?
• Write a query for the borrowers who submitted no application last month.

Write a SQL query to find duplicate records in a table.

Medium · Technical / Domain Questions

Approach

1. Start by defining what makes two rows duplicates. Take a table of loan applications where a resubmitted form created extra rows: the natural key might be a hash of the SSN plus the property address, not the surrogate id. Then write the base query: SELECT ssn_hash, property_address, COUNT() FROM applications GROUP BY ssn_hash, property_address HAVING COUNT() > 1.
2. To return the full duplicate rows or their ids, use ROW_NUMBER() OVER (PARTITION BY ssn_hash, property_address ORDER BY submitted_at) AS rn in a CTE and select rn > 1. That keeps the first submission and flags the resubmissions.
3. Deal with dirty keys: GROUP BY puts NULLs together in one group, but a self join on a.col = b.col never matches NULLs. Normalise text with LOWER(TRIM(address)) if case or whitespace variants count as duplicates.
4. For cleanup, delete the rows where rn > 1, choosing in the ORDER BY which row survives (earliest submission or latest updated_at). Then add a UNIQUE constraint on the natural key so resubmissions cannot create duplicates again.

Follow-up

• Delete the duplicates but keep the most recently updated application in each group.
• In MySQL a DELETE cannot select from the same table in a subquery. How do you work around that?
• The same borrower resubmitted with a differently formatted property address. How would you find those near-duplicates?

How would you approach optimizing a slow-running SQL query?

Medium · Problem-Solving / Case Studies

Approach

1. Reproduce first. Capture the exact query, parameters and data volume, then read the plan with EXPLAIN ANALYZE (PostgreSQL, and MySQL 8.0.18+). Look for full scans on large tables, sorts or hashes spilling to disk, and estimated row counts far from actual ones.
2. If estimates are far off, refresh statistics (ANALYZE) before anything else. If a scan is the cost, add an index matching the predicate: in a composite index, equality columns go first and the range column last, and a covering index can avoid table lookups.
3. Make predicates sargable: WHERE YEAR(created_at) = 2024 cannot use a plain index on created_at, so rewrite it as a range. Also look for a LIKE pattern that starts with a wildcard, and implicit type casts on the indexed column.
4. Rewrite the query itself: select only the columns needed, replace correlated subqueries with joins or EXISTS, aggregate before joining a one-to-many table, and use keyset pagination instead of large OFFSET values.
5. State the trade-off plainly: an index speeds the reads (and the row lookup for UPDATE and DELETE) that match its first columns, but it adds cost to every INSERT and to updates of indexed columns. Confirm the read gain with the plan and timings, then check the write path before keeping it.

Follow-up

• The index exists but the planner does not use it. What are the possible reasons?
• When does adding an index make overall performance worse?
• The query is fast in development but slow in production. What differs, and how do you investigate?

Explain the concept of object-oriented programming and its principles.

Medium · Technical / Domain Questions

Approach

1. Name the four principles and give each a one-line Java example: encapsulation (private fields behind methods that enforce invariants), abstraction (callers depend on an interface such as List, not ArrayList), inheritance (a subclass reuses and extends a parent), polymorphism (one call, behaviour chosen by the runtime type).
2. Split polymorphism into compile-time overloading (same name, different parameter lists, resolved by the compiler) and runtime overriding (dynamic dispatch on the object's actual class). Mixing these up is a common slip.
3. Show encapsulation with a concrete class: a LoanApplication whose balance field is private, so it changes only through a method that rejects a negative amount.
4. Add the trade-off: deep inheritance trees couple classes tightly, so I prefer composition when the relationship is has-a, and I keep subclasses substitutable for their parent (Liskov substitution).

Follow-up

• When would you choose composition over inheritance? Give an example from code you have written.
• Can you override a static or private method in Java? What happens if you declare one with the same signature?
• How do SOLID principles relate to these four?

Can you describe the differences between an abstract class and an interface in Java?

Medium · Technical / Domain Questions

Approach

1. Start with the structural differences. An abstract class can have constructors, instance fields, any access modifier and both abstract and concrete methods. An interface has no constructors and no instance state, and its fields are implicitly public static final.
2. Cover inheritance: a class extends one class but can implement many interfaces, so interfaces are how Java models multiple types.
3. Bring it up to date: since Java 8 interfaces can have default and static methods, and since Java 9 private methods. If two interfaces supply the same default method, the class must override it and can call a specific one with InterfaceName.super.method().
4. Give the design rule: use an interface for a capability or contract that unrelated classes share (Comparable, Runnable). Use an abstract class when subclasses share state and a fixed skeleton, as in the template method pattern.

Follow-up

• Now that interfaces have default methods, why would you still use an abstract class?
• What is a functional interface, and how does it relate to lambdas?
• Can an abstract class have no abstract methods? Why would you write one?

What are some common performance issues in Java applications, and how can they be mitigated?

Medium · Technical / Domain Questions

Approach

1. Group the causes. Memory: leaks through static collections, unbounded caches, unremoved listeners, and ThreadLocals in pooled threads. CPU and GC: object churn, autoboxing in hot loops, and string concatenation inside loops instead of StringBuilder. Wrong collections: List.contains is O(n) where a HashSet is O(1) on average.
2. Cover I/O and data access, often the larger cost in business apps: N+1 queries from ORM lazy loading (fix with a join fetch or batch fetching), a missing or undersized connection pool, and blocking calls on request threads.
3. Cover concurrency: lock contention on broad synchronized blocks. Fix it by narrowing the locked section or using java.util.concurrent types such as ConcurrentHashMap.
4. Measure before changing anything. Use Java Flight Recorder or async-profiler for CPU hot spots, jstack thread dumps for contention, heap dumps (-XX:+HeapDumpOnOutOfMemoryError, analysed in Eclipse MAT) for leaks, GC logs via -Xlog:gc*, and JMH for microbenchmarks.
5. Close with the trade-off: caching and tuning add complexity and memory. I change one thing, re-measure against the baseline, and keep only changes that show a gain.

Follow-up

• Heap usage climbs steadily until an OutOfMemoryError. Walk through how you find the leak.
• What is the N+1 query problem in Hibernate, and how do you detect it?
• When would you tune the garbage collector rather than change the code?

Describe a challenging technical problem you faced and how you resolved it.

Medium · Problem-Solving / Case Studies

Approach

1. Pick a problem with a real technical constraint: a production bug that was hard to reproduce, a slow query or a data inconsistency. State the impact in one or two sentences, with a number if you have one.
2. Spend most of the answer on your own reasoning: the hypotheses you formed, the evidence that ruled each one out (logs, query plans, profiler output, a failing test) and why the final cause explained every symptom.
3. Describe the fix and how you checked it: the measured result (latency before and after, error rate, rows corrected) and the regression test or alert you added so it would not recur.
4. The mistake that sinks this answer is narrating what the team did without saying which part was yours, or ending with no result. Say "I" for your own actions and give credit for the rest.

Follow-up

• What would you do differently if you hit the same problem again?
• How did you confirm your fix caused the improvement and not something else?
• What alternatives did you consider and reject, and why?

Given a scenario where your code is producing unexpected results, outline your debugging process.

Medium · Problem-Solving / Case Studies

Approach

1. Reproduce it reliably with the smallest input that shows the problem, and write down expected vs actual output. A failing unit test is the best form of this.
2. Narrow the search by bisection: git bisect across commits if it used to work, otherwise breakpoints or logging at the midpoint of the code path to find where the data first goes wrong.
3. Check assumptions before theories: the input data, configuration, environment and versions. Change one variable at a time.
4. Know the common Java culprits: == instead of equals on strings, broken equals/hashCode in hash-based collections, integer overflow, shared mutable state across threads, time zone handling, and double used for money where BigDecimal is needed.
5. Fix the root cause, not the symptom. Keep the failing test as a regression test, and check whether the same pattern exists elsewhere in the codebase.

Follow-up

• The bug only appears in production and you cannot attach a debugger. What do you do?
• How do you debug an intermittent failure that you suspect is a race condition?
• How do you decide when to stop investigating and roll back instead?

Suggested practice checklist

The plan follows the reported rounds: fundamentals in Java and SQL first, then performance and debugging, live coding, and finally the project and behavioral discussion, with a full run-through on the last day.

Day 1 — Map the loop and refresh Java OOP

• Write the five reported rounds on one page and note the format questions to ask the recruiter, especially take-home versus proctored exam.
• Write a one-page explanation of the four object-oriented principles, each with a small Java example.
• Write the abstract class versus interface comparison, including default methods and multiple inheritance of type, and one case for each choice.

Deliverable: A one-page loop map, a one-page OOP summary with four Java examples, and a written abstract class versus interface comparison.

Day 2 — SQL joins and duplicate records

• Create two small tables and write INNER, LEFT, RIGHT, FULL and CROSS joins on them, noting which rows each keeps or drops.
• Write the duplicate-finder with GROUP BY and HAVING, then a ROW_NUMBER version that keeps one row per group.
• Test a one-to-many join before an aggregate to see how counts inflate, and fix it.

Deliverable: A SQL file with one example per join type, both duplicate queries and a fan-out demonstration with the corrected query.

Day 3 — Query tuning and Java performance

• Take a slow query on a table with a few hundred thousand rows, read its EXPLAIN plan and write what you would change.
• Add or remove an index, rewrite a non-sargable predicate, and compare plans before and after.
• List Java performance problems (object churn, string building in loops, boxing, poor collection choice, N+1 queries, contention, leaks) with a fix for each.

Deliverable: A before-and-after plan comparison for one query and a Java performance checklist with a mitigation for each item.

Day 4 — Coding: linked list and a medium algorithm

• Write iterative and recursive linked-list reversal in Java and hand-trace empty, one-node and long lists.
• Solve two medium problems on a hash map and two-pointer pattern, stating brute force, improvement and complexity before coding.
• Attempt the practice problem on overlapping job attempts and peak concurrency from lease records under timed conditions, without running the code until the end.

Deliverable: Two reversal implementations with traced test cases, two solved medium problems with complexity notes, and a timed attempt at the concurrency problem.

Day 5 — Debugging and the technical-problem story

• Write a debugging sequence you can say aloud: reproduce, narrow the scope, form a hypothesis, check logs and recent changes, fix, add a test.
• Apply it to a real bug from your past or a deliberately broken Java method and narrate it out loud.
• Write the challenging technical problem story: symptom, evidence, decision and result.

Deliverable: A spoken-ready debugging checklist, a recorded narration of one bug and a written technical-problem story.

Day 6 — Behavioral stories

• Write the teamwork story, stating your own contribution, one friction point and the outcome.
• Write the feedback story with a concrete review comment, your response and the lasting change.
• Write the adapting-to-change story, including what you dropped and how you updated others, then say all three aloud.

Deliverable: Three first-person stories, each cut to a short spoken version with a longer back-up version.

Day 7 — Full run-through

• Do a mock take-home: build a small Java feature with tests and a readme, committed in small steps in Git.
• Do a timed mock of the exam format: one SQL problem, one Java problem and one explain-aloud question.
• Present two projects aloud, with role, stack, a hard decision and the result, and list what to fix.

Deliverable: A committed mock repository, a timed mock transcript and a short fix list for the weakest area.

Behavioural preparation

Candidates report a stage devoted to past experiences and project work, and the reported behavioral prompts are about teamwork, feedback and adapting to change. For a Software Engineer, answer them with engineering detail: code review, shared ownership of a release, and a change in requirements or tooling. Keep each story in first person so your own contribution is clear.

1. Describe a challenging technical problem you faced and how you resolved it.

Describe a time when you worked as part of a team to achieve a common goal.

Medium · Behavioral / Leadership

Approach

1. Choose a goal that needed several people, such as a feature release, a migration or an incident response, and state it in one sentence together with who was on the team and what each role did.
2. Spend the middle of the story on your own contribution: the specific decision, piece of work or unblocking step that was yours, said with I rather than a collective pronoun.
3. Include one point of friction, such as a disagreement over design, a dependency on another team or a missed handoff, and what you did to resolve it.
4. Close with the outcome and what the team did differently afterward, and mention how you kept others informed, for example through code review, shared tickets or short syncs.
5. The mistake that sinks it is a story in which you cannot be told apart from the group or where the teamwork was only attending meetings.

Follow-up

• What exactly did you do that nobody else on the team did?
• Tell me about a disagreement in that team and how it ended.
• What would you change about how that team worked together?

How do you handle feedback and criticism of your work?

Medium · Behavioral / Leadership

Approach

1. Open with a specific piece of feedback you received, ideally from a code review or a design discussion, and say what it was in concrete terms.
2. Describe your first reaction honestly, then the steps you took: asking a clarifying question, checking the claim against the code or data, and making the change.
3. Show a lasting change, for instance a checklist item, more tests, smaller pull requests or earlier design reviews, so it is clear you adjusted your habits and not just one patch.
4. If you disagreed, show how you handled it: you explained your reasoning with evidence, listened, and either changed your mind or agreed on a path with the reviewer.
5. The mistake that sinks it is claiming you never receive criticism, naming a weakness that is really a strength, or telling a story where the reviewer was simply wrong.

Follow-up

• Tell me about feedback you disagreed with and what you did.
• How do you give critical feedback to a teammate in a code review?
• What changed in your work after that feedback?

Tell me about a time you had to adapt to a significant change at work.

Medium · Behavioral / Leadership

Approach

1. Pick a change with real stakes, such as shifting requirements mid-project, a reorganisation, a new framework or database, or a move to Agile practices, and describe it in two sentences.
2. Show your first actions: what you did to understand the change, what you reprioritised or dropped, and how you updated the people depending on you.
3. Name what the change cost you, for example work thrown away or new skills to learn quickly, and how you handled that without stalling delivery.
4. Give the result and what you took from it, for example a habit of building in smaller increments or checking assumptions earlier.
5. The mistake that sinks it is a story where you only endured or complained about the change, or one with no concrete action.

Follow-up

• What did you have to give up or stop doing?
• How did you keep stakeholders informed while things were uncertain?
• How would you handle it if the change were reversed halfway through?