Interview guides · Arrow Electronics

Arrow Electronics Software Engineer Interview Guide

Arrow Electronics Software Engineer interview guide: reported rounds, Java, SQL and Angular questions, behavioral prompts and a 7-day prep plan.

The 60-second brief

Arrow Electronics is described as a global technology distributor with semiconductor and cloud-services work alongside it. Candidates report that Software Engineers build and maintain the systems behind inventory, order processing and customer-facing digital tools, and work with Field Application Engineers, product managers and cross-functional IT teams. Reports also describe the hiring process as decentralised: each business unit runs its own conversations, so the stack and the style of your loop depend on the team that is hiring.

This guide is for Software Engineer candidates, from early-career to senior, preparing for the Arrow Electronics loop.

Candidates report two stages over roughly two to four weeks: a recruiter or HR phone screen, then one or more technical rounds that can mix coding, whiteboard work and deep dives into past projects.

Focus areas

Technical interview fundamentals (concepts & problem-solving
RTL coding (hardware design)
AXI protocol (AMBA AXI)

Overview

The reported questions fall into two groups. The first is technical and domain-specific: Core Java and J2EE architecture, Angular, Spring and Hibernate, SQL tuning and PL/SQL procedures, and how you keep code scalable and maintainable. The second is situational: a difficult project, escalations across teams, pressure before a deadline, a process you improved, and why you want to move into semiconductors or technology distribution. Nothing in the reported set is a puzzle-style algorithm question, so the preparation weight sits on explaining real work precisely.

Candidates describe being asked to go deep on projects listed on their resume, including why a tool or pattern was chosen and what the trade-offs were. That makes your own history the main study material. For each project, be ready to state your role, the design decisions you owned, what broke, and what you would change. Any technology on the resume is open to a follow-up, so cut or refresh anything you could not discuss for several minutes.

Reports also mention scenario-style questions built around order management or inventory, such as designing a workflow for an order management system. Prepare these as small design exercises: entities (order, line item, inventory position, customer), state transitions, what happens on retry or partial failure, and which queries the system must answer quickly.

Because the loop varies by business unit, expect either a structured technical assessment or a conversational discussion of your projects, and be ready for both. Some reports list hardware-design topics such as RTL coding, the AXI protocol and static timing analysis; those do not match the Java, SQL and Angular questions reported for this role, so confirm with your recruiter which stack your unit uses before spending time on them.

The Arrow Electronics interview process

Candidates report these two stages, and note that the depth of the technical stage differs between business units.

HR/Recruiter Phone Screen

Candidates report an initial call with a recruiter or HR contact to review your background and your fit for the role. No technical questions are tied to this stage in the reports, so treat it as a short, structured conversation about your experience, your motivation for moving into semiconductors or technology distribution, and the logistics of the process. Use it to ask which business unit is hiring, which stack the team uses (Java, SQL, Angular, Oracle) and what the technical rounds will look like, since reports say the process is inconsistent across units and scheduling can slip.

What to demonstrate

How clearly you summarise your background and why you want this role
Whether your motivation for the semiconductor or distribution industry sounds specific
Basic fit on stack, location and availability as you describe them

How to prepare

Write a short spoken summary of your career that ends on the Java, SQL or Angular work most relevant to the posting
Prepare a concrete answer for why you are moving into semiconductor or technology distribution, tied to inventory or order-processing problems you have worked on
Ask the recruiter which business unit and stack the role sits in and what format the technical rounds take, and note the answer
Agree how you will follow up if scheduling goes quiet, since candidates report delays

Technical Rounds

Candidates report one or more technical rounds that may include coding challenges, whiteboard sessions, or discussions of previous work. The reported technical questions cover Core Java and J2EE, Angular, Spring and Hibernate, SQL and PL/SQL optimisation, and keeping code scalable and maintainable, alongside troubleshooting and situational questions. Approach it as a project defence first: for every system on your resume, know the architecture, your part in it, and the reasons behind the main choices. For any coding or whiteboard task, restate the problem, ask about unclear requirements before you start, and write readable code with the edge cases named.

What to demonstrate

Working code and clear reasoning if a coding challenge or whiteboard task is set
Understanding of the architecture behind the projects on your resume, beyond syntax
Ability to explain technology choices and trade-offs in Java, SQL, Spring, Hibernate or Angular work
How you structure an open-ended scenario such as an order-management workflow

How to prepare

For each resume project, write the architecture in five lines, your specific contribution, one decision you would change, and one failure you debugged
Review Core Java collections, concurrency and memory, then Spring dependency injection and transactions, Hibernate lazy loading and the N+1 problem, and Angular services and RxJS
Practise SQL tuning on a real query: read the execution plan, name the missing index, and rewrite a correlated subquery as a join

Where candidates lose points

Listing technologies on the resume that you cannot discuss in depth

Review each project and technology on your resume and write what you personally built, one design decision and one failure. Remove anything you could not explain for several minutes.

Answering the Spring, Hibernate or Angular question with a list of buzzwords instead of one project

Name which of the three you used and give one decision with a consequence, such as fixing an N+1 query with join fetch or avoiding a leaking RxJS subscription.

Describing SQL tuning as 'add an index' without reading a plan

Practise the sequence: read the execution plan, find the scan or join that costs most, check statistics and predicates, then change the query or index and re-measure.

Telling the escalation or difficult-project story as blame, or as a story about a different person's decision

Choose a story where you made decisions. State facts and impact neutrally, say what you asked for, and describe what changed in how you worked together afterwards.

Starting a coding or whiteboard task before clarifying the requirements

Restate the problem, ask about inputs, volume and failure behaviour, then outline your approach before writing. Candidates report that open-ended questions are common, so clarifying scope is expected.

Questions & practice

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

Easy · hashing · at-least-once · aggregation

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

Approach

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

Follow-up

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

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

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?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

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?

How do you approach optimizing SQL queries or managing PL/SQL procedures?

Medium · Technical and Domain Expertise

Approach

Start from evidence, not guesses: get the real execution plan (in Oracle, DBMS_XPLAN.DISPLAY_CURSOR with the ALLSTATS LAST format after running with the gather_plan_statistics hint; in Postgres, EXPLAIN ANALYZE). Compare estimated and actual row counts at each step. A large gap usually means stale statistics, which I refresh with DBMS_STATS.GATHER_TABLE_STATS before touching the SQL.
Keep predicates sargable. Wrapping an indexed column in a function (UPPER(col), TRUNC(order_date)) or comparing it to a value of another type (implicit conversion) stops a plain B-tree index from being used. I rewrite the predicate as a range (order_date >= :d AND order_date < :d + 1) or add a function-based index.
Design composite indexes from the query: equality columns first, the range column last, and the selected columns appended when a covering index saves the table lookup. Every extra index slows inserts and updates, so I name that cost too.
In PL/SQL, prefer set-based work to row-by-row loops. A single INSERT ... SELECT or MERGE usually beats a cursor loop that runs one DML per row. When I do need procedural logic, I use BULK COLLECT with a LIMIT clause plus FORALL, which cuts PL/SQL-to-SQL context switches without loading every row into PGA memory. SAVE EXCEPTIONS lets a batch report its failing rows instead of aborting.
For maintaining procedures: group them in packages (spec plus body), use bind variables rather than concatenated dynamic SQL (fewer hard parses, no injection), and never write WHEN OTHERS THEN NULL. I log and re-raise instead. Transaction control stays with the caller, and every change ships as a versioned script with a before-and-after timing.

Follow-up

The plan shows a full table scan even though the filter column is indexed. What could cause that? (Low selectivity, a function or implicit conversion on the column, stale statistics, or an IS NULL filter on a single-column B-tree index, which does not store all-null keys.)
How would you process ten million order rows in a PL/SQL job without running out of memory or holding locks for the whole run?
A query is fast for most customers but slow for one very large customer. How do you diagnose a plan that depends on the bind value?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

How do you ensure your code is scalable and maintainable?

Medium · Technical and Domain Expertise

Approach

Separate the two properties. Maintainability is how cheaply the next person can change the code safely. Scalability is how it behaves as load or data grows. Anchor both in one real system from your own work, for example an order-processing service.
Maintainability: a layered structure (controller, service, repository in a Spring app), dependencies injected behind interfaces so business logic is unit-testable without a database, small classes with one responsibility, and unit plus integration tests running in CI on every pull request, with code review as the gate before merge.
Scalability: keep service instances stateless so they scale horizontally behind a load balancer, with state in the database or a shared cache. Page large result sets, size the connection pool deliberately, and move slow work (emails, downstream sync) onto a queue with idempotent consumers so retries cannot double-process an order.
Data access is usually the first bottleneck. Watch for the ORM N+1 pattern in Hibernate (one query per child row) and fix it with JOIN FETCH, an entity graph or @BatchSize. Cache read-heavy reference data only with an explicit invalidation rule, because every cache trades freshness for speed.
Measure before and after: set a target (p95 latency, throughput, error rate), profile or load-test to find the actual hotspot, then optimise that. Name the trade-off you accepted, such as an extra abstraction layer that made testing easier but added indirection.

Follow-up

An endpoint that lists orders with their line items gets slower as orders grow. How do you find out whether it is an N+1 problem, and how do you fix it?
Two instances of your service receive the same order message. What stops the order from being processed twice? (An idempotency key with a unique constraint, or optimistic locking with a version column.)
You inherit a large module with no tests and need to add a feature. How do you keep it maintainable without a full rewrite?

Make the resource write endpoint safe for retrying clients

Easy · idempotency · unique constraints · retries

The edge API accepts POST /v1/resources at 1.2k writes/second peak under a 400 ms p99 budget, and clients retry on timeout. idempotency_key has PRIMARY KEY (tenant_id, idempotency_key) plus request_fingerprint CHAR(64), state in ('in_flight','succeeded','failed'), response_status, response_body, resource_id, locked_until and expires_at. Specify the exact sequence the handler runs: what the second request does when it arrives while the first is still executing, what a retry carrying a different body receives, what happens when a process dies mid-request, and how the table is kept from growing without bound.

Approach

Start from the race rather than the happy path. Insert the key row first, in its own short transaction, with state 'in_flight' and locked_until set to now() plus the request deadline. The unique constraint on (tenant_id, idempotency_key) is the arbitration mechanism: exactly one caller commits the insert, and every other caller takes a unique violation (SQLSTATE 23505) and becomes a follower. Reading the table and then inserting is a check-then-act race that both callers pass, and they pass it most often under the load that generates the retries.
Give the follower a branch for every state it can observe, with no fall-through to doing the work: fingerprint mismatch means the key is being reused for a different request, so reject with 422 and never replay the stored response; 'succeeded' replays response_status and response_body verbatim; 'failed' allows a fresh attempt; 'in_flight' with locked_until in the future is answered with 409 and a retry hint, or a short bounded wait, because the only alternative is executing the effect twice.
Commit the effect and the record of the effect together. The resource insert, its resource_revision row, its outbox_event row and the transition of the key row to 'succeeded' all happen in one transaction, so no crash can leave the work done and the key still 'in_flight'. The earlier insert is deliberately a separate transaction: it has to be visible to a concurrent caller before the work starts, which an uncommitted row is not.
Close the wedged-key path. A process that dies after the insert leaves a row that would otherwise block that key forever, which is what locked_until exists for. Reclaim with a single conditional statement, UPDATE ... SET state='in_flight', locked_until=now()+interval WHERE ... AND state='in_flight' AND locked_until < now(), and treat a zero rowcount as losing the reclaim. Two statements that read and then update reintroduce the original race one layer down.

Follow-up

The stored response body averages 200 KB and this table is now the largest in the database. What do you store instead, and what does a replay return once the body has been pruned?
A client library generates a fresh idempotency key on every attempt. What breaks, which layer should have caught it, and does the server have any defence?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

The plan is built around the two reported stages: the recruiter call on day one, the technical topics candidates report on days two to five, and the troubleshooting and situational stories on days six and seven.

Day 1 — Map the loop and inventory your resume

List the two reported stages, then write down which business unit and stack you are interviewing for, or note the question to ask your recruiter.
For every project on your resume, write your role, the architecture in five lines, one decision you would change and one bug you debugged.

Deliverable: A loop map and a one-page project inventory with the weakest project marked.

Day 2 — Core Java and J2EE experience

Review collections internals, concurrency utilities, memory and garbage collection, and exception handling, writing one page of notes for each from your own experience.
Draw the layered architecture of your main Java system, marking where the transaction boundary and datasource sat.
Rehearse the Core Java or J2EE experience answer aloud, ending on one decision and its consequence.

Deliverable: A one-page Java reference and a rehearsed spoken answer on the Core Java and J2EE question.

Day 3 — Spring, Hibernate and Angular

Write a short Hibernate example that shows an N+1 problem and fix it with join fetch or batch size, noting the SQL each version runs.
Write notes on Spring dependency injection, bean scopes and how @Transactional proxies work, including the self-invocation pitfall.
List the Angular concepts you have used (services, RxJS, guards, interceptors) and attach one project example to each.

Deliverable: A written N+1 example, Spring transaction notes and an Angular concept list with a project for each.

Day 4 — SQL and PL/SQL optimisation

Take a slow query you know, read its execution plan, and write what you would change in the query or the indexes.
Write one paragraph on how you structure and maintain a PL/SQL procedure: parameters, error handling, and testing.

Deliverable: An annotated execution plan, a keyset paging solution and a PL/SQL maintenance note.

Day 5 — Scalable, maintainable code and an order workflow

Design an order-management workflow on paper: entities, states, failure and retry behaviour, and the queries it must serve.
Write your answer to the scalable and maintainable code question with two concrete examples from your own code.

Deliverable: A workflow diagram with state transitions and two written maintainability examples.

Day 6 — Troubleshooting and project stories

Write the troubleshooting story in STAR form, with the sequence from evidence to root cause to prevention.
Write the difficult-project story and the process-improvement story, each with a baseline and an outcome.

Deliverable: Three written stories (troubleshooting, difficult project, process improvement) and one debugging write-up.

Day 7 — Escalation, deadline pressure, motivation and a mock

Write the escalation story, your stance on team expectations under a deadline, and your answer on why semiconductor or technology distribution.
Run a full spoken mock with a friend: recruiter-style call first, then a project deep dive and one scenario question.
Write two questions for the hiring manager about the business unit and its stack.

Deliverable: Three finished answers, a recorded mock and two questions for the hiring manager.

Project stories and situational answers

The reported situational questions concern troubleshooting a hard fault, resolving a difficult project, handling escalation across teams, pressure before a deadline, improving a process, and the move into semiconductors or technology distribution. Build five or six stories from your own work that cover these, each with the situation, your decision, the trade-off and a measurable result, and reuse them across questions.

Can you explain your experience with Core Java or J2EE architectures?

Medium · Technical and Domain Expertise

Approach

Choose one system you built or maintained and describe its layers in order: presentation (servlets, JSP or an Angular front end), business services, persistence (JDBC, JPA or Hibernate) and how it was deployed on an application server. Say what you personally owned in each layer rather than describing the stack in general.
Show Core Java depth with specifics you have used: HashMap and ConcurrentHashMap behaviour, ExecutorService or synchronized versus java.util.concurrent locks, memory and garbage collection symptoms, streams and Optional, and checked versus unchecked exceptions. Anchor each in a moment where it mattered in your code.
Cover J2EE concepts as they apply to your work: container-managed transactions and where the transaction boundary sat, connection pooling, session handling, and how you moved from EJB-style code to Spring or Jakarta EE if you did.
Be honest about the edges. If you have used Java in a Spring Boot service but never in a full J2EE container, say that, and show you understand the concepts (JNDI datasources, JTA transactions, deployment descriptors) well enough to learn the rest quickly.

Follow-up

How does HashMap resolve collisions, and why is it unsafe to share between threads?
Where did the transaction boundary sit in that system, and what happened to a half-finished operation on failure?
What would you change if you rebuilt that architecture today?

Describe a time you had to troubleshoot a complex error in your code; what was your process?

Medium · Technical and Domain Expertise

Approach

Use STAR but spend most of the time on process. Pick a bug that was hard, such as an intermittent failure, a production-only error, a memory leak or a race condition, rather than a typo found on the first read.
Walk through the sequence: how you reproduced it or captured evidence (logs, stack trace, heap dump, query plan), how you narrowed the cause (bisecting commits, disabling components, a minimal repro), what hypotheses you ruled out and how, and what finally confirmed the root cause.
Separate the immediate fix from the lasting one: the change that stopped the symptom, the regression test you added, and any monitoring or alert so the same class of fault is caught earlier next time.
Name the cost and the risk: who was affected, what could have gone wrong while you investigated, and what you checked before releasing the fix. Avoid stories that end at a restart or a retry with no explanation of why it failed.

Follow-up

How did you know that was the root cause and not just a symptom?
What would you have done if you could not reproduce it?
What did you change afterwards so the bug would be found sooner?

What is your experience with Angular, Spring, or Hibernate frameworks?

Medium · Technical and Domain Expertise

Approach

State precisely which of Angular, Spring and Hibernate you have used, in which project and for how long. Answer each separately rather than claiming all three, then give one concrete decision you made with each.
Angular: components and services with dependency injection, RxJS observables for HTTP and state, route guards, HttpClient interceptors, and how you avoided memory leaks by unsubscribing or using the async pipe.
Spring: inversion of control and bean scopes, how @Transactional works through proxies (including the self-invocation pitfall), controller and service layering for REST endpoints, and how Spring Boot configuration was organised in your project.
Hibernate: entity mappings, lazy versus eager fetching, the N+1 select problem and fixing it with join fetch, entity graphs or batch size, and the session boundary behind LazyInitializationException. Cite a query you tuned or a bug you traced to the persistence layer.

Follow-up

How would you detect and fix an N+1 problem in a Hibernate-backed endpoint?
Why can a @Transactional method called from another method in the same class fail to start a transaction?
How do you stop an RxJS subscription from leaking when a component is destroyed?