The reported questions focus on fundamentals and day-to-day engineering practice, not puzzles. On the coding side, candidates list stack versus queue, writing binary search, the complexity of common sorting algorithms, how you test your code, and an open coding challenge with no specific problem attached. The technical and domain questions ask about your strongest languages, Agile or Scrum, code quality, RESTful APIs and debugging. The problem-solving cases cover performance optimisation, prioritising a bug that affects many users, gathering requirements from stakeholders and balancing technical constraints against user needs. Since most of these are explain-and-justify questions, preparation means building precise, example-backed answers, not memorising definitions.
The requirements candidates describe ask for Java, C# or Python, web development with HTML, CSS and JavaScript, a solid grasp of databases and SQL, and familiarity with Agile or Scrum. The nice-to-haves are AWS or Azure, mobile development, machine learning and AI concepts, and DevOps practices. Candidate descriptions also mention React, Node.js, Git, CI/CD and dependency management. Pick one primary language from the listed set and make sure you can write a queue, a stack and both binary search variants in it without an IDE. For SQL, be ready to explain a join, an index and a query you have tuned.
The day-to-day work candidates describe is building and testing retail-facing applications, turning requirements into specifications, reviewing code and fixing issues in existing systems. That is why so many reported questions are about process: how you debug, how you rank a widespread bug, how you collect requirements, and how you keep code maintainable. A strong answer to each names a real incident from your own work, the tools you used, the decision you made and a result you can check.
Candidates also list AI / Machine Learning concepts among the topics, while the requirements treat ML as a nice-to-have. Cover the basics well enough to discuss them: supervised versus unsupervised learning, train and test splits, overfitting, and precision versus recall. If you have integrated a model or an AI service into an application, prepare that story too.
Initial Screening Interview
reportedCandidates describe the first stage as a conversation about your resume plus basic technical questions. It does two jobs. First, give a clean account of each project you list: what it did, which language and database it used, and what you personally owned. Second, answer fundamentals in a few accurate sentences without turning them into a lecture. Remove any technology from your resume that you cannot discuss in depth, or study it until you can.
What to demonstrate
- Your resume: the projects, technologies and responsibilities you list
- Basic technical knowledge, answered briefly and accurately
- Whether your experience lines up with the stack the role lists (Java, C# or Python, web technologies, SQL)
How to prepare
- Write a walk-through for each resume project: the problem, your role, the language and database, one hard decision, and one measurable result.
- Prepare short, correct answers on fundamentals across the listed stack: language features of your primary language, HTTP and REST basics, SQL joins and indexes, and your Git branching and review workflow.
- Decide which language you will code in for the Technical Interviews, check that it is one the role lists, and say so if asked.
- Be ready to name which Agile or Scrum practices your past teams actually ran, and which you only know by name.
Technical Interviews
reportedCandidates report one or more technical interviews that combine coding challenges with an in-depth discussion of technical knowledge. The reported coding questions are fundamentals: data structures, searching, sorting complexity and testing. Prepare to write correct, working code in your chosen language and to state its complexity and edge cases without being asked. For the discussion part, back every claim about a tool or practice with an example from your own projects, such as a REST endpoint you designed, a slow query you fixed or a test suite you wrote.
What to demonstrate
- Working code for coding challenges, written live
- Data-structure and algorithm fundamentals, as the reported coding questions cover
- Depth of technical knowledge in the languages and tools you claim
How to prepare
- Practise the reported coding and data-structure questions with working code in your primary language, testing each solution on empty, single-element and duplicate-heavy inputs.
- Solve a set of medium array, string, hash-map, two-pointer and BFS/DFS problems out loud, stating brute force, the optimised approach and its complexity each time.
- For each technology on your resume (SQL, REST APIs, Git, a CI/CD pipeline, a front-end framework such as React), prepare one concrete use and one trade-off you ran into.
- Rehearse explaining your debugging and testing process with a real bug and a real test suite as the examples.
Stakeholder Interaction
reportedCandidates describe this stage as meeting several stakeholders, including technical leads and team members. Treat it as a series of conversations about how you work with others: how you take a request from a non-engineer through to a shipped feature, how you handle disagreement, and how you explain technical constraints to different audiences. Bring separate questions for each group, since a technical lead and a teammate can tell you different things about the codebase, the release process and team habits.
What to demonstrate
- How you communicate with technical leads and with team members
- Collaboration and teamwork, shown through specific past examples
- Fit with the team, as candidates describe this stage
How to prepare
- Write five STAR stories covering teamwork, a conflict, a change in communication style, a technical obstacle, and a requirements or prioritisation call. Each needs a decision you made yourself and a result.
- Practise explaining one technical decision from your past work twice, once to an engineer and once to a non-technical listener from product or operations, and note what changes between the two.
- Write questions for a technical lead (code review norms, testing, how releases ship) and for teammates (sprint rhythm, how requests from operations arrive, how bugs are triaged).
PracHub editorial advice for the preparation topics above.
Writing binary search with mixed boundary conventions, so it loops forever or misses the target on one- and two-element arrays.
Pick one invariant (inclusive [lo, hi] or half-open [lo, hi)) and keep the loop condition and updates consistent with it. Before saying you are done, trace your code by hand on an empty array, a single element, and a target just outside the range. Practise the lower-bound variant too, since duplicates break the exact-match version's guarantees.
Answering the REST question with 'JSON over HTTP' and nothing about method semantics, idempotency, status codes or pagination.
Prepare a compact answer that covers resources and URIs, safe and idempotent methods, the status codes you actually return (including 401 versus 403 and 409), statelessness, caching headers and cursor pagination. Then attach one endpoint you designed and a mistake you corrected in it.
Claiming every sort is O(n log n), or getting quicksort's worst case, stability and space usage wrong.
Learn a small table covering best, average and worst time, extra space and stability for insertion, merge, quick and heap sort, plus counting and radix sort. Know which algorithm the standard library in your primary language uses and why.
Answering the code-quality, testing, debugging and performance questions with principles alone and no incident from your own work.
For each of these four, prepare one real example with the tool you used (profiler, EXPLAIN plan, git bisect, a CI gate), the number before and after, and what you changed in your process afterwards. A principle followed by evidence is a complete answer; a principle alone is not.
Telling teamwork and conflict stories in the collective voice with no decision of your own, or answering the values question with praise for the company.
Rewrite each story so the turning point is something you decided or did, with a result someone could check. For the values and mission question, learn what the company builds and connect one concrete past decision to its users, not to adjectives.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Solve the following coding problem: [insert relevant coding challenge here].
Solve the following coding problem: [insert relevant coding challenge here].
Approach
- No specific problem is reported for this coding challenge, so prepare the process. Restate the problem, confirm input types, sizes and constraints, and work one small example by hand.
- State a brute-force solution and its complexity, then improve it using the pattern that fits the access pattern: a hash map for lookups, two pointers or a sliding window on arrays and strings, sorting plus a scan, a heap for top-k, BFS or DFS for graphs and grids.
- Write the code in your primary language (Java, C# or Python) with clear names and helper functions, and talk through the invariant as you go.
- Test it yourself on edge cases: empty input, a single element, duplicates, negatives, and the largest size. State the final time and space complexity.
Follow-up
- Can you reduce the space complexity?
- How would your solution change if the input arrived as a stream?
- What tests would you write for this function?
Explain the difference between a stack and a queue, providing examples of each.
Explain the difference between a stack and a queue, providing examples of each.
Approach
- Stack: LIFO, with push and pop at the same end, both O(1). Queue: FIFO, with enqueue at the back and dequeue at the front, both O(1) with the right implementation.
- Implementations: a dynamic array works for a stack. A queue needs a circular buffer, a linked list or two stacks (amortised O(1)). In Python, use list for a stack and collections.deque for a queue, because list.pop(0) is O(n). In Java, prefer ArrayDeque over the legacy Stack class. In C#, use Stack and Queue.
- Stack examples: the call stack, undo history, matching brackets, expression evaluation, iterative DFS. Queue examples: BFS, task or print queues, buffering incoming requests, message queues between services.
- Mention the related structures and how they differ: a deque allows both ends, and a priority queue orders by priority rather than arrival, so it is not FIFO.
Follow-up
- Implement a queue using two stacks and explain the amortised cost.
- Design a stack that returns its minimum element in O(1).
- How would you implement a bounded queue with a fixed-size array?
How would you implement a binary search algorithm? Can you write it in your preferred programming language?
How would you implement a binary search algorithm? Can you write it in your preferred programming language?
Approach
- Precondition: the array is sorted. With inclusive bounds, start lo = 0 and hi = n - 1, loop while lo <= hi, set mid = lo + (hi - lo) / 2 (this avoids integer overflow in Java and C#), and move lo = mid + 1 or hi = mid - 1. Return -1 if the target is not found.
- Complexity: O(log n) time and O(1) space iteratively. A recursive version uses O(log n) stack space.
- Know the lower-bound variant: half-open bounds [lo, hi) with hi = n, loop while lo < hi, set hi = mid when a[mid] >= target and lo = mid + 1 otherwise. This finds the first occurrence and the insertion point.
- Check edge cases aloud: empty array, a single element, a target below or above the whole range, and duplicates. Watch for the infinite loop that comes from setting lo = mid under inclusive bounds.
- Mention binary search on the answer: any monotonic yes/no predicate, such as the minimum capacity that meets a deadline, can be searched the same way.
Follow-up
- Return the first and last index of a target in an array with duplicates.
- Search for a target in a rotated sorted array.
- How would you find the square root of an integer without a library call?
Discuss the time complexity of common sorting algorithms.
Discuss the time complexity of common sorting algorithms.
Approach
- Quadratic sorts: bubble, selection and insertion sort are O(n^2). Insertion sort is stable and O(n) on nearly sorted input, which is why hybrid sorts use it for small runs.
- Merge sort: O(n log n) in every case, O(n) extra space, stable. It is the basis of external sorting and works well on linked lists.
- Quicksort: O(n log n) on average, O(n^2) in the worst case with poor pivots (randomised or median-of-three pivots mitigate this), in-place with O(log n) stack, not stable. Heapsort: O(n log n) worst case, O(1) extra space, not stable.
- Non-comparison sorts: counting sort is O(n + k) and radix sort is O(d(n + k)) for bounded integer keys. Comparison sorts have an Omega(n log n) lower bound.
- Connect to real libraries: Python's sort and Java's object sort are Timsort-based (stable, fast on presorted runs), Java sorts primitives with dual-pivot quicksort, and .NET's Array.Sort uses introsort (not stable).
Follow-up
- How would you sort a file too large to fit in memory?
- Why does stability matter when sorting by multiple keys?
- How would you find the top k items without sorting everything?
How do you approach writing tests for your code?
How do you approach writing tests for your code?
Approach
- Describe the test pyramid as you apply it: many fast unit tests on business logic, fewer integration tests against a real database or HTTP layer, and a small set of end-to-end tests for core user flows.
- Explain what goes in each test: the Arrange-Act-Assert structure, behaviour rather than implementation details, boundary values and equivalence classes, and the error paths.
- Use mocks or fakes only at external boundaries (third-party APIs, the clock, the network) so tests stay valid through refactors. Name your tools: pytest, JUnit, xUnit or NUnit, Jest.
- For bug fixes, write the failing test first. Run everything in CI on every pull request. Treat coverage as a signal for gaps, not a target, and quarantine and fix flaky tests rather than retrying them.
Follow-up
- How would you test code that depends on the current time or an external service?
- What do you do about a flaky test that blocks merges?
- How much coverage is enough, and how do you decide?
Denormalise tenant onto revisions and backfill it live
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?
Replace offset paging on the resource feed with keyset
resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.
Approach
- Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
- Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
- Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
- Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.
Follow-up
- The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
- Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?
What programming languages are you most proficient in, and why?
What programming languages are you most proficient in, and why?
Approach
- Name one or two languages from the stack the role lists (Java, C#, Python, JavaScript) and rank them honestly. Pick one as your primary and say what you shipped in it.
- Show depth with specifics, not adjectives: the type system, memory management and garbage collection, the concurrency model (threads and executors in Java, async/await in C# or JavaScript, the GIL and asyncio in Python), and the tooling you use (build tool, test framework, linter).
- Answer the 'why' part with fit to the problem: for example, Python for data scripts and quick services, Java or C# for long-lived typed backends, JavaScript or TypeScript for the browser.
- Name a pitfall you have actually hit in your primary language, such as Python's mutable default arguments, Java's equals/hashCode contract, or JavaScript's == coercion. It shows real use.
Follow-up
- What is a language feature in your primary language that you think is misused, and why?
- If the team works in C# and your strength is Java, how would you get productive quickly?
- How do the error-handling models differ between two languages you know?
How do you ensure code quality and maintainability in your projects?
How do you ensure code quality and maintainability in your projects?
Approach
- Structure the answer in layers. Before the code: small, focused pull requests and clear naming and module boundaries. In the pipeline: formatters, linters and static analysis in CI that block the merge. After: review standards and tests.
- Describe your review practice: what you check first (correctness, edge cases, tests, readability), how you keep reviews small, and how you give feedback that gets acted on.
- Tie maintainability to tests and design: unit tests around business logic, dependency injection at external boundaries, and short decision records for non-obvious choices.
- Give one concrete example with a measurable signal, such as fewer production defects after adding a test gate, or faster onboarding after splitting a large module.
Follow-up
- How would you improve the quality of a legacy codebase with no tests?
- How do you handle a reviewer who disagrees with your design in a pull request?
- What do you cut first when a deadline forces a trade-off between quality and delivery?
Can you explain the concept of RESTful APIs and their importance in software development?
Can you explain the concept of RESTful APIs and their importance in software development?
Approach
- Define REST as an architectural style. Resources are identified by URIs and manipulated through a uniform interface of HTTP methods. Each request is stateless, and representations (usually JSON) are cacheable where appropriate.
- Know the method semantics: GET is safe and idempotent; PUT and DELETE are idempotent; POST is neither; PATCH is a partial update. Map status codes correctly: 200, 201 with a Location header, 204, 400, 401 versus 403, 404, 409, 422, 429, and 5xx.
- Cover the practical design points: plural resource nouns, nesting only for true ownership, cursor pagination for large lists (offset gets slow and shifts under inserts), filtering via query parameters, versioning in the path or a header, and ETag with Cache-Control for caching.
- Explain why it matters: a uniform contract lets a web front end, a mobile app and third-party integrations share one backend and evolve independently. Retries are safe for idempotent methods, and for POST you can add an idempotency key.
Follow-up
- How would you make a POST that creates a transaction safe to retry after a timeout?
- When would you choose GraphQL or gRPC over REST?
- How do you introduce a breaking change to an API that clients already depend on?
How would you approach optimizing an existing software system for better performance?
How would you approach optimizing an existing software system for better performance?
Approach
- Start by defining the target: which metric (p95 latency, throughput, memory, cost), for which operation, and what number counts as success. Then measure a baseline under realistic load.
- Profile before changing anything: CPU and memory profilers, APM traces to see where request time goes, the database slow-query log and EXPLAIN ANALYZE for SQL.
- Fix the largest bottleneck first. Common ones are N+1 queries, missing or unused indexes, unbounded result sets without pagination, repeated work that could be cached or batched, synchronous calls that could move to a queue, and an O(n^2) loop that should be a hash lookup.
- State the trade-off of each fix: caching brings staleness and invalidation work, indexes slow down writes, and async processing adds eventual consistency.
- Verify with the same metric under the same load, and add a regression guard such as a performance test or a dashboard alert.
Follow-up
- How would you invalidate a cache when the underlying data changes?
- When would you scale horizontally instead of optimising the code?
- The database is the bottleneck. What are your options, in order?
Given a scenario where multiple users face a software bug, how would you prioritize fixing it?
Given a scenario where multiple users face a software bug, how would you prioritize fixing it?
Approach
- Triage on severity and reach together. Severity order: data loss, security or money incorrectness first, then a blocked core workflow, then degraded behaviour, then cosmetic issues. Reach: how many users, which segment, and whether the count is growing.
- Mitigate before you fix. Roll back the release, turn off the feature flag, or publish a workaround, then do the root-cause work once the bleeding has stopped.
- Communicate early and on a schedule: tell support and the affected stakeholders what is known, what the workaround is and when the next update comes.
- Put it in context with current work: a high-severity, wide-reach bug preempts the sprint, while a low-severity one goes into the backlog with a clear rank.
- Close it out with a regression test, a short postmortem and a monitoring alert that would catch it next time.
Follow-up
- Two high-severity bugs arrive at the same time and you can only work on one. How do you choose?
- A large customer is pushing hard for a low-severity bug fix. What do you do?
- How would you measure how many users a bug affects if there is no direct metric?
What steps would you take to gather requirements for a new feature request from stakeholders?
What steps would you take to gather requirements for a new feature request from stakeholders?
Approach
- Identify every stakeholder group first: the requester, the end users, operations and support staff who live with the feature, and any team that owns a system it touches.
- Ask about the problem, not the requested solution: what they do today, where it fails, how often, and how they will know the feature worked. Write that down as a success metric.
- Capture requirements as user stories with acceptance criteria (Given/When/Then), plus non-functional needs: performance, permissions, audit, and offline or failure behaviour.
- Prioritise with the stakeholders (for example must/should/could), then confirm understanding with a mock-up or a thin prototype before full build-out.
- Close the loop after release: check the success metric and gather feedback for the next iteration.
Follow-up
- Two stakeholders give you conflicting requirements. How do you resolve it?
- What do you do when the stakeholder is not available to answer questions mid-sprint?
- How do you handle scope that keeps growing after work has started?
How do you balance technical constraints with user needs in software design?
How do you balance technical constraints with user needs in software design?
Approach
- Separate the user need from the solution that was asked for. Often the need can be met in a way the constraints allow.
- List the real constraints: latency, an existing system or integration that cannot change, data that is not available, budget, deadline and team skills.
- Lay out two or three options with their costs, and favour phased delivery: a version that meets the core need now, with the rest planned as a follow-up.
- Make the trade-off explicit to product and record it, including any technical debt taken on knowingly and when it will be paid down.
- Back the answer with a specific example where you made such a call and what happened.
Follow-up
- When have you pushed back on a user request, and how did it end?
- How do you decide whether a shortcut is acceptable technical debt?
- How did you check that the compromise still met the user need?
What debugging techniques do you employ when facing software issues?
What debugging techniques do you employ when facing software issues?
Approach
- Start by reproducing the issue reliably, and record the exact inputs, environment and version. A bug you cannot reproduce cannot be confirmed fixed.
- Narrow the search space: read the full stack trace and logs, check what changed (recent deploys, config, dependency bumps), and use git bisect when a known-good version exists.
- Work with one hypothesis at a time. Use a debugger with conditional breakpoints for local issues, and use structured logs with request or correlation IDs, metrics and traces for issues that only show up in production.
- Before fixing, write a failing test that captures the bug. Then fix the root cause, not the symptom, confirm the test passes, and note what monitoring would have caught it sooner.
- Have an intermittent-bug story ready if you can (race conditions, time zones, environment differences between staging and production), since it shows method rather than luck.
Follow-up
- How do you debug an issue that only occurs in production and that you cannot reproduce locally?
- A test fails in CI about one run in ten. What do you do?
- How do you know your fix actually addressed the cause?
Each day targets one reported stage or one cluster of reported questions. The plan moves from your resume and fundamentals, through coding and engineering practice, to the stakeholder conversations, and every task produces something you can review.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Resume walk-through and stack fundamentals
- Write a walk-through for each project on your resume: the problem, your role, the language and database, one hard decision, and one measurable result.
- Write and rehearse your answer to the strongest-languages question, including one pitfall you have hit in your primary language.
- Write down the Agile or Scrum practices your past teams ran, one you changed, and one that failed, then rehearse the methodology answer out loud.
Deliverable: A one-page resume walk-through plus outline answers for the languages and methodology questions.
Practice prompt ↗Practice prompt ↗02Stacks, queues and binary search in code
- Implement a stack, a circular-buffer queue and a queue from two stacks in your primary language, with unit tests for empty, full and single-element cases.
- Write exact-match binary search and the lower-bound variant from memory, then trace both by hand on arrays of length 0, 1 and 2.
- Solve first-and-last-occurrence and rotated-array search problems out loud, stating complexity before you code.
Deliverable: A tested file with stack, queue and both binary search variants, plus written traces of the edge-case runs.
Practice prompt ↗Practice prompt ↗03Sorting complexity and open coding practice
- Fill in a table of best, average and worst time, space and stability for insertion, merge, quick, heap, counting and radix sort, and note which sort your language's library uses.
- Implement merge sort and quicksort with a randomised pivot, and test both on sorted, reversed and all-duplicate input.
- Solve three medium problems (hash map, sliding window, BFS) out loud, each time stating brute force, the improved approach and the final complexity.
Deliverable: A sorting comparison table, two tested sort implementations, and three solved problems with complexity notes.
Practice prompt ↗Practice prompt ↗04REST APIs and SQL
- Write a REST API outline for a resource you know: endpoints, methods, status codes, cursor pagination, versioning, and an idempotency key for the create call.
- Work the keyset-pagination SQL practice question and explain why offset paging slows down and skips rows under concurrent inserts.
- Work the denormalise-and-backfill SQL practice question, then rehearse explaining a join, an index and a query you have tuned with EXPLAIN.
Deliverable: A one-page API outline plus written solutions to both SQL practice questions.
Practice prompt ↗Practice prompt ↗Practice prompt ↗05Code quality, testing, debugging and performance
- For the code-quality and testing questions, write an answer built around one real codebase: review norms, CI gates, the test pyramid and one flaky-test fix.
- For the debugging question, write up one real bug as reproduce, narrow, hypothesis, failing test, fix, prevention.
- For the performance question, write up one optimisation as metric, baseline, profile, fix, trade-off and verification.
Deliverable: Four written answer outlines, each built on a named incident or codebase with before-and-after evidence.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗06Problem-solving cases with stakeholders
- Write a triage rubric (severity by reach, mitigate first, communication cadence) and apply it out loud to the multi-user bug question.
- Outline your requirements-gathering steps and the constraints-versus-user-needs trade-off, each anchored on a feature you shipped.
- Write the technical-obstacle story in STAR form with the investigation in the middle and a checkable result.
Deliverable: A bug triage rubric, two case answer outlines tied to real features, and one STAR story.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗07Behavioral stories and the Stakeholder Interaction stage
- Write STAR stories for teamwork, conflict and a change in communication style, each with a decision of your own and a result.
- Prepare the values-and-mission and motivation answers with one concrete example each, connected to what the company builds.
- Write questions for a technical lead and for teammates, then run a mock where a friend asks all reported behavioral prompts in random order.
Deliverable: Five behavioral answers, a list of questions for leads and teammates, and notes from one full mock run.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
The reported behavioral questions cover teamwork, conflict, adapting your communication, alignment with the company's mission, motivation, and overcoming a technical obstacle. The Stakeholder Interaction stage puts you in front of technical leads and team members. For each prompt, prepare a story where you made a decision, explain what it cost or risked, and give a result someone could check.
Describe your experience with software development methodologies (e.g., Agile, Scrum).
Describe your experience with software development methodologies (e.g., Agile, Scrum).
Approach
- Describe the process you actually ran: team size, sprint cadence, which ceremonies happened (planning, stand-up, review, retro), who owned the backlog, and your own role in it.
- Give one thing that worked and one that did not, with evidence. For example, retros that produced no actions, or stories too large to finish in a sprint and how you split them.
- Describe a change you drove yourself, such as a definition of done that required tests and review, smaller stories, or a work-in-progress limit, and what it changed.
- Contrast Scrum with Kanban and say when each fits: fixed sprints for planned feature work, flow-based Kanban for support or interrupt-heavy teams. Do not just recite the Scrum Guide.
Follow-up
- How did your team handle an urgent production bug in the middle of a sprint?
- How did you estimate stories, and how accurate were the estimates?
- When would you argue against using Scrum?
Describe a time when you encountered a significant technical obstacle. How did you resolve it?
Describe a time when you encountered a significant technical obstacle. How did you resolve it?
Approach
- Choose an obstacle that is genuinely technical: a memory leak, a flaky third-party integration, a data migration, a performance wall, or a concurrency bug. Pick one where you made the call.
- Spend two sentences on the situation, then most of the time on the investigation: what you tried, what evidence ruled each option out, and why you chose the fix you did.
- Give a checkable result (error rate, latency, hours saved, incident closed) and what you changed afterwards to prevent a repeat.
- Keep your own actions in the first person singular. A story in which the team solved it and you watched does not answer the question.
Follow-up
- What would you do differently if you hit the same obstacle again?
- At what point did you consider asking for help, and did you?
- How did you confirm your fix was what resolved the problem?
Tell me about a time you had to work closely with a team to achieve a common goal.
Tell me about a time you had to work closely with a team to achieve a common goal.
Approach
- Choose a goal with a clear shared outcome: a release, a migration or an incident. Name your specific part in it.
- Explain how the team coordinated (split of work, interfaces between pieces, check-ins) and the moment it nearly went wrong.
- Show what you did beyond your own task: unblocking someone, taking on an unglamorous piece, or flagging a risk early.
- End with a measurable result and one thing you would change about how the team worked. Keep your own actions in the first person singular throughout.
Follow-up
- What was the hardest moment for the team, and what did you do about it?
- How did you handle a teammate who was falling behind?
- What would the outcome have been without your contribution?
How do you handle conflicts within a team environment?
How do you handle conflicts within a team environment?
Approach
- Use a real conflict, ideally a technical disagreement such as an architecture choice, a review dispute or a priority clash. Answering that you avoid conflict, or that you have never had one, does not work.
- Show how you understood the other side first: what they cared about and what information they had that you did not.
- Explain how you moved the decision to evidence or agreed criteria: a quick prototype, a benchmark, or a written comparison. Say when you would escalate to a lead.
- Close with the outcome and the state of the working relationship afterwards, including any point where you were the one who changed your mind.
Follow-up
- Tell me about a time you were wrong in a disagreement.
- What do you do if the conflict is with someone more senior?
- How do you disagree in a code review without stalling the work?
Describe a situation where you had to adapt your communication style to effectively collaborate with others.
Describe a situation where you had to adapt your communication style to effectively collaborate with others.
Approach
- Pick a clear audience shift, for example explaining an outage or a delay to operations or product staff after discussing the same issue with engineers.
- Name the specific changes you made: dropping jargon, leading with impact and options before the cause, using a diagram or analogy, switching to a written summary, or changing how often you sent updates.
- Show the evidence that it worked: a decision made faster, fewer follow-up questions, or a stakeholder repeating the plan back correctly.
- Say what you learned about that audience and how you communicate with them now.
Follow-up
- How do you explain a technical risk to someone who only wants a yes or no?
- What is a time your communication failed, and what did you change?
- How do you keep a distributed team aligned on a project?
How do you ensure that your work aligns with the company’s values and mission?
How do you ensure that your work aligns with the company’s values and mission?
Approach
- Learn what the company builds before the interview (candidates describe software for vending and retail). Connect your answer to the people who use it, not to slogans.
- Candidates report culture-fit questions touching teamwork, innovation and customer focus. Pick one of those and show it with a past decision, such as choosing reliability for end users over a faster release, or picking up a support issue outside your area.
- Explain how you check alignment in daily work: tying tasks to the user problem behind the ticket, and asking why when the goal of a feature is unclear.
- Avoid generic praise of the company. One concrete story is worth more than a list of values.
Follow-up
- Tell me about a time a request conflicted with what you thought was right for users.
- What would you do if you disagreed with a product direction?
- What do you know about how the product is used day to day?
What motivates you to perform at your best in a challenging workplace?
What motivates you to perform at your best in a challenging workplace?
Approach
- Name one or two motivators that are true and specific to engineering work, such as shipping something people use, solving a hard bug, or learning a new part of the stack.
- Back it with a hard period: what made it difficult, what kept you going, and what you delivered.
- Show how you sustain performance: breaking work into small wins, asking for help early, and protecting focus time. Do not claim that pressure itself motivates you without an example.
- Link it to this role: building and fixing software that retail users and operations staff depend on.
Follow-up
- What demotivates you, and how do you handle it?
- Tell me about a time your motivation dropped on a project.
- What kind of work would you not want to do in this role?
- 01
Tell me about a time you had to work closely with a team to achieve a common goal.
- 02
How do you handle conflicts within a team environment?
- 03
Describe a situation where you had to adapt your communication style to effectively collaborate with others.
- 04
How do you ensure that your work aligns with the company’s values and mission?
- 05
What motivates you to perform at your best in a challenging workplace?
- 06
Describe a time when you encountered a significant technical obstacle. How did you resolve it?
How many rounds is the 365 Retail Markets Software Engineer interview process?
Candidates report three stages over about 3-5 weeks: an Initial Screening Interview on resume details and basic technical questions, Technical Interviews (one or more) with coding challenges and deeper technical discussion, and a Stakeholder Interaction stage with technical leads and team members. Candidates also mention that the process can vary slightly by team.
365 Retail Markets Software Engineer candidate reports ↗What topics come up in the 365 Retail Markets Software Engineer interview?
Candidates list AI / Machine Learning concepts, software engineering problem solving, technical fundamentals, usage and understanding of technologies, and standard technical interview preparation. The reported questions are mostly fundamentals: stack versus queue, binary search, sorting complexity, testing, REST APIs, debugging, code quality and performance. The rest are problem-solving cases and behavioral prompts.
365 Retail Markets Software Engineer candidate reports ↗Which programming language should I use?
The requirements candidates describe ask for Java, C# or Python, plus web technologies (HTML, CSS, JavaScript) and SQL. Code in the one you know best from that list and make sure you can write a queue, a stack and both binary search variants in it without an IDE. If your strongest language is not on the list, prepare to explain how quickly you have picked up a new language before.
PracHub Software Engineer practice ↗Is a specific coding problem reported?
No. Candidates report an open coding challenge without naming the problem, alongside fundamentals questions on data structures, searching, sorting and testing. Prepare the process (clarify, brute force, optimise, test edge cases, state complexity) on medium array, string, hash-map and graph problems, and drill the reported fundamentals until you can write them correctly on the first attempt.
PracHub Software Engineer practice ↗Do I need machine learning knowledge for this Software Engineer role?
AI / Machine Learning concepts appear among the topics candidates list, and the requirements treat ML and AI knowledge as a nice-to-have, not a must-have. None of the reported questions is an ML question. Cover the basics so you can discuss them: supervised versus unsupervised learning, train and test splits, overfitting and regularisation, and precision versus recall. If you have integrated a model or an AI service into an application, prepare that story.
PracHub Software Engineer practice ↗How should I prepare for the Stakeholder Interaction stage?
Candidates describe it as meeting several stakeholders, including technical leads and team members. Prepare STAR stories on teamwork, conflict and adapting your communication. Practise explaining one technical decision to both an engineer and a non-technical listener. Bring separate questions for leads (code review, testing, releases) and teammates (sprint rhythm, how bugs and requests reach the team).
PracHub Software Engineer practice ↗Should I study cloud and DevOps topics?
The requirements list AWS or Azure and DevOps practices as nice-to-haves, and candidate descriptions mention CI/CD, Git and dependency management. Be ready to describe a pipeline you have used end to end (build, test, deploy, rollback), your Git branching and review workflow, and how you pin and update dependencies. Deep cloud architecture is not among the reported questions.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01365 Retail Markets Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
XPeng Motors Software Engineer Interview Guide
What XPeng Motors asks Software Engineer candidates, from reported rounds and questions.
X Development Software Engineer Interview Guide
What X Development asks Software Engineer candidates, from reported rounds and questions.
Virtualitics Software Engineer Interview Guide
What Virtualitics asks Software Engineer candidates, from reported rounds and questions.
University of Southern California Software Engineer Interview Guide
What University of Southern California asks Software Engineer candidates, from reported rounds and questions.