The work candidates describe is enterprise application development for an insurer: services and APIs that move policy, risk and claims data between internal users, brokers and other systems, backed by relational databases. That shapes the question mix. Object-oriented design questions test whether you can organise code that stays maintainable (abstraction, polymorphism, loose coupling, a pattern you have really used). SQL questions test whether you can query and design relational data, including joins, normalization trade-offs and slow-query diagnosis. A whiteboard array problem and two broader questions (building a web application from scratch, and testing a new API) round out the technical side.
Two parts of the loop reward preparation you can do alone. The Take-Home Project asks for a working application built from scratch, and reported example scenarios include a RESTful API for policyholder data with validation, error handling and unit tests, and refactoring a block of legacy code into a testable service. Treat it as production code: a clear folder layout, meaningful tests and a README covering build, run and test. The second is the behavioral material, where reports list conflict resolution, delivering under deadline pressure and taking code-review feedback, plus questions about working with business analysts on vague requirements.
The reported tips add a communication layer. Candidates are advised to explain reasoning aloud, keep the language professional, and stress collaboration with other engineers, system administrators and business stakeholders. Panels may mix senior engineers, hiring managers and junior team members, so be ready to run the same project story at two levels of technical depth. A self-rating question on a 1 to 10 scale is also reported. The sensible plan is to pick one language and one database engine, answer every technical question in them, build a small API end to end, and rehearse five behavioral stories until each has a clear decision and result.
HR Screen
reportedCandidates describe the HR Screen as a conversation about your background, your career goals and how they line up with the role. No technical content is reported for this stage. Treat it as the first test of your story: a clear account of what you have built, in which language and database, and why this role follows from it.
What to demonstrate
- How you describe your background and career goals
- Whether your experience matches the role as candidates describe it: an object-oriented language and relational databases
- Clarity and professionalism of your spoken communication
How to prepare
- Write a short walk through your career that ends at this role, and mention your primary language (C#/.NET or Java) and database engine by name.
- Prepare a specific reason for being interested in software for specialty insurance (underwriting, claims, broker-facing tools), based on what you have read, without pretending domain expertise you lack.
- Practise the 1 to 10 self-rating question: choose a number, then back it with two concrete strengths and one thing you are still learning.
- Keep the recruiter informed and ask in writing what the later stages involve, since the timeline is reported to run long.
Technical Screening
reportedThe Technical Screening is reported as a technical evaluation with a hiring manager or tech lead. Candidates describe live technical sessions as covering OOP concepts, SQL queries and a whiteboard exercise, and the reported advice is to explain why you chose a technology, not only how it works. Prepare to talk through reasoning out loud and in measured, professional language.
What to demonstrate
- Command of an object-oriented language and of relational database fundamentals
- Ability to explain the reason behind a technical choice
- Problem decomposition while talking through a whiteboard-style task
How to prepare
- Rehearse OOP answers in your own language with code: the four pillars, abstract class versus interface, and a design pattern you have actually used and what it solved.
- Write the second-highest-value query without analytic functions, then explain joins, normalization and indexing aloud.
- Solve the maximum-sum contiguous subarray problem on paper and narrate the approach, complexity and edge cases as you go.
- Prepare one or two 'why did you choose it' stories about technologies on your CV, including what you rejected.
Take-Home Project
reportedThe Take-Home Project asks you to build a functional application from scratch to show coding and architectural skill. Reported evaluation areas for this kind of work are code organization (directory layout, separation of concerns, naming), tests that prove behavior, and documentation. Reported example scenarios include a RESTful API for policyholder data with validation, error handling and unit tests, and refactoring a monolithic block of legacy code into a testable service. Containerization, CI configuration and automated dependency management are listed as less common extras.
What to demonstrate
- Working software that runs from your instructions
- Code structure, naming and separation of concerns
- Meaningful unit and integration tests, including edge cases
- A README that explains design decisions and how to build, run and test
How to prepare
- Build a practice REST API for policy records in your chosen language: input validation, consistent error responses, a repository layer behind an interface, and unit tests that mock it.
- Write the README first as a checklist (setup, run, test, design decisions, known limitations) and keep it current as you build.
- Ask the recruiter in writing about the time allowed, language choice and what to submit, because none of that is reported.
- If you add Docker or a CI file, make sure it works from a clean clone, or leave it out.
Competency Interviews
reportedCompetency Interviews are reported as deep-dive sessions on behavioral scenarios and collaborative problem-solving. Reported areas are resolving technical disagreements, managing time and communicating delays early, and taking code-review feedback. Reported example scenarios include a team member disagreeing with your architecture, and turning vague requirements from business analysts into concrete deliverables.
What to demonstrate
- Conflict resolution within a team
- Project delivery: prioritizing and communicating delays
- Receiving and applying feedback from code review
- Working with business-side partners on unclear requirements
How to prepare
- Build a story bank of five real projects and map each to a scenario: a disagreement, a missed or at-risk deadline, a fast learning curve, a hard stakeholder, and a requirement that began vague.
- For each story, write the decision you personally made, the alternative you rejected, and the measurable result.
- Prepare one honest example of code-review feedback that changed how you work.
- Say 'I' for your own actions and name collaborators explicitly, since collaboration is a reported emphasis.
Onsite/Panel Interview
reportedThe Onsite/Panel Interview is reported as an intensive session covering system design and behavioral aspects. Candidates also report panels that mix senior engineers, hiring managers and junior team members, so the same answer may need to land at different levels of depth. A reported database design scenario is a schema for a multi-tenant claims processing system, and a reported broader question is how to architect and build a web application from scratch.
What to demonstrate
- System design: structuring an application and justifying technology choices
- Database schema design for a multi-user, data-heavy system
- Behavioral answers delivered to a mixed audience
- Collaborative problem solving as you talk through trade-offs
How to prepare
- Practise a web application walkthrough in a fixed order: requirements, components, data model, API surface, testing, deployment, then what you would change at larger scale.
- Sketch a multi-tenant claims schema with keys, constraints and a tenant-isolation choice, and defend the trade-offs between shared tables and separate schemas.
- Prepare two versions of your main project story, a detailed one for senior engineers and a plain-language one for non-technical panelists.
- Prepare questions of your own about the team's engineering practices, such as code review and how requirements reach developers.
PracHub editorial advice for the preparation topics above.
Submitting a take-home that runs but has no tests, no README and everything in one file
Split the code into clear layers, write unit tests for validation and error paths, and add a README with setup, run, test commands and design decisions. Try the instructions on a fresh clone before submitting.
Answering abstract class versus interface with two definitions and no decision rule
Give the rule in your language: an interface for a capability contract that unrelated classes implement, an abstract class for shared state or partial implementation in a closely related family. Add one example from your own code and mention how multiple inheritance and later changes affect the choice.
Writing a second-highest query that breaks on ties, NULLs or a table with fewer than two rows
Use a subquery on the maximum value (or an OFFSET approach on distinct values), state how duplicates of the top value are treated, and say the result is NULL when no second value exists. Then offer the version that picks the Nth value.
Giving an extreme self-rating, or a number with no explanation
Candidates are advised against both a 10 and a very low score. Choose a figure you can justify, tie it to two concrete strengths from real projects, and name one area you are still developing.
Telling behavioral stories in the plural, with vague results and no personal decision
Name what you decided, what you rejected and the result. Use 'we' only for team facts, and give the reader a before-and-after that is true. Prepare the delayed-deadline and difficult-stakeholder stories with the actual conversation you had.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Solve this whiteboard problem: given an array of integers, find the contiguous subarray with the largest sum.
Solve this whiteboard problem: given an array of integers, find the contiguous subarray with the largest sum.
Approach
- Clarify: can the array be empty, can all values be negative, and should the answer be the sum only or also the bounds? Use a 64-bit accumulator if sums can overflow 32 bits.
- Brute force first: try every start and extend the end while keeping a running sum, O(n^2) time and O(1) space (the naive triple loop recomputing each sum is O(n^3)).
- Kadane's algorithm: current = max(x, current + x); best = max(best, current). Initialise both to the first element, not zero, so an all-negative array returns its largest element. O(n) time, O(1) space.
- For bounds, record a tentative start whenever current restarts at x, and copy start and the current index into the answer whenever best improves.
- Test on all-negative input, a single element, all positives (the whole array), and zeros mixed in. Mention the O(n log n) divide-and-conquer version only as an alternative.
Follow-up
- Solve it for a circular array, where the subarray may wrap around the end.
- Find the contiguous subarray with the largest product instead of the largest sum.
- Return the maximum sum for subarrays of length at most k.
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?
Canonicalise a request body into a stable idempotency fingerprint
idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.
Approach
- Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
- Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
- Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
- Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.
Follow-up
- A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
- Where does the fingerprint get computed relative to request decompression and the body-size limit?
Write a SQL query to retrieve the second-highest record from a table without using proprietary analytical func
Write a SQL query to retrieve the second-highest record from a table without using proprietary analytical functions.
Approach
- Clarify whether 'second-highest' means the second distinct value or the second row when the top value is tied; the standard reading is the second distinct value.
- Portable answer with no analytic functions: SELECT MAX(amount) FROM t WHERE amount < (SELECT MAX(amount) FROM t). The inner query finds the top value, the outer finds the largest value below it, and ties at the top are handled automatically.
- Edge cases: with only one distinct value the outer MAX runs over no rows and returns a single NULL; MAX ignores NULL amounts. If the question wants the full record, wrap it: SELECT * FROM t WHERE amount = (that query), which returns every row tied at the second value.
- Alternative: SELECT DISTINCT amount ... ORDER BY amount DESC with OFFSET 1 and LIMIT 1 in PostgreSQL, or OFFSET 1 ROWS FETCH NEXT 1 ROWS ONLY in SQL Server 2012+ and Oracle 12c+. It returns an empty set rather than NULL when there is no second value.
- Performance: with an index on the amount column each MAX is an index seek. The general Nth-value form, WHERE N-1 = (SELECT COUNT(DISTINCT amount) FROM t t2 WHERE t2.amount > t1.amount), is a correlated subquery and grows roughly quadratically without an index.
Follow-up
- Generalise it to the Nth-highest value without window functions.
- Return the second-highest amount within each department.
- What should the query return when every row has the same amount, and how does each version behave?
What is database normalization, and what are the trade-offs between third normal form (3NF) and denormalizatio
What is database normalization, and what are the trade-offs between third normal form (3NF) and denormalization in a high-read environment?
Approach
- Define normalization as removing redundancy so each fact is stored once, which prevents update, insert and delete anomalies. 1NF: atomic values, no repeating groups. 2NF: no non-key column depends on only part of a composite key. 3NF: no non-key column depends on another non-key column.
- Give a concrete 3NF fix: an orders table holding customer_id and customer_city has a transitive dependency, so the city moves to the customers table and changing it updates one row instead of many.
- Denormalization in a read-heavy system: duplicate columns or precomputed aggregates to remove joins from hot queries. The cost is write amplification and the risk of copies drifting, so name how you keep them in sync (same transaction, trigger, or a materialized or indexed view).
- Before denormalizing, try cheaper fixes: covering indexes, caching, read replicas, or a separate reporting store such as a star schema, which keeps the transactional schema in 3NF.
- Distinguish a point-in-time snapshot from denormalization: storing the address or price as it was when a record was issued is a separate historical fact and is correct modelling, not a redundant copy.
Follow-up
- What does Boyce-Codd normal form add beyond 3NF?
- You denormalized a total onto a parent row. How do you stop it drifting from the child rows under concurrent writes?
- How would you decide between an indexed or materialized view and a cache for a slow dashboard query?
Explain the difference between an inner join, a left join, and a cross join, and describe a scenario where a c
Explain the difference between an inner join, a left join, and a cross join, and describe a scenario where a cross join is appropriate.
Approach
- INNER JOIN returns only rows with a match on both sides. LEFT JOIN returns every row of the left table, with NULLs in the right table's columns where nothing matches. CROSS JOIN has no join condition and returns every pairing, m times n rows.
- Call out the classic LEFT JOIN mistake: a filter on the right table in WHERE (right.status = 'X') discards the NULL rows and behaves like an inner join; put that condition in the ON clause to keep unmatched left rows.
- Note row multiplication: if the join key is not unique on the right side, each left row repeats once per match, which silently inflates SUM and COUNT. Check key uniqueness before aggregating.
- Appropriate CROSS JOIN: build a complete grid, for example every date times every product, then LEFT JOIN the facts onto it so missing combinations show up as zero rather than disappearing. Also useful for generating test combinations.
- Anti-join: rows in A with no match in B via LEFT JOIN ... WHERE b.key IS NULL or NOT EXISTS. Avoid NOT IN when the subquery can return NULL, because the predicate is then never true and no rows come back.
Follow-up
- What does a FULL OUTER JOIN return, and when have you needed one?
- Why can NOT IN return zero rows when NOT EXISTS returns the expected result?
- A LEFT JOIN query returns more rows than the left table has. What happened?
How do you optimize a slow-running SQL query? Explain your approach to indexing.
How do you optimize a slow-running SQL query? Explain your approach to indexing.
Approach
- Reproduce first with the real parameters and data volume, then read the actual plan: SET STATISTICS IO, TIME ON and the actual execution plan in SQL Server, EXPLAIN (ANALYZE, BUFFERS) in PostgreSQL, DBMS_XPLAN in Oracle.
- In the plan, look for full scans of large tables, big gaps between estimated and actual row counts (stale statistics or parameter sniffing), key or bookmark lookups repeated per row, sorts or hashes spilling to disk, and implicit type conversions on join columns.
- Fix sargability: WHERE YEAR(created_at) = 2024 or a pattern that starts with a wildcard (LIKE '%term') cannot seek an index. Rewrite as a range such as created_at >= '2024-01-01' AND created_at < '2025-01-01'.
- Index design: in a composite B-tree index put equality columns first and the range column after, since only a left prefix of the key can be used; add INCLUDE columns (SQL Server, PostgreSQL 11+) to cover the query and remove lookups.
- State the cost: every index slows inserts and updates and uses storage, so check for unused or duplicate indexes, and confirm the fix by comparing logical reads and duration before and after.
Follow-up
- The query is fast in development and slow in production with the same code. What would you check?
- Why might the optimizer ignore an index that exists on the filtered column?
- How do you decide whether a table has too many indexes?
Explain the four pillars of Object-Oriented Programming and provide a real-world scenario where you applied po
Explain the four pillars of Object-Oriented Programming and provide a real-world scenario where you applied polymorphism.
Approach
- Name the four pillars and define each in one line: encapsulation (state hidden behind methods that enforce invariants), abstraction (callers depend on what an object does, not how), inheritance (a subtype reuses and extends a base type), polymorphism (one call site, behaviour chosen by the object's actual type).
- Separate the kinds of polymorphism: subtype polymorphism resolved at runtime through overriding, overloading resolved at compile time, and parametric polymorphism through generics (List in C# or Java).
- Get the language detail right: in C# a method must be marked virtual and the subclass must use override, while in Java instance methods are overridable by default unless they are final, static or private.
- For the real scenario, show the switch statement you removed: for example one IRateCalculator interface with an implementation per coverage type, so adding a type means adding a class, not editing every branch. Say what it bought you (a smaller change surface, each calculator unit-tested alone).
- Close with the cost: deep inheritance trees couple subclasses to base-class internals, so state when you would compose behaviour instead of inheriting it.
Follow-up
- When would you choose composition over inheritance, and what goes wrong with a deep hierarchy?
- Give an example that breaks the Liskov substitution principle and say how you would fix it.
- How does the runtime decide which overridden method to call, and when is an overload chosen instead?
How do you design a system to ensure loose coupling and high cohesion?
How do you design a system to ensure loose coupling and high cohesion?
Approach
- Define both terms: cohesion is how closely the contents of one module belong to a single responsibility; coupling is how much one module must know about another's internals to work. The goal is that one business change touches one module.
- At class level: depend on interfaces rather than concrete classes (dependency inversion), pass dependencies through constructors so a container such as ASP.NET Core's built-in DI or Spring can wire them, and keep classes to one reason to change.
- At module or service level: group code by business capability rather than technical layer, expose it only through a published contract (an API or events), and never let two services write the same database tables.
- Name the trade-off: every interface and message hop adds indirection. An interface with one implementation and no test seam is cost without benefit, and event-driven decoupling brings eventual consistency and harder debugging.
- Give a measurable signal: how many modules a typical feature change touches, or how many other modules a class imports; rising numbers mean the boundaries are drawn in the wrong place.
Follow-up
- How would you introduce these boundaries into an existing tightly coupled legacy system without a rewrite?
- Two services share one database table. What problems does that cause and how would you separate them?
- When is tight coupling acceptable?
What is the difference between an abstract class and an interface, and when would you choose one over the othe
What is the difference between an abstract class and an interface, and when would you choose one over the other?
Approach
- State the structural difference: an abstract class can hold instance fields, constructors and implemented methods with any access modifier, and a class can extend only one; an interface is a contract a class can implement many of, and it cannot hold instance state.
- Cover the modern versions correctly: Java 8 added default and static interface methods and Java 9 private ones; C# 8 added default interface implementations (on .NET Core 3.0 and later). Interfaces still have no instance fields, so shared state still needs a class.
- Choose an interface for a capability that unrelated types share, and for seams you want to mock or inject. Choose an abstract class when closely related types share state and code, for example a template method whose fixed steps call abstract hooks.
- Mention versioning: adding a method to a published interface breaks every implementer unless it has a default; adding a concrete method to an abstract base class does not.
- Mention the common combination: an interface as the public contract plus an abstract base class that implements it for shared plumbing, so callers depend only on the interface.
Follow-up
- In Java, what happens when a class implements two interfaces that provide conflicting default methods?
- Why do mocking frameworks and DI containers work more naturally with interfaces?
- Would you put validation logic in an abstract base class or somewhere else, and why?
Describe a design pattern you frequently use. How does it solve specific architectural challenges in your proj
Describe a design pattern you frequently use. How does it solve specific architectural challenges in your projects?
Approach
- Pick one pattern you can defend from real code, not a catalogue. Strategy, Decorator, Repository and Factory are all safe choices if you have used them.
- Structure the answer as problem, pattern, result: the code smell before (a growing switch on a type field, data access scattered through business logic), the classes you introduced, and what got easier (adding a variant, unit testing without a database).
- Show the mechanics precisely. Strategy: an interface with one implementation per variant, chosen by a factory or DI. Decorator: a wrapper implementing the same interface that adds caching, logging or retries around the real object without editing it.
- Name the cost and the limit: extra types and indirection, and a pattern applied where only one variant will ever exist is over-engineering. Say how you decided it was worth it.
- Be ready to contrast it with a near neighbour (Strategy versus State, Decorator versus inheritance) so the choice sounds deliberate.
Follow-up
- What is the difference between the Strategy and State patterns?
- Tell me about a time a pattern made the code worse, and what you did about it.
- How did the pattern change the way you wrote unit tests for that code?
Walk me through how you would architect and build a web application from scratch. What technologies would you
Walk me through how you would architect and build a web application from scratch. What technologies would you choose and why?
Approach
- Start by asking about users, expected load, data sensitivity, and the team's existing skills; every later technology choice should trace back to one of those answers rather than personal preference.
- Outline the layers: a single-page front end (React or Angular), a stateless REST API (ASP.NET Core or Spring Boot), a relational database (SQL Server or PostgreSQL) with versioned schema migrations (EF Core migrations or Flyway), and authentication through OAuth 2.0 / OpenID Connect with an identity provider rather than hand-rolled passwords.
- Default to a modular monolith with clear internal boundaries, and explain why: one deployable is simpler to run and debug, and the module boundaries allow a later split into services when a part needs to scale or ship independently.
- Cover the cross-cutting pieces: input validation at the API boundary, structured logging with a correlation id, configuration and secrets outside the code, a CI pipeline running tests on every change, and containerised deployment to a cloud host (AWS or Azure).
- Close on scaling and trade-offs: keep the API stateless so instances can be added behind a load balancer, add caching and read replicas for read load, and name what you deliberately left out of the first version.
Follow-up
- Where does session or user state live once you run several API instances?
- At what point would you split the monolith into services, and which part would go first?
- How would you handle large file uploads in this design?
Describe your testing strategy for a newly developed API. How do you balance unit tests, integration tests, an
Describe your testing strategy for a newly developed API. How do you balance unit tests, integration tests, and end-to-end tests?
Approach
- Use the test pyramid as the shape: many fast unit tests on domain rules and validation with no I/O, fewer integration tests through the HTTP layer with a real database, and a small set of end-to-end tests for the main user flows only.
- Integration layer: host the API in-process (WebApplicationFactory in ASP.NET Core, @SpringBootTest with MockMvc in Spring) against a real database engine, for example in a Testcontainers container. Avoid the EF Core in-memory provider for query tests, because it does not enforce relational behaviour such as constraints.
- Enumerate cases per endpoint beyond the success path: validation failures (400), missing or wrong credentials (401 and 403), not found (404), conflicts and duplicate submissions (409 or an idempotency key), pagination limits, and concurrent updates.
- Isolate test data (a transaction rolled back per test, or a fresh schema per run) so tests can run in any order, and stub third-party HTTP dependencies (WireMock or similar) instead of calling them.
- Wire it into CI: unit and integration suites on every change, end-to-end on deploy to a staging environment, and add consumer-driven contract tests (such as Pact) if other teams call the API.
Follow-up
- Code coverage is high but bugs still reach production. What would you change?
- How do you keep end-to-end tests from becoming flaky?
- How would you test the API's behaviour when a downstream service times out?
Every query on one table stalls for forty seconds mid-deploy
During a release on PostgreSQL, every query touching resource times out for about 40 seconds and then recovers with no intervention. The release ran one migration, ALTER TABLE resource ADD COLUMN archived_reason TEXT, and the migration log shows it completing in 6 ms. Unrelated tables showed no change in error rate. Explain how a 6 ms statement caused a 40-second stall, give the ordered checks you would run on a live system to confirm it, and give the migration procedure that prevents a repeat.
Approach
- Separate the statement's duration from the lock's duration. ADD COLUMN with no default is a catalogue-only change and genuinely runs in milliseconds, but it requires ACCESS EXCLUSIVE, and it cannot acquire that until every transaction already touching the table has finished.
- Account for the queueing, which is the part that surprises people. A lock request that is waiting blocks later requests for conflicting modes behind it rather than letting them overtake, so one long-open transaction holds the DDL and the DDL holds all the traffic. The stall length is set by the longest open transaction, not by the size of the change.
- Confirm on a live system in this order: pg_stat_activity for that table ordered by xact_start, looking for the oldest transaction and specifically for state = idle in transaction; then pg_locks where granted = false to find the waiter; then join them on pid to name blocker and blocked. pg_blocking_pids() does that join for you and is the fastest single call.
- Prevent rather than merely time it better. Set lock_timeout to a second or two on the migration session so the DDL abandons the queue after a bounded wait and is retried, instead of holding it for as long as the oldest transaction lives. Be exact about what that buys: queries arriving during the wait still queue behind the pending ACCESS EXCLUSIVE request, so each attempt costs them up to one lock_timeout of added latency. The outage goes from 40 seconds to about one second per attempt, not to zero. Also run migrations away from deploy-time peaks, and put a statement timeout and an idle-in-transaction timeout on the analytics role that opens the long transactions.
Follow-up
- The same release also wants NOT NULL on that column. What is the sequence that gets there without a long lock?
- Your lock_timeout retry fails ten times in a row because the analytics transaction is always open. What do you change?
The plan follows the five reported stages: OOP, SQL and coding for the technical screens, a practice build for the take-home, and stories for the competency and panel interviews. Practice-library items are PracHub's own exercises, included where they strengthen a day.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and fix your stack
- List the five reported stages and the question types each is reported to cover, and mark the one you are least ready for.
- Choose the language (C#/.NET or Java) and database engine (SQL Server, Oracle or PostgreSQL) you will use in every answer.
- List five projects from your history as candidates for behavioral stories.
Deliverable: A one-page loop map with your weakest stage marked, a written language and database choice, and a list of five story projects.
02Object-oriented design answers
- Write a short code example in your language showing all four pillars, with polymorphism as the focus.
- Write the abstract class versus interface comparison with a concrete decision rule and a short code snippet.
- Refactor a tightly coupled class pair so that one depends on an interface, and write down how that improves cohesion and coupling.
- Pick one design pattern you have used and write when it helps and when it hurts.
Deliverable: A code file with a polymorphism example and a refactor, plus four written spoken-answer outlines for the OOP questions.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗03SQL and data modelling
- Write the second-highest query two ways without analytic functions and test both with ties, NULLs and a single-row table.
- Create small tables and show inner, left and cross join results side by side, with one realistic cross join use.
- Take one table and write both its 3NF and denormalized forms, then list the read and write costs.
- Work through the PracHub practice debugging exercise about queries stalling during a deploy, then outline how you would tune a slow query using an execution plan and indexes.
Deliverable: A SQL file with tested queries, a join comparison, a 3NF versus denormalized design, and a written slow-query checklist.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗04Whiteboard coding and web application architecture
- Solve the maximum-sum contiguous subarray problem on paper with a linear-time approach, and test an all-negative array and an empty array.
- Write a spoken walkthrough for building a web application from scratch: requirements, components, data model, API, tests, deployment.
- Sketch a multi-tenant claims schema and note how you would isolate tenants.
- Optionally, do the PracHub practice coding exercise about diffing a projection against the primary for more data-oriented coding.
Deliverable: A tested subarray solution with a written complexity note, a one-page architecture outline, and a schema sketch.
Practice prompt ↗Practice prompt ↗Practice prompt ↗05Take-home rehearsal: API, tests and error handling
- Build a small REST API for policyholder records with validation, a consistent error format and a repository layer behind an interface.
- Write unit tests for the validation and error paths, and one integration test against a real or in-memory database.
- Write down your testing strategy for a new API, covering the balance between unit, integration and end-to-end tests, and how errors flow and are logged across layers.
- Try the PracHub practice coding exercise on request idempotency fingerprints to see how repeat requests should be handled.
Deliverable: A working API repository with tests and a README, and a written error-handling and testing-strategy note.
Practice prompt ↗Practice prompt ↗Practice prompt ↗06Behavioral story bank
- Write STAR outlines for the difficult-stakeholder, complex-project, missed-deadline and fast-learning questions, each naming your own decision and the result.
- Write two further stories for the reported scenarios: a teammate who disagreed with your architecture, and vague requirements from business analysts.
- Prepare your answer to a self-rating question, with the number and reasons.
- Say each story aloud and trim any sentence that does not carry a decision or result.
Deliverable: Six written STAR outlines and a self-rating answer, each cut down to what you would actually say.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗07Mixed mock and weak-spot review
- Answer aloud in sequence: abstract class versus interface, the join comparison, the web application walkthrough and the missed-deadline question.
- Record or write down where you hesitated or used loose language, and tighten those answers.
- Re-read your take-home README as a stranger would and fix anything that does not run from a clean clone.
Deliverable: A list of weak spots with revised answers, plus a final checked README.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Reported behavioral material for this loop centers on conflict resolution, delivering under pressure and communicating delays early, taking code-review feedback, and working with business analysts when requirements are vague. Candidates are advised to stress collaboration with other engineers, system administrators and business stakeholders, and to be ready for self-assessment questions. Prepare real stories where your own decision is visible.
How do you handle error propagation and logging in a multi-tiered application?
How do you handle error propagation and logging in a multi-tiered application?
Approach
- Describe the layers first: presentation or API, service or domain, data access. Each layer handles errors at its own level of abstraction. The data layer catches driver-specific failures (timeout, unique-key violation, deadlock) and rethrows them as domain exceptions, so upper layers never depend on a database vendor.
- Preserve the cause when wrapping. In Java, pass the original exception as the cause. In C#, rethrow with a bare 'throw;' or wrap with an inner exception; 'throw ex;' resets the stack trace. Never swallow an exception with an empty catch block.
- Separate expected business errors (validation failure, record not found, rule violation, optimistic-concurrency conflict) from unexpected faults. Map them once, at the outermost boundary (global exception handler or middleware), to 400, 404, 409 or 422 for expected cases and a generic 500 with a correlation id for unexpected ones. Never return stack traces to callers.
- Log once, where the error is finally handled, not at every layer, to avoid duplicate noise. Use structured logs with a correlation id generated at the edge and passed through downstream calls, so one request can be traced across tiers. Use levels deliberately and mask personal fields such as policyholder identifiers.
- Add the edge cases: roll back the transaction when an exception passes through it, retry only transient failures on idempotent operations with backoff, and use timeouts so a slow dependency cannot hold threads.
Follow-up
- Should you log at the throw site or the catch site, and why does logging at both produce problems?
- How would you trace a single failed request across three services?
- What do you return to the client for an unexpected exception, and what stays in the log only?
Tell me about a time you had to work with a difficult stakeholder or team member to deliver a project. How did
Tell me about a time you had to work with a difficult stakeholder or team member to deliver a project. How did you resolve the friction?
Approach
- Choose a conflict about requirements, scope, priorities or a technical decision, not a clash of personalities. Name the stakeholder's role (for example a business analyst, product manager or senior engineer) and what they needed, so they read as a person with a reason.
- Give the situation in two sentences, then your task. Spend most of the answer on actions in order: you asked questions to understand their constraints, restated the requirement in writing, brought evidence (a prototype, an estimate, a defect list) and offered options. Escalation, if any, came after a direct conversation.
- State the result and the working relationship afterward: what shipped, what each side gave up, and how you kept communicating.
- The story fails when the other person is the villain, when you only complied without judgment, or when it never resolves. Include what you would do differently.
Follow-up
- What if they had still refused after you showed the evidence?
- How did you keep the rest of your work on track during the conflict?
- What would you do differently if you met the same person again?
Describe a complex technical project you led or contributed to significantly. What was your role, and what wer
Describe a complex technical project you led or contributed to significantly. What was your role, and what were the key outcomes?
Approach
- Pick a project that you can explain at architecture level and in which your role is distinct. Open with the goal and your scope in two sentences, then state clearly which parts you designed and built and which belonged to teammates.
- Cover two or three real decisions: what options you weighed (database design, API shape, build versus reuse, migrating from a legacy component), why you chose one, and what it cost. Be ready to draw the components on a whiteboard.
- Give outcomes you can defend: shipped on time or not, defects avoided, queries or release process improved, with figures only if they are really yours. A single honest limitation or later fix makes the story credible.
- Name the collaborators (engineers, system administrators, business stakeholders) and how you worked with them, since collaboration is a reported emphasis. The usual mistake is claiming team results as personal ones or staying vague about outcomes.
Follow-up
- Which part of this was yours, and which was a teammate's?
- What was the hardest trade-off, and what did you reject?
- If you rebuilt it today, what would you change?
How do you handle a situation where you realize a project deadline cannot be met?
How do you handle a situation where you realize a project deadline cannot be met?
Approach
- Show you detected the problem early, from evidence: a task that grew, a dependency that slipped, or a spike that revealed hidden work. Say how you re-estimated, with a range and the assumptions behind it.
- Tell the stakeholder promptly and bring options, not just bad news: cut or phase scope, move the date, add help (with its ramp-up cost) or accept reduced polish, with the risk of each. Let the person who owns the priority choose.
- Describe follow-through: you updated the plan, communicated progress at a steady cadence and protected the core behavior from being cut, such as validation or data integrity.
- Close with the outcome and what you changed in how you estimate or flag risk. The usual failure is silence until the last day, or quietly working extra hours and hiding the slip.
Follow-up
- How early is early enough to raise it, and what triggers that call for you?
- What if the stakeholder insists on both the full scope and the original date?
- What did you change in your next estimate?
Tell me about a time you had to learn a new technology quickly to solve an urgent business problem.
Tell me about a time you had to learn a new technology quickly to solve an urgent business problem.
Approach
- Choose a real urgent business problem and say what was at stake, then name the technology and what you already knew that transferred (for example, another framework in the same language or another relational database).
- Describe a method: narrow to the minimal slice needed, read the official documentation, build a small throwaway spike, ask someone experienced for a short review, and write tests that check your understanding before building the real feature.
- Show how you managed risk: what you chose to learn later, how you kept the first version simple, and who reviewed your work.
- Finish with delivery and consolidation: what shipped, what you missed that surfaced later, and how you shared notes or a short guide with the team. Do not claim mastery in days or describe copying a tutorial.
Follow-up
- How did you know you were using it correctly and not just getting it to run?
- What did you skip that later caused a problem?
- How did you pass the knowledge on to the team?
- 01
Tell me about a time you had to work with a difficult stakeholder or team member to deliver a project. How did you resolve the friction?
- 02
Describe a complex technical project you led or contributed to significantly. What was your role, and what were the key outcomes?
- 03
How do you handle a situation where you realize a project deadline cannot be met?
- 04
Tell me about a time you had to learn a new technology quickly to solve an urgent business problem.
- 05
Describe a time when a team member disagreed with your architectural approach. How did you handle the discussion and arrive at a resolution?
- 06
Tell me about a project where you had to work closely with business analysts to translate vague requirements into concrete technical deliverables.
How long does the Argo Group Software Engineer process take?
Candidates report five stages over roughly 4-6 weeks. Reports also range from a two-stage evaluation to a longer sequence, and some describe timelines of several weeks or even months. Stay in regular, polite contact with the recruiter for status.
Argo Group Software Engineer candidate reports ↗What does the technical assessment look like?
Candidates describe a take-home project, where you build a working application from scratch, plus live technical discussions. The live sessions are reported to cover OOP concepts, SQL queries and a whiteboard problem. Prepare all three in your chosen language and database.
Argo Group Software Engineer candidate reports ↗How should I prepare for the behavioral rounds?
Use STAR (Situation, Task, Action, Result) on real examples of delivery, teamwork, conflict and learning something fast. Keep the situation short, make your own decision the center, and finish with the outcome. Reports suggest emphasizing collaboration with engineers, system administrators and business stakeholders, and being ready for a self-rating question.
Argo Group Software Engineer candidate reports ↗Which languages and databases should I prepare in?
Requirements candidates describe name an object-oriented language such as C#/.NET or Java, and relational databases such as SQL Server, Oracle or PostgreSQL. AWS or Azure, Angular or React, containerization and insurance familiarity are listed as nice to have. Practise in one language and one database rather than spreading thin.
Argo Group Software Engineer candidate reports ↗How should I approach the take-home project?
Reports advise treating it as production code: logical file layout, clean unit tests, handled edge cases and a README that explains design decisions and how to run it. Example scenarios include a REST API for policyholder data with validation and error handling. Ask the recruiter in writing about time allowed and submission format, as neither is reported.
PracHub Software Engineer practice ↗How do I answer a request to rate my skills from 1 to 10?
Candidates are advised to avoid both extremes. Choose a number you can defend, then immediately name concrete strengths from real projects and one area you are still developing. A rating that comes with evidence and honesty reads better than any particular number.
Argo Group Software Engineer candidate reports ↗Do I need insurance experience?
Familiarity with insurance or financial services is listed as nice to have, not required. It still helps to know the vocabulary that appears in the reported work (policies, policyholders, underwriting, claims, brokers) so your schema and API examples sound natural.
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.
- 01Argo Group 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.