The reported questions are fundamentals, not puzzles. Three of the four sit in Java and class design: how == differs from .equals(), how to handle exceptions and release resources such as database statements, and how to spot anti-patterns in a class you are shown and improve them. The fourth asks how parent and child nodes relate in a DOM tree, which is front-end knowledge rather than Java, so the loop is not purely back-end. Each of these has a short textbook answer and a deeper answer with edge cases, and the deeper answer is the one to rehearse.
The requirements candidates describe for the role are Java, SQL, REST APIs and skill at writing and debugging complex algorithms, with CI/CD, quality engineering and high-traffic site experience as extras. The evaluation areas candidates describe include code review (bugs, security problems such as SQL injection, maintainability), choosing data structures, language best practices, concurrency, memory management, API integration, and testing strategy. A code-review style answer has to connect to that list: when you see a class that builds SQL by string concatenation, say injection and name the bind-parameter fix.
Candidates also report that every project on your resume can be examined in detail, including why you made a design choice and how you handled a constraint. Reserve as much time for explaining your own work as for Java drills. Pick the three or four projects you can defend end to end and prepare the alternatives you rejected.
Candidates report being told to lay out a plan before coding, name edge cases and state time and space complexity. They are also warned that platform practice alone leaves gaps, since follow-ups can move to why the code is written that way. Practise answering aloud, since the reported format mixes coding assessments, conceptual discussion and project conversation.
Preparation focus
editorialCandidates describe an initial online assessment, then several technical and behavioral interviews, sometimes with a panel and sometimes remote or in person depending on office and team. They describe a mix of coding assessments, conceptual deep dives and discussion of past projects. No round names, order or lengths are reported, so ask your recruiter which stages you will face and whether you will write code. Use this block to prepare all four reported questions, the code-review skills behind them and a defensible account of your own projects.
What to demonstrate
- Java fundamentals: object equality, exception handling and releasing resources such as database statements
- Reading code critically: spotting bugs, SQL injection risks and anti-patterns, then proposing concrete improvements
- Structured problem solving: stating a plan, edge cases and time and space complexity before and while writing code
- Your own projects: the reasons behind your design choices and how you handled technical constraints
How to prepare
- Write short Java snippets that show
==against.equals()for Strings, boxed Integers and a class with and without an overriddenequals/hashCode, and explain the output - Write a JDBC method that runs a transaction: Connection in an outer try-with-resources, a PreparedStatement inside, rollback in an inner catch and auto-commit restored in finally
- Take a product-data service class with SQL built by concatenation, an inline REST call and swallowed exceptions, and rewrite it, saying which issue is most serious and why
- For each resume project, write down the design choices, the alternatives you rejected and the constraint that decided between them
PracHub editorial advice for the preparation topics above.
Answering the `==` question with only 'references versus content' and nothing else
Add the cases that make the answer checkable: new String("a") == "a" is false while an interned literal is true; autoboxed or valueOf Integers are guaranteed to share an instance only inside -128 to 127 (the upper bound can be raised with -XX:AutoBoxCacheMax), so outside that range == usually returns false; and a class that overrides equals must override hashCode consistently or HashMap and HashSet misbehave.
Explaining resource cleanup with a catch that prints the stack trace and a manual finally that calls `close()`
Use try-with-resources, catch specific exceptions, wrap with the cause, and state the suppressed-exception behaviour. Rehearse one JDBC transaction with the Connection in an outer try-with-resources and rollback in an inner catch, so the answer covers cleanup, rollback and injection in one pass.
Naming anti-patterns in the class you are shown but proposing no concrete change, or rewriting the whole class
Rank what you see by risk first (injection, leaked connections, an inline REST call with no timeout, swallowed exceptions, shared mutable state), then give the smallest change that fixes each and say how a test would confirm behaviour is unchanged. Treat style complaints such as naming and class size as lower priority.
Treating the DOM question as trivia and mixing up `childNodes` and `children`, or forgetting that whitespace between tags creates text nodes
Be able to state that every attached node except the document has exactly one parent, that siblings share a parent, that childNodes is a live collection that includes text and comment nodes while children holds elements only, and sketch a small tree to show how traversal and event bubbling follow parent links.
Listing technologies on your resume that you cannot explain at depth
Cut or rehearse every item. For each project be ready to say what you built, why you chose that design over the alternatives, what constraint pushed you, and what you would change now, because candidates report that any listed project can be examined in detail.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Diff a projection against the primary without per-row point reads
The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.
Approach
- Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
- Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
- For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
- Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.
Follow-up
- The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
- Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?
Find overlapping job attempts and peak concurrency from lease records
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
- 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.
- 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.
- 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.
- 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?
Archive a resource graph without breaking live references or recursing
Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.
Approach
- Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
- Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
- Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
- Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.
Follow-up
- The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
- The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?
Explain why the owner filter ignores the listing index
The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.
Approach
- Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
- For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
- Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
- Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.
Follow-up
- 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
- A dashboard runs this for 40 owners in one page load. What changes about the design?
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?
Explain the difference between `==` and `.equals` in Java.
Explain the difference between == and .equals in Java.
Approach
- Split it by type first. For primitives, == compares values, after numeric promotion. For references, == compares identity, so it is true only when both variables point at the same object. equals() is a method on Object whose default body is this == obj. String, Integer, List and records override it to compare logical content.
- Use String as the worked example. Compile-time constants are interned, so "ab" == "a" + "b" is true. new String("ab") == "ab" and a string built at runtime with a variable compare false. equals() is true in all three cases. I never rely on interning for correctness.
- Cover the boxing trap. Autoboxed or Integer.valueOf values are guaranteed to share an instance only inside -128 to 127, so two boxed 127s are == but two boxed 128s usually are not (the upper bound can be raised with -XX:AutoBoxCacheMax). Comparing an Integer to an int unboxes it, which throws NullPointerException when the Integer is null.
- State the equals contract: reflexive, symmetric, transitive, consistent, and x.equals(null) is false. Any class that overrides equals must also override hashCode so equal objects get equal hashes. Otherwise HashMap and HashSet lookups miss.
- Give the safe idioms. Objects.equals(a, b) handles null on either side, and "literal".equals(s) avoids an NPE when s is null. == is correct for enums and other singletons, and for a deliberate identity check such as IdentityHashMap.
Follow-up
- You override equals but not hashCode, then put two equal objects in a HashSet. What happens, and why?
- How do you write equals for a class with subclasses: getClass() or instanceof, and what does each choice do to symmetry?
- Why can new Integer(5) == new Integer(5) be false while Integer.valueOf(5) == Integer.valueOf(5) is true?
Can you identify common anti-patterns in a provided class structure and suggest improvements?
Can you identify common anti-patterns in a provided class structure and suggest improvements?
Approach
- Practise on a class shaped like this role's work: a ProductService for the site that concatenates a product id into a SQL string, opens its own Connection, calls a pricing REST endpoint inline with a hand-built HTTP client, validates input and formats the page response, with public mutable fields and a static cache map. Read it before naming anything: list its responsibilities, what it creates with new, what state it exposes and who calls it.
- Rank findings by risk. First the concatenated query (SQL injection; fix with a PreparedStatement and bind parameters) and the Connection that is never closed. Next the REST call: no timeout, an empty catch that returns null, so a slow pricing service stalls the page and failures vanish. Then the static cache map shared across request threads with no synchronisation and no eviction. Readability comes last.
- Coupling: the DataSource and HTTP client are built inside the class, so it cannot be tested without a database and a live endpoint. Move them behind interfaces (a ProductRepository and a PricingClient) passed through the constructor, and make fields private final.
- Split by responsibility: the repository owns SQL and resource cleanup, the client owns the HTTP call with a timeout and maps errors to a typed exception, a mapper owns formatting, and the service only orchestrates. If a switch on product type keeps growing, replace it with a strategy map or polymorphism rather than adding a subclass just to reuse code.
- Describe the order of changes: write characterization tests that pin current output, using a fake PricingClient, then refactor in small steps (Extract Class, Extract Method) and rerun after each. Name the trade-off: adding interfaces to a class with one implementation and few callers is over-engineering, so say where you would stop.
Follow-up
- The class has no tests and is in production. How do you refactor it without changing behaviour?
- Fix the concatenated query in this class. What does a PreparedStatement with bind parameters protect against, and what does it not protect against (for example a dynamic ORDER BY column)?
- The pricing call is slow under load. Where do you add a timeout, retry or cache, and what can go wrong with each?
Describe the relationship between parent and child nodes in a DOM tree.
Describe the relationship between parent and child nodes in a DOM tree.
Approach
- The DOM is a tree of Node objects with the Document at the root. Every node has at most one parent, exposed as parentNode. It is null for the Document and for the root of a detached subtree; nodes inside a detached subtree keep their parentNode. A parent holds an ordered list of children, and siblings are linked through previousSibling and nextSibling.
- Separate nodes from elements. childNodes is a live NodeList that includes text and comment nodes, such as whitespace between tags. children is a live HTMLCollection of Element nodes only. The element-only navigators are firstElementChild, nextElementSibling and parentElement. document.documentElement.parentNode is the document, but its parentElement is null.
- A node cannot have two parents, so appendChild or insertBefore on a node already in the tree moves it rather than copying it. cloneNode(true) makes a deep copy. removeChild or element.remove() detaches a node, and the node keeps its own subtree.
- Events travel along the parent chain: capture runs from window down through the ancestors to the target, then bubbling runs back up. Event delegation attaches one listener on a parent and resolves the source with event.target.closest(selector). That covers children added later, and it fails if a child handler calls stopPropagation.
- Edge cases and cost: removing children while looping forward over a live collection skips every other node, so loop backwards or copy first with Array.from. querySelectorAll returns a static NodeList. Walking up to an ancestor costs O(depth), and a full subtree traversal (recursion or TreeWalker) costs O(n).
Follow-up
- Write a function that finds the lowest common ancestor of two DOM nodes, and give its complexity.
- Why does a for loop that removes each entry of childNodes leave half the children behind, and how do you fix it?
- How would you serialise a subtree and rebuild it, keeping the parent-child order?
Listing latency scales with page size, not with filters
The tenant listing endpoint reads resource filtered by tenant_id and status, ordered by updated_at DESC, and returns each row plus the owner's display name from app_user and the actor of that resource's latest resource_revision. p99 is 55 ms at 10 rows per page and 1.4 s at 200. Database telemetry shows 401 statements per request, each under 1 ms, and nothing in the slow-query log. Diagnose the cause and give the fix, stating the statement count per request and the p99 you expect afterwards.
Approach
- Read the counters before forming a theory. 401 statements for 200 rows is one driver query plus two per row, and sub-millisecond execution with an empty slow-query log rules out a bad plan. The time is round trips, which is why it is invisible in every per-query metric and scales with rows returned rather than with filter selectivity.
- Name the two per-row statements from their normalised text: a single-row app_user lookup by user_id, and a resource_revision lookup by resource_id ordered by version DESC LIMIT 1. Confirm by dropping those two response fields and watching the statement count fall to one. That locates the calls in the serialisation layer, not the repository.
- Check that the arithmetic accounts for the whole gap. Measure one round trip to the replica in isolation; 400 trips at roughly 3 ms of network plus 0.2 ms of execution is about 1.3 s on top of a 55 ms baseline, which matches. If the multiplication had fallen short, the N+1 would only be part of the story and you would keep looking.
- Batch both lookups. Collect owner_user_ids and resource_ids from the driver query, then issue WHERE tenant_id = $1 AND user_id = ANY($2) for the users, and PostgreSQL's SELECT DISTINCT ON (resource_id) ... WHERE resource_id = ANY($2) ORDER BY resource_id, version DESC for the latest revision, which the UNIQUE (resource_id, version) index serves directly. On an engine without DISTINCT ON, use a lateral join or a row_number window. Three statements per request at any page size.
Follow-up
- The page size is capped at 200 today. What breaks first if it is raised to 2,000, and is it still this bug?
- How do you stop the next N+1 from reaching production, given that no individual query is slow and the endpoint's tests pass?
The plan starts with the four reported questions and the Java, SQL and REST API skills candidates describe, then moves to PracHub's SQL, coding and debugging practice, and ends with behavioral stories and a full spoken run-through.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Confirm the format and inventory your projects
- Email your recruiter to ask which stages you will face, whether there is an online assessment, whether any interview is a panel, which language you may use for coding and whether you will be writing code live.
- List every project on your resume and, for each, write the technologies used, two design choices and the alternative you rejected for each.
Deliverable: A sent recruiter email with your format questions, and a one-page project inventory with design choices and rejected alternatives for each project.
02Java equality, exceptions and memory
- Write and run snippets comparing Strings built with `new` against literals, boxed Integers at 127 and 128, and a class with and without `equals`/`hashCode`; write one sentence explaining each result.
- Write a JDBC transaction with the Connection in an outer try-with-resources, a PreparedStatement inside, rollback in the inner catch and auto-commit restored in finally; then force the body and `close()` to throw and print the suppressed exception.
- Memory management is listed next to concurrency: write a few lines on heap versus stack and GC roots, then write a leak (a static Map that only grows, or Connections never closed), run it with a small -Xmx, capture a heap dump and find the retaining path in a heap analyser.
- Answer aloud, without notes: the difference between `==` and `.equals()`, and how you handle exceptions and release resources in Java.
Deliverable: Runnable snippets with a one-line explanation per output, the JDBC transaction with its suppressed-exception test, the leak program with the retaining path you found, and two recorded spoken answers.
Practice prompt ↗Practice prompt ↗03Reading a class for anti-patterns
- Write a 60-line product-data service class that builds SQL by concatenation, opens its own Connection, calls a pricing REST endpoint inline with no timeout, swallows exceptions, keeps a static shared cache and exposes public mutable fields.
- Review your own class as if in a code review: list issues in order of risk, and rewrite it as a repository with bind parameters, a client interface with a timeout, and a thin service using constructor injection.
- Write the characterization tests, with a fake pricing client, that you would add before refactoring so you can show behaviour stayed the same.
Deliverable: A ranked issue list, the before and after versions of the class, and the characterization tests.
Practice prompt ↗04DOM tree and REST API basics
- Draw a small HTML tree and label parent, child, sibling and ancestor relations, then write which of `parentNode`, `childNodes`, `children`, `firstChild` and `nextSibling` returns what, including the whitespace text nodes.
- Write a recursive and an iterative traversal that collects all descendants of a node.
- Design a REST resource with its URLs, HTTP methods, status codes and which calls are idempotent, then list the tests you would write for it.
Deliverable: An annotated DOM diagram with a method cheat sheet, both traversals, and a one-page REST resource design with its test list.
Practice prompt ↗05SQL under time
- Work through the PracHub SQL question on why an owner filter ignores the listing index, and explain the plan reasoning aloud.
- Work through the window-function question on version gaps and relay lag, writing the query before checking.
- Take one query you wrote this week and rewrite it with bind parameters, then note which index it relies on.
Deliverable: Two solved SQL practice questions with written explanations, and one parameterised query with its supporting index named.
Practice prompt ↗Practice prompt ↗06Coding and debugging while narrating
- Solve the PracHub overlapping-attempts and peak-concurrency question aloud: state the plan, edge cases and time and space complexity before you write code.
- Solve the resource-graph archiving question iteratively, and say why you avoided recursion.
- Work the listing-latency debugging question, writing the sequence of checks you would run in order.
- Write a short Java example of a lost update on a shared counter and fix it with `AtomicInteger` or `synchronized`, since concurrency is a listed area.
Deliverable: Two timed solutions with spoken complexity statements, a written debugging sequence, and a working concurrency fix.
Practice prompt ↗Practice prompt ↗Practice prompt ↗07Behavioral stories and a full spoken run-through
- Write three STAR stories from your own work: a failure, a disagreement or requirements change with a QA lead or product owner, and a decision you made and defended.
- Rehearse the two PracHub behavioral situations aloud, one on telling callers their integration breaks and one on unblocking an engineer without taking the keyboard.
- Answer all four reported questions back to back, aloud and timed, then write the two questions you want to ask the interviewers.
Deliverable: Three written STAR stories, recorded answers to both behavioral situations, a timed run-through of the four reported questions and your two interviewer questions.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates describe the behavioral side as a conversation about your own history: the projects on your resume, the reasoning behind your design choices, your failures, your interests and how you collaborate. For this role the collaboration side includes QA leads, product owners and senior architects. The first prompt below is filed as behavioral but asks a Java question, so answer it technically and back it with a case from your own code. Build the others as STAR stories (Situation, Task, Action, Result) that put your decision and its outcome in the Action and Result.
How do you handle exceptions and ensure proper resource management (e.g., closing statements) in Java?
How do you handle exceptions and ensure proper resource management (e.g., closing statements) in Java?
Approach
- Start with the mechanism: a resource such as a Connection, Statement or ResultSet implements AutoCloseable, so declare it in try-with-resources. Java closes each resource when the block ends, in reverse order of declaration, whether the body finishes normally or throws.
- Explain why that beats try/finally: with hand-written finally blocks, an exception thrown by
close()can replace the original failure and hide the real cause. With try-with-resources the original exception propagates and theclose()failure is attached as a suppressed exception, readable throughgetSuppressed(). - Cover catching: catch the most specific exception you can act on, such as SQLException, never leave a catch empty, and avoid catching Throwable or a bare Exception. If you cannot recover, wrap and rethrow with the cause attached (
new DataAccessException("load order failed", e)) so the stack trace is kept, and log once at the boundary. - For a transaction, note that resources declared in a try-with-resources header are out of scope in its catch and already closed when the catch runs, so rollback cannot go there. The shape I use:
try (Connection conn = ds.getConnection()) { conn.setAutoCommit(false); try (PreparedStatement ps = conn.prepareStatement(sql)) { bind; execute; conn.commit(); } catch (SQLException e) { conn.rollback(); throw new DataAccessException("save failed", e); } finally { conn.setAutoCommit(true); } }. Bind parameters also close the SQL injection hole. - Name the pitfalls: a
returnor throw insidefinallycan discard an in-flight exception; closing a pooled Connection returns it to the pool, so a leaked one drains the pool; checked exceptions suit failures a caller can handle, unchecked suit programming errors. Answer technically and add a short story from your own code, such as a connection leak you fixed.
Follow-up
- What happens if the try body throws and
close()also throws, and how would you read the second exception? - What goes wrong if you put the Connection, the PreparedStatement and the rollback all in one try-with-resources with a single catch?
- How would you find a connection leak in a running service, and how does a connection pool change what
close()does?
Tell callers you do not own that their integration breaks
A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.
Approach
- Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
- Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
- Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
- Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.
Follow-up
- How would you detect a consumer that reads the field only during a monthly export?
- One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?
Unblock an engineer without taking the keyboard
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
- 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.
- 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.
- 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.
- 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?
- 01
How do you handle exceptions and ensure proper resource management (e.g., closing statements) in Java?
- 02
Walk me through the most substantial project on your resume and explain why you chose its main technologies and structure.
- 03
Tell me about a project that failed or missed its goal, and what you changed afterwards.
- 04
Describe a time you worked with QA leads, product owners or an architect to refine unclear requirements before you built anything.
- 05
Tell me about a bug that reached production, how you found it and what you changed so it would not recur.
- 06
What are you learning right now, and what draws you to maintaining large, long-lived enterprise software?
What does the American Wholesale Energy Software Engineer process look like?
Candidates describe an initial online assessment followed by several technical and behavioral interviews, with panel interviews in some loops. They report a mix of coding assessments, conceptual deep dives and project discussions, held virtually or in person depending on office and team. No round names or order are reported, so ask your recruiter for the sequence and whether you will write code.
PracHub Software Engineer practice ↗Which topics should I prioritise?
Start with the four reported questions: `==` against `.equals()`, exception handling and resource cleanup in Java, anti-patterns in a class structure, and parent-child relationships in a DOM tree. Then cover the skills candidates describe for the role: Java, SQL, REST APIs and writing and debugging algorithms.
PracHub Software Engineer practice ↗How do I prepare for a question that shows me a class and asks for improvements?
Practise a fixed review order on a realistic class, such as a product-data service: security first (SQL built by concatenation, unvalidated input), then leaked connections, inline remote calls without timeouts and swallowed exceptions, then shared mutable state and equals/hashCode contracts, then structure such as classes doing several jobs. For each issue, give the specific change and how a test would confirm behaviour is unchanged.
PracHub Software Engineer practice ↗Will there be system design?
Candidates say system design and architecture come up for more senior roles, with API design and testing strategy named. If you interview at that level, be ready to design REST endpoints (resources, methods, status codes, idempotency) and explain how you would test them, including in a CI/CD pipeline.
PracHub Software Engineer practice ↗How deeply will my resume be examined?
Candidates report that any project you list can be explored in detail, including why you chose a design and how you handled a constraint. Prepare each project's goals, your role, the alternatives you rejected and what you would change today, and drop anything you cannot discuss at that depth.
PracHub Software Engineer practice ↗Is solving problems on coding platforms enough?
Candidates report that it leaves gaps. Timed problems build speed, but also practise saying why each part of a solution is there: the data structure, the complexity, the edge cases and the Java convention it follows. Answering the reported questions aloud, such as the try-with-resources transaction or the equals and hashCode contract, is a quick way to check that you can explain the reasoning and not only produce code.
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.
- 01American Wholesale Energy 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.
Zoom Video Communications Software Engineer Interview Guide
What Zoom Video Communications asks Software Engineer candidates, from reported rounds and questions.
Wizeline Software Engineer Interview Guide
What Wizeline asks Software Engineer candidates, from reported rounds and questions.
World Wide Technology Software Engineer Interview Guide
What World Wide Technology asks Software Engineer candidates, from reported rounds and questions.
Wego Software Engineer Interview Guide
What Wego asks Software Engineer candidates, from reported rounds and questions.