Benchmark IT Solutions Software Engineer Interview Guide

The 60-second brief

Benchmark IT Solutions is described by candidates as a company that delivers client-facing and internal software projects across varied project domains. The Software Engineer role covers building and maintaining that software in a Java, .NET or PHP stack, with Spring Boot and ASP.NET MVC named as example frameworks and MySQL as the database the role lists. Engineers are described as taking part in the full software development life cycle and working with cross-functional teams, so the day job mixes writing code, reading older code and talking to people who are not engineers.

This guide is for candidates applying to Benchmark IT Solutions as a Software Engineer in a Java, .NET or PHP background. It covers the four reported stages, the twelve reported questions (sorting, OOP, exceptions, Java 8 features, 3-tier versus MVC, MySQL normalization, JOINs, RDBMS concepts, JDBC and JPA/Hibernate, the SDLC, project walkthroughs and maintainable code) and a seven-day plan. Technical answers are written with Java examples first, with notes where .NET or PHP differ.

Candidates report four stages over roughly three to five weeks: Initial Screening, Technical Deep-Dives, Practical Assessments (hands-on machine tests) and Final Managerial Rounds. Some candidates describe the whole process finishing in a single day.

Focus areas

• SQL
• Object-Oriented Programming (OOP)
• Spring Framework

Overview

The reported question list is a fundamentals list. Sorting algorithms, OOP with real-life examples, the exception hierarchy, Java 8 features, 3-tier versus MVC, normalization, JOIN types, RDBMS concepts and JDBC or JPA/Hibernate are all questions where a rehearsed definition is easy to give and a concrete example is harder. Prepare each one as a short definition followed by an example from code you have written, because candidates report that fundamentals such as JOINs and OOP are where answers most often fall apart.

The practical stage is a hands-on machine test. Candidates describe being asked to correct existing code or build a small feature, and the advice they pass on is to practise small CRUD modules or a simple API in your main stack, and to get comfortable writing code without leaning on IDE autocomplete. That makes this guide's plan include real build sessions against MySQL, not only reading about it.

Project depth is the third pillar. Candidates report being asked detailed questions about every project on the resume, including the architecture and what you personally contributed. Pick two projects, write down the components, the data model, one bug or bottleneck you fixed and one trade-off you made, and rehearse them aloud. The final stage is with management and is described as covering cultural fit and decision-making, so the same stories need to show how you reached a decision and who you worked with.

The Benchmark IT Solutions interview process

These are the four stages candidates describe, in the order they report them; teams and projects vary, so treat the sequence as typical rather than fixed.

Initial Screening

Candidates describe the first stage as a high-level technical screen that checks overall competence. No specific questions are tied to it in the reports, but the fundamentals list (OOP, sorting, JOINs, RDBMS concepts, the SDLC) is the natural material for a broad screen. Approach it as breadth: a clear one-paragraph answer on each core topic, then a concrete example if asked to go further.

What to demonstrate

• Breadth across language basics, OOP and database fundamentals
• Whether you can state a concept briefly and accurately
• How clearly you describe the stack you work in

How to prepare

• Write a two-sentence answer for each fundamentals question (OOP, exceptions, JOIN types, normalization, SDLC) and say it aloud without notes.
• Prepare a 90-second walk through your resume that names the stack you will use in the machine test, whether Java, .NET or PHP.
• Pick the language you will answer in and stay consistent; if you choose Java 8, be ready with lambdas, streams, Optional and default methods.

Technical Deep-Dives

Candidates describe this stage as in-depth technical discussion about your knowledge and experience. The reported evaluation areas include object-oriented programming, framework lifecycle (Spring Boot, Hibernate, ASP.NET), memory management, multithreading, dependency injection, normalization, query optimization and how your code reaches the database. Approach it by going one layer below the definition each time: say what the framework does for you and what it costs.

What to demonstrate

• Depth in your chosen stack beyond naming its features
• Understanding of the framework lifecycle, such as how dependency injection wires beans or how an ORM session manages entities
• Database knowledge: schema design, JOINs and how queries behave under load

How to prepare

• For Spring or ASP.NET MVC, outline one request from controller to database and back, naming each layer.
• Be ready to contrast JDBC with JPA/Hibernate: boilerplate, lazy loading, the N+1 query problem and transaction handling.
• Write one query with an INNER JOIN, a LEFT JOIN and a GROUP BY, then explain which index each one would use.
• Practise the exception hierarchy and the Java 8 feature list as spoken answers with a code example each.

Practical Assessments

Candidates describe hands-on machine tests meant to evaluate coding and problem-solving. Reported tips say the task may be to correct existing code or build a small feature from scratch, that practising a simple API or a CRUD module in your main stack is the best preparation, and that coding without an IDE is worth rehearsing. Approach it by building complete, running features, not fragments, and by narrating your reasoning as you go, since candidates are told to think out loud.

What to demonstrate

• Working code in your primary stack
• Reading and fixing existing code
• Clean, readable structure and sensible naming
• Clear explanation of your reasoning while you code

How to prepare

• Build a CRUD module end to end (entity, repository, service, controller, MySQL table with constraints) and repeat it until it comes out working without lookups.
• Practise on a plain editor or a basic text environment so syntax, imports and build configuration do not slow you down.
• Take an unfamiliar snippet with a planted bug, such as an off-by-one or a swallowed exception, and practise finding it by reading, then by running.
• Keep a short checklist: read the requirement, list inputs and edge cases, write the happy path, run it, then handle failures.

Final Managerial Rounds

Candidates describe the final stage as interviews with management covering cultural fit and decision-making. The reported advice is to stress how you collaborate with others to solve problems, and candidates also say salary discussions often happen around the final HR conversation. Approach it with stories that show a decision, the alternatives you rejected, and the people involved, drawn from the projects you listed on your resume.

What to demonstrate

• Decision-making, shown through the trade-offs in your past projects
• Communication and collaboration with teammates and leads
• Fit with a team-oriented, client-facing working pattern

How to prepare

• Write two project stories in situation, decision, result form, each with the alternative you rejected and why.
• Prepare an example of working with a non-engineer, such as a client or analyst, to turn a vague requirement into a specification.
• Do your own market research and settle on an expectation range and notice period before the conversation, so you are not improvising.
• Prepare questions about team structure, code review practice and which of Java, .NET or PHP the team uses.

Where candidates lose points

Naming one sorting algorithm as 'the most efficient' with no conditions

Answer the sorting question by comparing properties: quicksort averages O(n log n) but is O(n squared) in the worst case, merge sort guarantees O(n log n) and is stable but uses extra memory, heap sort is in place with no worst-case blowup but is not stable, and insertion sort wins on tiny or nearly sorted input. Then say which you would pick for a given input and why.

Giving textbook OOP definitions with no real-life or code example

For each of encapsulation, inheritance, polymorphism and abstraction, prepare one short example from code you have written, such as an abstract Payment class with two subclasses that override a method. Be ready to say when you would prefer composition over inheritance.

Mixing up JOIN types or filtering a LEFT JOIN in the wrong place

Practise INNER, LEFT, RIGHT, FULL and CROSS joins on two tiny tables where you can predict the output. Know that a condition on the right table placed in WHERE turns a LEFT JOIN into an inner join, while the same condition in ON keeps unmatched left rows, and know how to find rows with no match using IS NULL.

Freezing in the machine test because you rely on IDE help, or never running the code

Rehearse building a CRUD module or small API from an empty file in a plain editor. Write the simplest working path first, run it, then add validation and error handling, and say your reasoning aloud as you go.

Listing resume projects you cannot explain in depth

For every project on the resume, write down the architecture, the data model, your own contribution, one problem you debugged and one trade-off you made. Remove technologies you could not answer three follow-up questions about.

Questions & practice

What is the difference between various sorting algorithms and which is the most efficient?

Medium · Technical Foundations and Programming

Approach

1. Refuse the premise of a single winner: 'most efficient' depends on input size, key type, memory budget and whether the sort must be stable. Comparison sorts cannot beat O(n log n) comparisons in the worst case.
2. Quicksort: O(n log n) average, O(n^2) worst case on bad pivots, in place with O(log n) stack when the smaller side is recursed first, not stable. Merge sort: O(n log n) worst case, stable, O(n) extra memory. Heapsort: O(n log n) worst case, O(1) extra memory, not stable, weaker cache behaviour.
3. Insertion sort is O(n^2) but runs in O(n + inversions), so it wins on small or nearly sorted arrays; hybrids such as Timsort and introsort use it for short runs.
4. Counting sort and radix sort run in O(n + k) and O(d(n + k)) for bounded integer or fixed-width keys because they do not compare elements.
5. Tie it to Java: Arrays.sort on primitives uses a dual-pivot quicksort, while Arrays.sort on objects and List.sort use Timsort, which is stable, so sorting records by a second key keeps the earlier order.

Follow-up

• How would you sort a file that does not fit in memory (external merge sort: sorted runs, then a k-way merge with a min-heap)?
• Write the quicksort partition step and explain how pivot choice avoids the O(n^2) case on already sorted input.
• Why does stability matter when you sort by one field and then by another?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

1. One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
2. Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
3. Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
4. If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

• The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
• How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

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?

How do you approach MySQL normalization and table constraints?

Medium · Database and Data Management

Approach

1. Define the normal forms with one example table: 1NF means atomic values and no repeating groups; 2NF removes columns that depend on only part of a composite key; 3NF removes columns that depend on another non-key column (transitive dependency); BCNF requires every determinant to be a candidate key.
2. Work an orders table that repeats customer name and address on every row: split it into customers, orders and order_items, and name the update, insert and delete anomalies the split removes.
3. MySQL constraints: PRIMARY KEY, UNIQUE (InnoDB allows several NULLs in a unique column), NOT NULL, DEFAULT, FOREIGN KEY with ON DELETE RESTRICT, CASCADE or SET NULL (InnoDB only), and CHECK, which is enforced only from MySQL 8.0.16 and parsed but ignored before that.
4. Know the indexing side effects: InnoDB needs an index on a foreign key column and creates one if missing, and the primary key is the clustered index, so a short, stable key keeps secondary indexes small.
5. Give the trade-off: denormalize deliberately for read-heavy reporting tables, and say how the copies stay consistent.

Follow-up

• When have you denormalized, and how did you keep the duplicated data correct?
• What happens when you delete a parent row that child rows reference, under each ON DELETE option?
• How would you add a NOT NULL column with a foreign key to a table that already holds millions of rows?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

• A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
• Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Can you explain OOPs concepts with real-life examples?

Medium · Technical Foundations and Programming

Approach

1. Cover all four pillars with one running example, such as a bank account, instead of four unrelated analogies.
2. Encapsulation: the balance field is private and changes only through deposit and withdraw methods that validate the amount. Abstraction: callers depend on a PaymentMethod interface with pay(amount), not on card or wallet internals.
3. Inheritance: SavingsAccount extends Account and reuses its behaviour while adding interest. Polymorphism: runtime overriding, where an Account reference calls the subclass's calculateInterest through dynamic dispatch, versus compile-time overloading by parameter list.
4. Show judgement: prefer composition when the 'is-a' relationship is weak, and cite the Liskov substitution problem (a Square subclass of Rectangle breaks callers that set width and height independently).
5. Write a ten-line class sketch on the spot; a code example makes the answer checkable where analogies alone do not.

Follow-up

• When would you choose an abstract class over an interface, given that Java 8 interfaces can carry default methods?
• What is the difference between overloading and overriding, and which one is resolved at runtime?
• Give a case where inheritance caused you a problem and composition fixed it.

What are the key features of Java 8 or your primary programming language of choice?

Medium · Technical Foundations and Programming

Approach

1. Lead with lambdas and functional interfaces (a single abstract method, marked with @FunctionalInterface; built-ins Predicate, Function, Supplier, Consumer) plus method references such as String::length.
2. Stream API: intermediate operations (filter, map, flatMap, sorted) are lazy and run only when a terminal operation (collect, forEach, reduce, count) is called. Show one pipeline, such as grouping orders by customer with Collectors.groupingBy and summing amounts.
3. Optional for return values that may be absent (map, orElse, orElseThrow), default and static methods in interfaces, the immutable java.time API (LocalDate, Instant, Duration) replacing Date and Calendar, and CompletableFuture for composing async work.
4. Name the pitfalls: a stream can be consumed only once, parallel streams share the common ForkJoinPool and help only with large CPU-bound work, and Optional is not meant for fields or parameters.
5. If your primary language is C# or PHP, prepare the matching set: LINQ, async/await and generics in C#; typed properties, union types, match expressions and enums in PHP 8.x.

Follow-up

• What is the difference between map and flatMap on a stream?
• If a class implements two interfaces with the same default method, how does it compile (it must override, and can call A.super.method())?
• Rewrite a for-loop that filters and sums a list as a stream, then say which version you would keep and why.

Can you describe the difference between a 3-tier architecture and MVC?

Medium · Technical Foundations and Programming

Approach

1. 3-tier is an architecture split into presentation, business logic and data tiers, often deployable on separate machines, where requests flow strictly in order: the presentation tier never talks to the database directly.
2. MVC is a design pattern for the presentation layer: the Model holds state and domain data, the View renders it and the Controller handles input and picks the view. In classic MVC the view can read the model directly, so the three parts form a triangle rather than a line.
3. They are not alternatives: MVC usually lives inside the presentation tier. In Spring MVC, DispatcherServlet routes a request to a @Controller, which calls a @Service (business tier) that uses a repository (data tier) and returns a model plus view name or JSON.
4. Separate layers (logical code separation) from tiers (physical deployment) because the question often hides that distinction.
5. Say where each concern goes: input validation in the controller, business rules and transactions in the service, SQL only in the repository.

Follow-up

• How do MVP and MVVM differ from MVC?
• Walk through what happens in Spring MVC or ASP.NET MVC from an HTTP request to the response.
• If business logic has leaked into your controllers, how would you move it out safely?

What is the difference between different types of JOINs?

Medium · Database and Data Management

Approach

1. INNER JOIN keeps only matching pairs; LEFT JOIN keeps every left row and fills right columns with NULL; RIGHT JOIN is the mirror; CROSS JOIN is the Cartesian product; a self join joins a table to itself, as in employee to manager.
2. MySQL has no FULL OUTER JOIN: emulate it with a LEFT JOIN UNION ALL a RIGHT JOIN filtered to rows where the left key IS NULL (a plain UNION also removes legitimate duplicate rows).
3. Name the classic bug: a condition on the right table in WHERE turns a LEFT JOIN into an inner join, so put it in the ON clause. NULL keys never match in an equality join.
4. Anti-join for 'customers with no orders': LEFT JOIN orders ON ... WHERE o.id IS NULL, or NOT EXISTS. Avoid NOT IN when the subquery can return NULL, because it then returns no rows.
5. Watch fan-out: joining a one-to-many table before SUM or COUNT inflates totals, so aggregate the child table in a subquery first or use COUNT(DISTINCT).

Follow-up

• Write a query that lists each employee with their manager's name, including employees with no manager.
• Why does a LEFT JOIN with a WHERE filter on the right table return fewer rows than expected?
• How does MySQL execute a join (nested-loop with indexes, hash join from 8.0.18), and which index would you add?

Can you explain the fundamental concepts of RDBMS?

Medium · Database and Data Management

Approach

1. Start with the relational model: data in tables (relations) of rows (tuples) and typed columns (attributes); candidate, primary, composite and foreign keys; referential integrity enforced by foreign keys.
2. ACID with a concrete case such as a funds transfer: atomicity (both updates or neither), consistency (constraints hold), isolation (concurrent transactions do not see each other's partial state), durability (committed data survives a crash, via the redo log in InnoDB).
3. Isolation levels and anomalies: READ UNCOMMITTED allows dirty reads, READ COMMITTED prevents them, REPEATABLE READ (InnoDB's default) prevents non-repeatable reads, SERIALIZABLE prevents phantoms. InnoDB also uses next-key locks under REPEATABLE READ to block most phantoms.
4. Indexes: InnoDB stores rows in a B+tree clustered on the primary key, and secondary indexes hold the primary key value, so lookups through them cost a second traversal unless the index covers the query.
5. Group the SQL sublanguages (DDL, DML, DCL, TCL) and mention normalization and views briefly, as these come up together.

Follow-up

• What is the difference between a clustered and a non-clustered index?
• Why might MySQL ignore an index you created (function on the column, leading-wildcard LIKE, skipping the leftmost column of a composite index)?
• Which isolation level would you use for a balance transfer, and what would you add if it were not enough?

How do you implement JDBC or JPA/Hibernate for database connectivity?

Medium · Database and Data Management

Approach

1. Plain JDBC: get a Connection from a pooled DataSource (Spring Boot defaults to HikariCP) rather than DriverManager, use PreparedStatement with ? bind parameters to prevent SQL injection, map the ResultSet, and close everything with try-with-resources.
2. Transactions in JDBC: setAutoCommit(false), commit on success, rollback in the catch block; use addBatch and executeBatch for bulk inserts.
3. JPA/Hibernate: annotate entities with @Entity, @Id and @GeneratedValue, map relations with @ManyToOne and @OneToMany, and access data through Spring Data JpaRepository with @Transactional on service methods. The persistence context caches loaded entities and flushes dirty changes at commit.
4. Know the defaults and traps: @ManyToOne and @OneToOne are EAGER by default and the collection mappings are LAZY; looping over lazy associations causes N+1 queries, fixed with JOIN FETCH, @EntityGraph or batch fetching; touching a lazy field after the session closes throws LazyInitializationException.
5. Trade-off: JDBC (or JdbcTemplate) for tuned reporting SQL and bulk work, JPA for CRUD-heavy domain models. Turn on SQL logging to see what Hibernate actually runs.

Follow-up

• How would you detect and fix an N+1 query problem in a Hibernate application?
• Why does @Transactional not apply when one method calls another method of the same bean?
• What is the difference between persist and merge, and when does Hibernate issue the UPDATE?

Describe the SDLC in detail.

Medium · Project Experience and SDLC

Approach

1. List the phases in order with the output of each: requirements analysis (a requirements specification), design (high-level and low-level design, schema), implementation (reviewed code), testing (unit, integration, system, user acceptance), deployment (release notes, rollback plan) and maintenance (bug fixes, enhancements).
2. Compare the models: Waterfall is sequential and fits fixed, well-understood scope; the V-model pairs each design phase with a test level; Spiral is iterative and risk-driven; Agile/Scrum delivers in sprints from a prioritised backlog with planning, daily stand-ups, review and retrospective.
3. Say how you would choose: fixed-scope client contracts suit Waterfall or V-model milestones, while changing requirements suit Agile iterations.
4. Anchor it in your own work: which model your last project used, which phases you owned and one point where the process caught a defect early (a review or test before release).

Follow-up

• When would you pick Waterfall over Agile?
• How did you handle a requirement change that arrived halfway through a sprint or phase?
• Where should testing start in the lifecycle, and what does shifting it earlier change?

Walk me through a project you led or contributed to, specifically focusing on the technical challenges you fac

Medium · Project Experience and SDLC

Walk me through a project you led or contributed to, specifically focusing on the technical challenges you faced.

Approach

1. Open with context in a few sentences: what the system did, who used it, the stack (for example Spring Boot with MySQL, or ASP.NET MVC) and the part you personally owned. Use 'I' for your work and 'the team' for everything else.
2. Describe the architecture as a request path: client, controller, service, repository, database, plus any external API, so the listener can follow the next part.
3. Pick one or two technical challenges and give the debugging sequence: the symptom, how you measured it (logs, profiler, EXPLAIN on a slow query), the root cause and the fix, such as a composite index or removing an N+1 loop.
4. Give the numbers you actually have (response time or error rate before and after) and the alternatives you rejected, with the reason.
5. Finish with what you would do differently, and be ready to sketch the schema or class design of the module you built.

Follow-up

• Why did you choose that framework or database over the alternatives?
• What broke in production on this project, and how did you find it?
• What would have to change if the data volume grew tenfold?

How do you ensure your code is maintainable and scalable?

Medium · Project Experience and SDLC

Approach

1. Split the answer into maintainability (code) and scalability (runtime), with one concrete practice and one example for each.
2. Maintainability: small cohesive classes following SOLID, constructor injection (in Spring, for example) so dependencies can be mocked in unit tests, interfaces at module boundaries, consistent exception handling and logging, code review and automated tests in the build.
3. Scalability: keep application servers stateless so they can sit behind a load balancer (sessions in a shared store or tokens), use connection pooling, add indexes and paginate queries instead of loading whole tables, cache hot reads with a clear invalidation rule, and move slow work to a background queue.
4. Say how you decide: measure first (profiler, slow query log, EXPLAIN) and fix the actual bottleneck, rather than adding caches or services before there is load to justify them.
5. Close with a real refactor or performance fix you made, giving before and after.

Follow-up

• How would you scale reads on a MySQL-backed application, and what does replication lag break?
• Show a class you would refactor for testability and explain how you would change it.
• How do you make a session-based web application run on several servers?

One log partition stops advancing while the others drain

Easy · poison message · head-of-line blocking · consumer lag

Search results for a subset of tenants are hours stale; the rest are current. The projection consumer reports lag of zero on 15 of 16 partitions and 400,000 on one. Its error rate is flat and its CPU is idle. outbox_event has no pending rows older than a second, so the relay has published everything it holds. Identify the mechanism, give the ordered checks, and state what you do in the first ten minutes versus what you change permanently.

Approach

1. Read the lag distribution first. A slow consumer lags everywhere; zero on fifteen partitions and 400,000 on one is not throughput. Idle CPU on the stuck partition means the consumer is not advancing its offset at all, which points at one message it cannot get past rather than at a rate problem.
2. Exonerate the producer before touching the consumer. No pending outbox rows older than a second means the relay published, so the event exists in the log. This separates never sent from sent and never applied, which are different code paths and usually different owners.
3. Read the message at the stuck offset and the handler's log lines for its event_id. A flat error rate with no progress has two explanations and you must distinguish them: the handler is throwing and the retry loop is swallowing it, or the handler is blocking on something and never returning. Idle CPU with no error lines favours the second.
4. Mitigate before diagnosing further. Move the offending event to a dead-letter store and commit the offset past it. Adding consumers does nothing here, because a partition is consumed by exactly one member of the group, and the blast radius is every aggregate hashed to that partition, not only the aggregate that produced the bad event.

Follow-up

• The dead-lettered event carried aggregate_version 7 and the projection had applied 6. What must the replay do differently if 8 and 9 landed in the meantime?
• How do you show staleness to the user while the partition is behind, given the API already returns the projection's watermark?

Suggested practice checklist

The plan follows the reported loop: fundamentals for the screen and deep-dives on days two to five, a timed machine-test simulation on day six, and project and managerial stories on day seven.

Day 1 — Fix your stack and map the loop

• Choose the language and framework you will interview in (Java with Spring Boot, .NET with ASP.NET MVC, or PHP) and keep every answer in it.
• Write the four reported stages, Initial Screening, Technical Deep-Dives, Practical Assessments and Final Managerial Rounds, with what you would show in each.
• List every project on your resume and mark the two you can explain best.

Deliverable: A one-page loop map, a stack decision, and a ranked list of resume projects.

Day 2 — Sorting and core algorithm talking points

• Write a comparison table of insertion, merge, quick, heap and counting sort covering average and worst-case time, extra space and stability.
• Implement merge sort and quicksort from scratch in your language and test on empty, sorted, reversed and duplicate-heavy arrays.
• Answer the sorting question aloud as a decision rule: which algorithm for which input.

Deliverable: A sorting comparison table, two tested implementations, and one recorded spoken answer.

Day 3 — OOP, exceptions and language features

• Write one code example each for encapsulation, inheritance, polymorphism and abstraction, then add a note on composition versus inheritance.
• Draw the exception hierarchy, write a custom checked and a custom unchecked exception, and demonstrate try-with-resources and a swallowed-exception bug you then fix.
• List the key features of Java 8 (lambdas, streams, Optional, default methods, the date-time API), or the equivalent for your language, with a three-line example each.

Deliverable: Four OOP code examples, a runnable exception demo, and a feature cheat sheet with code.

Day 4 — Architecture and the persistence layer

• Sketch a 3-tier application and an MVC application for the same feature, and write the difference in one paragraph, noting that MVC often sits inside the presentation tier.
• Write one data-access class with plain JDBC (PreparedStatement, try-with-resources) and the same operation with JPA/Hibernate, then compare boilerplate, lazy loading and the N+1 problem.
• Trace a request through Spring Boot, or ASP.NET MVC, from controller to repository, and explain dependency injection at each hop.

Deliverable: Two architecture sketches, JDBC and JPA versions of one operation, and a written request trace.

Day 5 — MySQL: schema, JOINs and RDBMS concepts

• Take a flat orders spreadsheet and normalize it to third normal form, adding primary keys, foreign keys, NOT NULL, UNIQUE and CHECK constraints.
• Create two small tables in MySQL and run INNER, LEFT, RIGHT, CROSS and anti-join (LEFT JOIN with IS NULL) queries, writing the expected output before each run.

Deliverable: A normalized schema with constraints, a query file covering every JOIN type with outputs, and a one-page RDBMS summary.

Day 6 — Machine test simulation

• Build a small REST API with CRUD endpoints backed by MySQL in your main stack, starting from an empty folder and a plain editor.
• Take a short snippet with two planted bugs and fix them by reading first, then running.
• Rewrite the working module once more, speaking your reasoning aloud, and refactor names and structure so the code reads cleanly.

Deliverable: A running CRUD API, two fixed bugs with a one-line cause each, and a list of every lookup you needed.

Day 7 — Projects, SDLC and the managerial conversation

• Write the SDLC answer as phases (requirements, design, build, test, deploy, maintain) with one concrete activity from your last project in each, and a note on how an agile team differs from waterfall.
• Write the project walkthrough for your two best projects: architecture, your contribution, one technical challenge, one trade-off.

Deliverable: An SDLC answer, two project walkthroughs, a maintainability checklist and a rehearsed estimation story.

Project stories and managerial round preparation

The final managerial stage is described as covering cultural fit and decision-making, and the reported project questions invite you to explain technical challenges you faced. Prepare stories that show a decision you made, the alternatives you rejected and how you worked with others, and keep the technical detail accurate enough to survive follow-up questions.

1. Walk me through a project you led or contributed to, specifically focusing on the technical challenges you faced.
2. Tell me about a bug that reached production from code you wrote or reviewed. What was the cause, how did you find it, and what did you change afterwards?
3. Describe a disagreement with a teammate or lead about a technical approach. How did it end, and what would you do differently?
4. Tell me about a requirement that was unclear. How did you turn it into something you could build, and who did you check with?
5. Describe a time you helped a teammate through a hard task, or asked for help on one yourself.

How do you handle exceptions in your code, and what is the exception hierarchy?

Medium · Technical Foundations and Programming

Approach

1. Start with the hierarchy, using Java. Throwable splits into Error (OutOfMemoryError, StackOverflowError), which signals JVM-level trouble you normally do not catch, and Exception. Under Exception, checked exceptions such as IOException and SQLException must be caught or declared; RuntimeException and its subclasses (NullPointerException, IllegalArgumentException, IllegalStateException) are unchecked.
2. If your stack is not Java, say so and map it: in .NET everything derives from System.Exception and nothing is checked; in PHP 7 and later, Throwable has Error and Exception beneath it.
3. Cover the mechanics: catch blocks are tried in order, so the most specific type goes first (a subclass after its superclass will not compile); multi-catch merges unrelated types; finally runs on both paths; try-with-resources closes AutoCloseable resources and records secondary failures as suppressed. A return or throw inside finally hides the original exception.
4. State your policy: catch only where you can recover, add context or translate. Wrap low-level failures in a domain exception and keep the cause; never leave an empty catch; log once at the boundary; avoid catching Exception or Throwable broadly. In Spring, @ControllerAdvice with @ExceptionHandler maps exceptions to HTTP responses, and @Transactional rolls back on unchecked exceptions by default but not checked ones.
5. Close with a real case from your own code, such as a swallowed SQLException that hid failed writes. Say how you found it, what you changed (specific type, preserved cause, a log line with an identifier) and how a test confirmed the fix. Reciting the tree with no example, or saying you always catch Exception to be safe, weakens the answer.

Follow-up

• Why did designers make some exceptions checked, and why do many frameworks, including Spring's data access layer, prefer unchecked ones?
• What happens if both the try block and the finally block throw, and how does try-with-resources change that?
• How would you design the error response of a REST API so clients can tell a validation failure from a server fault?

Unblock an engineer without taking the keyboard

Easy · mentoring · leases · at-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach

1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.

Follow-up

• How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
• Their handler calls an external endpoint before recording that it did. What do you tell them to change first?

Estimate work you have never done and defend the range

Hard · estimation · backfills · expand-contract

You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

Approach

1. Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
2. Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
3. Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
4. Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.

Follow-up

• How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
• Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?