The reported questions fall into five groups: general technical questions (a hard problem you solved, your languages, MVC, code quality, a technology trend), problem-solving cases (a slow application, a high traffic web application, debugging a complex system issue), behavioral prompts, three coding fundamentals, and two design prompts (a URL shortening service and a scalable e-commerce platform). Topics candidates list for the loop are programming problem solving, code writing exercises, technical project discussion, software engineering fundamentals and resume-based technical discussion.
Two things follow from that mix. First, a good share of the loop is you talking about your own work, so every project on your resume needs a short account of the problem, your part, the technical choices and the result. Second, the coding questions reported are classic fundamentals: reverse a linked list, find two numbers that add up to a target, and compare a stack with a queue. Candidates describe the difficulty as average to easy, which makes clean, correct code and clear explanation the goal rather than exotic algorithms.
Because the role is about a shopping website, performance and reliability cases are worth extra rehearsal. For the slow application and high traffic questions, practise a fixed order: measure first, find the bottleneck (database queries, missing indexes, repeated calls, no caching, blocking work in the request path), fix the largest cost, then verify with the same measurement. Since the requirements mention MySQL and MongoDB, be ready to discuss indexes and query shape in at least one of them.
The Leadership Interview is reported to involve someone such as the CIO. Prepare to describe technical work in terms of what it changed for users or the business, and keep stories ready about collaborating with a hard colleague, prioritising under a deadline and leading a project.
Phone Screen
reportedCandidates report that the first stage is a call with a recruiter about your background and fit for the role. No technical questions are reported for this call, so treat it as a conversation about your resume and the role's listed requirements: one programming language, a web framework and a database. Have a clear, short account of what you have built and why a retailer of photography, video and electronics interests you.
What to demonstrate
- Your background against the requirements candidates describe: a language such as Java or Python, a framework such as React or Angular, a database such as MySQL or MongoDB
- How clearly you summarise your experience and your reason for applying
- Logistics fit, including questions about the later stages
How to prepare
- Write a short walkthrough of your career with one line per project: the problem, your part and the result.
- Match your stack to the listed requirements and note any gap (for example MongoDB if you only used MySQL) with the closest thing you have done.
- Prepare your answer to 'What programming languages are you most comfortable with, and why?' and tie it to a project you shipped.
- Write questions for the recruiter: what the technical sessions contain, who conducts them, and how flexible the working arrangement is for the team.
Technical Interviews
reportedCandidates report several sessions in this stage: discussions with team members and technical assessments. Reported topics for the loop include programming problem solving, code writing exercises, technical project discussion, software engineering fundamentals and resume-based technical discussion. Reports do not tie particular questions to particular sessions, so prepare every type: the coding fundamentals, the explain-and-compare questions, the performance and debugging cases, and the two design prompts.
What to demonstrate
- Working code written live, since code writing exercises are a reported topic
- Command of fundamentals such as MVC, stacks and queues, and code quality practices
- Ability to discuss your own projects and technical decisions in detail
- Structured reasoning on performance, debugging and design cases
How to prepare
- Write reverse a linked list (iterative and recursive), two-sum (hash map) and a stack versus queue explanation in your main language without an IDE helper.
- Prepare spoken answers for MVC, code quality and maintainability, and a recent technology trend, each tied to a project you worked on.
- Rehearse a fixed sequence for the slow application, the high traffic web application and the complex system bug: measure, locate, fix, verify.
- Sketch both design prompts, the URL shortening service and the scalable e-commerce platform, with requirements, data model, read and write paths and failure handling.
Leadership Interview
reportedCandidates report an interview with leadership, such as the CIO, to assess fit and skills. Reported behavioral prompts cover working with a difficult team member, prioritising under tight deadlines and leading a project, and candidates also report being asked about a recent technology trend. Expect to describe your work at a higher level than in the technical sessions: what the problem was, why it mattered, what you decided and what happened.
What to demonstrate
- Overall fit and skills for the Software Engineer role, as the stage is described
- Teamwork and communication, which candidates list as evaluation areas
- How you explain technical work and decisions to a senior, non-peer audience
How to prepare
- Build three stories with a clear result and your own decisions in them: a difficult collaborator, a deadline you had to prioritise under, and a project you led.
- Prepare a short answer on a recent technology trend that connects it to something you have actually built or would apply to a shopping website.
- Practise explaining one project in business terms first (customer, cost, reliability) and technical terms second.
- Prepare two questions for leadership about the engineering roadmap and how the team works with product managers.
PracHub editorial advice for the preparation topics above.
Losing the rest of the list while reversing it
In the reverse-a-linked-list question, save the next node before you repoint the current one, keep previous, current and next pointers, and test an empty list, a single node and two nodes. Know the recursive version too and say it costs O(n) stack space against O(1) for the iterative one.
Giving the nested-loop answer to the two-numbers-that-add-up-to-a-target question and stopping
State the O(n squared) version, then move to a hash map of seen values for O(n) time and O(n) space. Settle duplicates, using the same element twice, no valid pair and what you return before you write code.
Answering the slow application and high traffic cases with a list of fixes such as 'add a cache' without measuring
Open with how you would find the bottleneck: profile or trace the request path, check slow queries and missing indexes, N+1 queries and blocking calls. Pick the biggest cost, fix it, and re-measure. Then discuss caching, queues and horizontal scaling with the trade-offs each brings.
Telling project stories that stay at team level, so your own contribution and decisions never appear
Technical project discussion and resume-based discussion are reported topics. For each project, prepare the problem, your specific part, one technical decision with the alternative you rejected, and the result.
Jumping into boxes and arrows on the URL shortening and e-commerce design prompts
Start from requirements and rough load, then separate the read path from the write path. For the URL shortener cover key generation, collisions, redirect latency and caching. For the e-commerce platform cover catalog and search, cart, checkout and inventory consistency, and what happens when a dependency is down.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Write a function to reverse a linked list.
Write a function to reverse a linked list.
Approach
- Iterative three-pointer reversal: prev = null, curr = head; while curr is not null, save next = curr.next, set curr.next = prev, move prev = curr and curr = next; return prev. O(n) time, O(1) extra space.
- Recursive version: reverse the rest of the list, then set head.next.next = head and head.next = null, and return the new head from the base case. Still O(n) time, but O(n) call-stack depth, which can overflow on long lists (CPython's default recursion limit is 1000).
- Edge cases: an empty list returns null, a single node returns itself, and a two-node list makes a good dry run. Check that the old head's next ends up null so the result has no cycle.
- Test it by building a list from an array, reversing it, walking the result back into an array, and comparing that with the reversed input. For a doubly linked list, swap prev and next on every node and return the old tail.
Follow-up
- Reverse only the nodes between positions m and n in one pass.
- Reverse the list in groups of k nodes, leaving a final short group as it is.
- Check whether the list is a palindrome using O(1) extra space.
Given a list of integers, find two numbers that add up to a specific target.
Given a list of integers, find two numbers that add up to a specific target.
Approach
- Clarify first: return indices or values, exactly one answer or possibly none, whether duplicates appear, whether one element may be used twice, whether the input is sorted, and whether negatives are allowed.
- Brute force: check every pair with two nested loops, O(n^2) time and O(1) space. State it, then improve it.
- One-pass hash map from value to index: for each x at index i, if target - x is already in the map return (map[target - x], i), otherwise store x -> i. O(n) average time and O(n) space. Checking before inserting stops an element pairing with itself and still handles [3, 3] with target 6.
- Alternative: sort, then move two pointers inward from both ends. O(n log n) time and no hash map, but sorting loses the original indices unless you sort (value, index) pairs. On input that is already sorted it runs in O(n).
- Edge cases: return an explicit empty result when there is no pair, and in Java watch for int overflow in target - x near the type's limits (use long).
Follow-up
- Return all unique pairs that sum to the target, without duplicates.
- Design a structure with add(number) and find(target) for a stream of numbers, and say which operation you make cheap.
- Count the pairs whose sum is below the target in a sorted array.
Explain the difference between a stack and a queue, and provide examples of their use cases.
Explain the difference between a stack and a queue, and provide examples of their use cases.
Approach
- Define both precisely. A stack is LIFO: push, pop and peek all work at the top in O(1). A queue is FIFO: enqueue at the back and dequeue at the front, both O(1) with the right implementation.
- Implementation details: a dynamic array gives a stack amortized O(1) push. A queue needs a linked list or a circular buffer. In Java, use ArrayDeque for both, because Stack is a legacy synchronized class that extends Vector. In Python, use a list for a stack (append/pop) and collections.deque for a queue, since list.pop(0) is O(n).
- Stack use cases: the function call stack, undo history, matching brackets, iterative DFS, expression evaluation, and the browser back button.
- Queue use cases: BFS, job and message queues (for example order events processed by background workers), print spooling, and buffering requests under load. A priority queue is a heap ordered by priority, not a FIFO queue.
- Know the classic conversion: a queue built from two stacks moves items from the inbox stack to the outbox stack only when the outbox is empty, which gives amortized O(1) per operation.
Follow-up
- Implement a queue with two stacks and explain why the cost is amortized O(1).
- Design a stack that also returns its minimum in O(1).
- When would you use a deque or a priority queue instead?
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?
Find version gaps and relay lag with window functions
outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.
Approach
- Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
- Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
- Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
- Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.
Follow-up
- Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
- Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?
Describe a challenging technical problem you faced and how you resolved it.
Describe a challenging technical problem you faced and how you resolved it.
Approach
- Pick a problem whose difficulty was technical and where you owned the diagnosis: a race condition, a query that degraded as a table grew, a memory leak, a flaky integration. Say in one line what made it hard: no reproduction, legacy code with no tests, or a production-only symptom.
- Give the impact in numbers (error rate, p95 latency, failed orders, hours lost), then the hypotheses you considered and the evidence that ruled each one out. That middle part should take most of the answer.
- Name the actual tools: a profiler, EXPLAIN output, a heap dump, logs joined on a request id, git bisect. 'I looked into it' tells the listener nothing.
- Explain the fix and the alternative you rejected, with the trade-off: for example an index that slows writes slightly, against a cache that adds staleness.
- Close with how you verified it (the same metric before and after) and what stops it recurring: a regression test, an alert or a runbook entry. Keep your own part separate from the team's.
Follow-up
- How did you confirm the root cause rather than a change that happened at the same time?
- Which fix did you reject, and would you still reject it today?
- What would you do differently if the same symptom appeared tomorrow?
What programming languages are you most comfortable with, and why?
What programming languages are you most comfortable with, and why?
Approach
- Name one or two languages you would actually code in during the loop, each tied to a real project. The requirements candidates describe for this role list Java and Python, with React or Angular for the web side, so say plainly where your experience overlaps with that list and where it does not.
- Give technical reasons rather than taste: static typing, generics and JVM tooling in Java; fast iteration and type hints checked by mypy in Python; the component model and the async event loop in JavaScript.
- Show that you know each language's concurrency model. Java has threads, ExecutorService and CompletableFuture. In standard CPython builds the GIL stops threads running Python bytecode in parallel, so CPU-bound work goes to multiprocessing and I/O-bound work to asyncio or threads.
- Name a pitfall you have hit in your main language: Python's mutable default arguments, Java's equals/hashCode contract for HashMap keys, JavaScript's == coercion or a lost
thisbinding. - Finish with how you pick up a new language: idioms, the standard library and the test framework first, then a small real feature.
Follow-up
- Which language would you choose for a new web service here, and what would make you change that choice?
- What bug has your strongest language's design caused you?
- How does your main language handle concurrent I/O?
How do you ensure code quality and maintainability in your projects?
How do you ensure code quality and maintainability in your projects?
Approach
- Describe layers, not a single habit: unit tests for logic, integration tests at the database and API boundaries, a few end-to-end tests on the main user flows, all run in CI on every pull request. Treat coverage as a signal, not a target.
- Automate the mechanical checks so review time goes to design: a formatter and linter (Prettier and ESLint, Checkstyle or SpotBugs, black or ruff), plus a type checker where the language has one, all enforced in CI.
- Code review: small pull requests, a clear description of intent, a test for every bug fix, and review comments about naming, error handling and boundaries rather than style.
- Design for change: single responsibility, explicit module boundaries, dependency injection so code can be tested without a real database, and no abstraction until a second use case exists. Refactor behind tests, and track tech debt as tickets rather than leaving it in comments.
- Back it with one example and an outcome: fewer production bugs, a flaky suite you stabilised, or review turnaround you cut.
Follow-up
- How do you deal with a flaky test that blocks the pipeline?
- How would you add tests to a legacy module that has none?
- When is it right to ship with known tech debt?
Discuss a recent technological trend that interests you and how it relates to your work.
Discuss a recent technological trend that interests you and how it relates to your work.
Approach
- Choose a trend you have actually used, not one you have only read about: AI coding assistants, React Server Components, OpenTelemetry-based observability, containers and managed Kubernetes, or edge caching and edge functions.
- Explain the mechanism in a sentence or two to show you understand it. For example, React Server Components run on the server and send a serialized result to the client, so their code is never shipped in the browser bundle.
- Connect it to your own work with something concrete: what you tried, what you measured (bundle size, build time, time to diagnose an incident) and what you decided.
- State the costs and limits. AI assistants write plausible but wrong code, so review and tests carry more weight. Tracing adds overhead and cardinality cost. Kubernetes adds operational load that a small team may not need.
- Tie it to the work candidates describe for this role, web applications for online shopping, for example through page performance, reliability or developer speed.
Follow-up
- What would stop you from adopting it on a production team?
- How would you measure whether it paid off?
- What does a team need to put in place before rolling it out?
How would you optimize a slow-running application?
How would you optimize a slow-running application?
Approach
- Define slow first: which page or endpoint, p50 against p95/p99 latency, since when, and for which users. Take a baseline measurement before changing anything.
- Find where the time goes before fixing anything. Split a request into browser rendering (bundle size, LCP), network, application code, database and external calls, using tracing or an APM tool and a profiler (Chrome DevTools Performance, py-spy, Java Flight Recorder).
- Database fixes come up most often: run EXPLAIN to find full scans and add a composite index that matches the WHERE and ORDER BY, remove N+1 queries with a join or batch loading, and replace deep OFFSET paging with keyset paging.
- Then cache and defer: CDN and HTTP caching for static assets and images, an application cache such as Redis with a TTL and an explicit invalidation path for hot reads, and a queue for slow work that does not need to happen before the response.
- Change one thing at a time, measure it against the baseline, and load-test. Name the costs: every index slows writes, and every cache adds staleness and an invalidation bug to guard against.
Follow-up
- How would you detect N+1 queries in an ORM-heavy codebase?
- It is fast in staging and slow in production: what differs, and what do you check first?
- What would you cache on a product page, and how do you invalidate it when the price changes?
Given a scenario with a high traffic web application, how would you ensure performance and reliability?
Given a scenario with a high traffic web application, how would you ensure performance and reliability?
Approach
- Clarify the load and the targets: peak requests per second, read/write ratio, how spiky traffic is (sale events), and latency and availability objectives. Those numbers decide everything after.
- Scale the read path: stateless app servers behind a load balancer with autoscaling, a CDN for static assets and cacheable pages, Redis for hot data, read replicas and connection pooling for the database, and a queue for work that can wait (emails, analytics).
- Design for failure: health checks and instances spread across availability zones; timeouts on every outbound call; retries with exponential backoff and jitter only on idempotent operations; circuit breakers; rate limiting; and graceful degradation, so checkout keeps working when recommendations are down.
- Observe and release safely: rate, errors and duration per service, distributed tracing, alerts on SLO burn, load tests before known peaks, and canary or blue-green deploys with fast rollback behind feature flags.
- Name the trade-offs: replica lag breaks read-after-write (route reads that follow a write to the primary), and a cache miss storm on a hot key needs request coalescing or jittered TTLs.
Follow-up
- The cache cluster fails during peak traffic: what happens to the database, and how do you protect it?
- Traffic jumps tenfold in minutes: which component saturates first?
- A customer places an order and the order page does not show it: what causes that, and how do you fix it?
Design a URL shortening service. What considerations would you make?
Design a URL shortening service. What considerations would you make?
Approach
- Requirements: create a short code for a long URL, redirect from the code, and optionally support custom aliases, expiry and click counts. Redirects far outnumber creates, so optimise the read path. State your own traffic and storage assumptions out loud.
- API: POST /urls with the long URL returns the code; GET /{code} redirects. A 301 is permanent and browsers cache it, which cuts load but hides repeat clicks. A 302 sends every click through the service, which keeps analytics accurate.
- Key generation: base62-encode a unique id, from a database sequence or from id ranges handed out to each server so they need no coordination. Seven base62 characters give 62^7, about 3.5 trillion codes. Sequential ids can be enumerated, so shuffle or encrypt them if that matters. Hashing the URL and truncating needs a collision check on insert.
- Storage and reads: a key-value lookup on the code as primary key (MySQL with a unique index, or a key-value store), partitioned by a hash of the code, with Redis in front for hot codes. Redirects never touch the write path.
- Operations: rate-limit creation and check destination URLs to block abuse, clean up expired codes, and send click events to a queue so analytics never slows a redirect.
Follow-up
- The same long URL is submitted twice: same code or a new one, and why?
- How do you count clicks per code accurately without adding latency to redirects?
- The id allocator goes down: what keeps code creation working?
How would you architect a scalable e-commerce platform?
How would you architect a scalable e-commerce platform?
Approach
- Scope it: catalog browsing and search, product pages, cart, checkout, payment, orders, inventory and accounts. Browsing is read-heavy and spiky, while checkout must be correct, so treat the two paths differently.
- Components: a CDN for images and static assets; a catalog service with a read-optimised store and a search index (Elasticsearch or OpenSearch) fed by change events; a cart keyed by user or session in Redis or a document store; orders in a relational database such as MySQL with transactions; and payments through an external provider called with idempotency keys.
- Inventory without overselling: decrement with a conditional update (UPDATE inventory SET qty = qty - 1 WHERE sku = ? AND qty >= 1, then check rows affected), or hold reservations that expire. The stock count shown on a page can be eventually consistent; the decrement cannot.
- Asynchronous flow: an order-placed event goes to a queue for confirmation emails, fulfilment and analytics. Use a transactional outbox so the database write and the event cannot diverge, and make consumers idempotent because messages can be delivered twice.
- Scale and resilience: stateless services that autoscale, cached catalog pages, read replicas, orders sharded by order or customer id once one database is not enough, and degraded modes such as hiding recommendations or falling back on search. Start as a modular monolith and split services where scaling or team boundaries require it.
Follow-up
- How do you prevent overselling during a flash sale on one popular item?
- The payment provider times out after possibly charging the card: what does your system do?
- A price changes: how do the cache, the search index and the cart stay consistent?
Describe your approach to debugging a complex system issue.
Describe your approach to debugging a complex system issue.
Approach
- Start with scope and impact: the exact symptom, who is affected, since when, and which component it shows up in. If it is in production, mitigate first (roll back, turn off a feature flag, shed load) and find the root cause after.
- Build a timeline of what changed: deploys, config, dependency versions, traffic shape, data volume. Check that the alert or dashboard is measuring correctly before trusting the symptom.
- Narrow it with evidence: logs joined on a request or trace id, distributed tracing to find the failing or slow hop, and metrics broken down by host, region, version or customer to see whether the failure is concentrated somewhere.
- Reproduce it in a lower environment or as a minimal case, then bisect: git bisect over commits, or turn components off one at a time. Each hypothesis should predict something you can check.
- Fix, confirm with the same metric that showed the problem, add a regression test and an alert, and write a blameless postmortem with follow-up actions.
Follow-up
- The issue is intermittent and you cannot reproduce it: what do you instrument?
- How do you tell the actual cause from a deploy that happened at the same time?
- The logs you need were never written: how do you proceed?
The plan moves from your own project stories to the reported coding fundamentals, then explain-and-compare topics, performance and debugging, design, and behavioral prompts, and ends with a full mock of the three rounds.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the three rounds and your project inventory
- Write the reported sequence (Phone Screen, Technical Interviews, Leadership Interview) and list what you will be asked to talk about at each.
- List every project on your resume with its stack, your role, one technical decision and the result.
- Write out your answer to the challenging technical problem question in a problem, action, result shape, using the strongest project.
Deliverable: A one-page loop map, a project inventory table, and a written answer to the challenging technical problem question.
Practice prompt ↗02Coding fundamentals in your main language
- Write reverse a linked list iteratively and recursively, and test it on empty, single-node and longer lists.
- Write the two-numbers-that-add-up-to-a-target solution with a hash map, and handle duplicates and the no-answer case.
- Write a stack and a queue, with use cases for each (undo and call stacks against task queues and breadth-first search).
Deliverable: Three working, tested solutions plus a short comparison of stack and queue with two use cases each.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Fundamentals and personal technical stories
- Write a model, view, controller trace for one request in a framework you used, including where validation lives.
- Write a short answer on how you keep code quality and maintainability high: reviews, tests, naming, small changes.
- Write your language answer and a technology trend answer, each tied to something you built.
Deliverable: Four spoken-length answers (MVC, code quality, languages, trend), each referring to a real project.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗04Performance and debugging cases
- Write a bottleneck checklist for the slow application: measure, trace, queries and indexes, N+1, caching, blocking work.
- Add what changes for the high traffic web application: horizontal scaling, caches, queues, graceful degradation, monitoring.
- Write a debugging sequence for a complex system issue: what changed, reproduce, bisect, confirm the cause, add a regression test.
- Work PracHub's keyset-paging SQL practice drill to rehearse a query-shape fix for slow list pages.
Deliverable: A one-page performance playbook and a debugging sequence, plus the completed keyset-paging drill.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗05System design prompts
- Design the URL shortening service: requirements, key generation, storage, redirect path, caching and collisions.
- Design a scalable e-commerce platform: catalog and search, cart, checkout, inventory consistency, database choice.
- For each design, write what breaks first at ten times the traffic and how you would find out.
Deliverable: Two annotated design sketches, each with a failure and scaling note.
Practice prompt ↗Practice prompt ↗06Behavioral stories
- Write a story for collaborating with a difficult team member, centred on behaviour and the working change you agreed.
- Write a prioritisation story with a scope cut you negotiated, and your general method in three sentences.
- Write a project-lead story with the goal, your decisions, a hard moment and a result you can verify.
Deliverable: Three structured stories, each with your own decisions, an outcome and one thing you would do differently.
Practice prompt ↗Practice prompt ↗Practice prompt ↗07Full mock of the three rounds
- Run a recruiter-call mock: resume walkthrough, language answer, and your questions for the recruiter.
- Run a technical block: one coding problem written live, one performance case and one design prompt, spoken out loud.
- Run a leadership-style conversation: one project in business terms, one behavioral story and the trend answer.
Deliverable: A list of the weakest answers from the mock, each with a rewritten version.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report a Leadership Interview with someone such as the CIO, and behavioral prompts about collaboration, prioritisation and leading a project. Teamwork and communication are also listed among the evaluation areas. Prepare stories where you made the decisions, with an outcome you can verify, and practise explaining technical work in terms of customers and the business.
Explain the MVC architecture and your experience with it.
Explain the MVC architecture and your experience with it.
Approach
- Define the three parts in one breath: the model holds data and business rules, the view renders the output, and the controller receives the request, calls the model and chooses the view. Then trace one request, such as adding an item to a cart: route to controller, controller calls a service that checks stock and saves, then a template or JSON response.
- Anchor the answer in a framework you used (Spring MVC, Django, Rails, ASP.NET MVC, Express with a template engine) and say where your files lived. Note that Django names its pattern model-template-view, which shows you know the pattern is looser than the acronym.
- Show judgment: keep controllers thin, put business rules in the model or a service layer so they can be unit tested without HTTP, and keep logic out of templates. Name the failure modes, namely a fat controller and an anemic model that is only a bag of fields.
- Compare with relatives: MVP and MVVM, and component-based front ends like React or Angular, where the view is derived from state and the controller role is split between components, services and the server API.
- Close with one concrete experience of your own, such as moving pricing or validation logic out of a controller into a service so it could be tested and reused, and say what it improved.
Follow-up
- Where do input validation and authorization belong in an MVC application?
- How does the pattern change when the front end is a single-page app talking to a JSON API?
- How would you unit test a controller, and what would you mock?
Tell me about a time you had to collaborate with a difficult team member.
Tell me about a time you had to collaborate with a difficult team member.
Approach
- Choose a conflict that affected the work, such as slow or dismissive code reviews, missed handoffs or repeated unresponsiveness, and describe it by behaviour and impact. Do not label the person; a story built on 'he was impossible' reads as blame.
- Use a STAR shape with little time on the situation: your first action should be a private, direct conversation where you ask what is driving their behaviour (constraints, priorities, a different view of the design) and restate the shared goal.
- Show a concrete working change you agreed on, such as review turnaround, a written interface contract, or recording design decisions in the ticket, rather than a vague 'we got along better'.
- Show escalation judgment: say when you involved your lead or the product manager and why, after the direct attempt and not in place of it.
- Report the result in work terms (delivery, rework, review quality) and name what you changed in your own approach. Stories where you win by going around the person sink the answer.
Follow-up
- What would you have done if the conversation had not changed anything?
- At what point is it right to bring in your manager?
- What did the situation teach you about your own part in it?
How do you prioritize tasks when faced with tight deadlines?
How do you prioritize tasks when faced with tight deadlines?
Approach
- Lead with your method and prove it with a story: list everything due, estimate effort, then rank by impact on customers or the business, how firm each deadline is, what blocks other people, and the risk of getting it wrong.
- Make the cost visible. Tell the product manager or lead what fits, what does not, and offer a scope cut (ship the core path first, defer polish) instead of quietly working longer hours.
- Protect verification inside the reduced scope: cut features, not tests and code review on the critical path. For a shopping site, give a concrete ranking example, such as a defect that blocks purchase outranking a new feature.
- Give one real case with what you dropped, who agreed to it and what happened, then say how you re-planned when new information arrived midway.
Follow-up
- Two stakeholders each insist their task comes first. What do you do?
- What exactly did you drop, and who signed off on dropping it?
- What changes if the deadline is moved earlier halfway through?
Describe a situation where you took the lead on a project. What was the outcome?
Describe a situation where you took the lead on a project. What was the outcome?
Approach
- Pick a project where you owned the outcome, even without a manager title, and say in one sentence what the goal and the finish line were.
- Show leadership as actions: you set the scope and done criteria, split the work into pieces matched to people, set checkpoints, made and recorded the key design decisions, unblocked teammates and kept reviews moving.
- Include one hard moment, such as a slipping piece or a disagreement over the approach, and explain how you resolved it with evidence or a trade-off rather than rank.
- State the outcome with facts you can defend: shipped against the plan, defects or latency reduced, adoption by users. If you lack numbers, name the observable result instead of inventing one.
- Use 'I' for your decisions and credit teammates by role for theirs; a story that is all 'the team' hides your contribution, and one that is all 'I' undercuts the lead claim. End with what you would change.
Follow-up
- How did you handle a teammate who fell behind?
- Which decision did you make that others disagreed with, and how did it turn out?
- What would you change if you ran the project again?
- 01
Tell me about a time you had to collaborate with a difficult team member.
- 02
How do you prioritize tasks when faced with tight deadlines?
- 03
Describe a situation where you took the lead on a project. What was the outcome?
- 04
Describe a challenging technical problem you faced and how you resolved it.
- 05
Tell me about a time you changed your approach after feedback in a code review.
How many rounds are there and how long does the loop take?
Candidates report three rounds over about three to five weeks: a Phone Screen, Technical Interviews, and a Leadership Interview. The pace depends on scheduling, so ask the recruiter in the first call what to expect next.
B&H Photo Video Software Engineer candidate reports ↗Who conducts each round?
Candidates report that the Phone Screen is a recruiter call, the Technical Interviews are sessions with team members plus technical assessments, and the Leadership Interview is with leadership, such as the CIO. Ask the recruiter for the names and formats of the sessions on your schedule.
PracHub Software Engineer practice ↗How hard is the loop and how long should I prepare?
Candidates generally describe the difficulty as average to easy, and some suggest one to two weeks of preparation. The seven-day plan in this guide covers the reported coding fundamentals, performance and debugging cases, two design prompts and the behavioral prompts.
B&H Photo Video Software Engineer candidate reports ↗Which languages and tools should I review?
The requirements candidates describe name one language such as Java or Python, a web framework such as React or Angular, and databases such as MySQL or MongoDB. AWS or Azure, DevOps tools and Agile practice are listed as extras. Be ready to write code in your strongest language and to discuss a project that used a framework and a database.
PracHub Software Engineer practice ↗What coding questions do candidates report?
The reported coding questions are reversing a linked list, finding two numbers in a list that add up to a target, and explaining stacks versus queues with use cases. Practise writing each one without autocomplete, state time and space complexity, and test edge cases aloud.
PracHub Software Engineer practice ↗Do I need e-commerce experience?
Candidates describe the target as roughly three to five years of experience, ideally in e-commerce or retail technology. If you lack retail experience, translate your projects into shopping-site terms such as catalog browsing, search, cart and checkout reliability, and use the e-commerce design prompt to show that thinking.
PracHub Software Engineer practice ↗Is the role remote or on-site?
Candidates report that remote work exists but expectations vary by team. Ask the recruiter during the Phone Screen about the arrangement for the specific team.
B&H Photo Video Software Engineer candidate reports ↗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.
- 01B&H Photo Video 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.
Cognition Software Engineer Interview Guide
What Cognition asks Software Engineer candidates, from reported rounds and questions.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Together Ai Software Engineer Interview Guide
Failure-handling practice for Together Ai software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Spotify Software Engineer Interview Guide
Timed practice for Spotify software engineer candidates who lose time to the clock: short problems taken end to end, then reviewed against a written rubric rather than a passing test run.