Allianz Software Engineer Interview Guide

The 60-second brief

Allianz is a financial services and insurance provider. The role description candidates see for Software Engineers mentions customer-facing digital portals, internal enterprise platforms and policy-management systems, some of them older systems being modernized. That description frequently mentions Java with Spring Boot, RESTful APIs and microservices, Spring Data JPA and Hibernate against relational databases, and Angular front ends. Exposure to event-driven design, Docker, Kubernetes and cloud platforms is listed as a plus.

This guide is for Java backend engineers preparing for the Allianz Software Engineer loop; the requirements candidates describe range from mid-level to senior. It covers the five reported stages, the fifteen questions candidates report (Spring Boot internals, microservices, JPA tuning, event-driven design, project trade-offs, production debugging, Angular integration and behavioral topics), and a seven-day plan that sequences them.

Candidates report five stages over roughly 4 to 6 weeks: a recruiter call, technical evaluations, virtual interviews, deep-dive questions and a final HR discussion.

Focus areas

• Spring Boot
• Java
• Microservices

Overview

The reported questions centre on the enterprise Java stack. Expect to explain how dependency injection and MVC work inside Spring Boot, how services talk to each other and fail safely in a microservices setup, how you tune queries under Spring Data JPA and Hibernate, and how event-driven design helps with scale and security. Candidates also report a question on integrating an Angular front end with backend REST APIs. Prepare each of these as a concrete walk-through of something you built, with the reason you chose it and what it cost.

A second group of questions is about your own history: a project with a hard architecture trade-off, how you debug a slow production system, explaining a UML or design idea out loud without a diagram, how you keep quality up with tests and continuous integration, and how you pick up an unfamiliar technology or domain. Candidates also report that interviewers draw on specific projects and technical decisions from your CV, so every CV line should be something you can defend in detail.

The behavioral group asks why you want to move into insurance, how you resolved a disagreement, how you cope with shifting priorities in an agile cycle, where you want your technical leadership to go, and how your values connect to reliability, professionalism and customer trust. The role description also mentions code reviews, sprint planning, production troubleshooting and compliance with enterprise security standards, so stories that show those habits fit naturally.

Live coding and panel discussions are reported in the virtual interview stage, and the technical evaluations are described as covering coding skill and architectural understanding in various formats. Keep some Java coding practice in the plan alongside the framework and design preparation, and practise talking while you work.

The Allianz interview process

Candidates report five stages. Exact timing and format are said to vary by region and team, so confirm the specifics with your recruiter.

Recruiter Screening Call

Candidates describe an opening call with a recruiter covering your background, your motivation for the role and salary expectations. Candidates describe the call as covering motivation, so have a short account of your career and why this domain. Keep the call factual: stack, level, location and notice period, then ask what the remaining stages look like.

What to demonstrate

• A coherent account of your background and current stack
• Motivation for moving to this company and domain
• Alignment on salary expectations and logistics

How to prepare

• Rehearse a two-minute CV walk-through that names Java, Spring Boot and the services you owned, and ends with why insurance.
• Settle your salary range, notice period and location constraints before the call so you can state them plainly.
• Prepare two questions about the team's stack and how the later stages are organised.

Technical Evaluations

Candidates describe assessments of coding skill and architectural understanding in several formats, without a single fixed shape. Cover both sides: be able to write and explain working Java, and be able to reason about service design. The framework and architecture questions candidates report (Spring Boot internals, microservice communication, JPA tuning, event-driven design) are the natural material for the architecture side.

What to demonstrate

• Working code and an explanation of it
• Architectural understanding and trade-off reasoning
• Ability to explain technical decisions, not only name tools

How to prepare

• Trace one HTTP request through a Spring Boot app out loud, naming where each bean is injected and where the transaction boundary sits.
• Reproduce an N+1 problem with Hibernate, show the SQL it generates, and fix it with a fetch join or entity graph.
• Write a short comparison of synchronous REST calls and messaging between two services, including timeouts, retries and idempotency.

Virtual Interviews

Candidates report a mix of virtual interviews, live coding sessions and panel discussions with engineering leads. Live coding means working code visible to others, so practise solving Java problems while narrating assumptions and edge cases. A panel means several people at once: answer the person who asked, but make sure the whole group follows your design.

What to demonstrate

• Working code produced live and explained as you go
• Clarity of explanation in front of several engineers
• Design discussion and clear verbal explanation

How to prepare

• Solve the rolling failure rate, overlapping job attempts and bounded-lateness merge practice problems in plain Java while speaking aloud.
• Describe a sequence diagram of a policy-update flow in words only, then check that a listener could redraw it.
• Prepare a short Angular-to-REST integration answer covering typed services, an auth interceptor and cross-origin setup.

Deep-Dive Questions

Candidates describe in-depth questions about career history, project decisions and professional goals, and a tip reports that interviewers pull specific projects and technical choices from your CV. Treat this as a defence of your own record: for each major project, know the problem, your decision, the alternatives you rejected and what you would change.

What to demonstrate

• Depth and ownership in the projects you list
• Reasoning behind past architecture and design decisions
• Direction of your career and technical leadership

How to prepare

• For your three biggest CV projects, write the decision you made, one rejected alternative and one measurable result.
• Prepare a production slowness story with the steps you took: metrics, slow query log, thread dump, trace, fix and verification.
• Write a five-year answer that names concrete steps such as owning designs, reviewing code and mentoring.

Final HR Discussions

Candidates describe closing conversations with HR about the process and a potential offer. Use it to settle logistics and to answer the values and motivation questions cleanly. Have your compensation expectations consistent with what you said in the first call, and ask about next steps in writing.

What to demonstrate

• Consistency with what you said earlier in the loop
• Motivation and fit for the company and domain
• Readiness to move to an offer discussion

How to prepare

• Re-read your first-call notes so salary, notice period and location statements match.
• Prepare a values answer that uses one real incident on reliability or customer trust, not a list of adjectives.
• List the open questions about team, stack and onboarding you still want answered before deciding.

Where candidates lose points

Giving textbook definitions of dependency injection and MVC with no request to follow

Trace one request through a Spring Boot app: the dispatcher, controller, service, repository, and where the container injects each bean. Prefer constructor injection and say why it helps testing.

Answering the JPA and Hibernate question with "add an index" and nothing else

Turn on SQL logging, show the N+1 pattern from lazy collections, and fix it with a fetch join, entity graph or DTO projection. Mention pagination, read-only transactions and checking the query plan.

Listing microservice tools without saying what happens when a call fails

For each interaction state the timeout, whether the call is idempotent so it can be retried, and how errors are mapped. For cross-service data consistency, describe a saga or outbox rather than a distributed transaction.

Telling project stories in "we" with no named decision, rejected option or result

Prepare each CV project as: problem, my decision, one alternative I rejected and why, and one measurable result. A tip reports that projects are pulled straight from CVs.

Treating the insurance-move and values questions as small talk

Prepare a specific reason and one incident for reliability or customer trust. Name the domain challenges you expect and your first moves to learn them.

Questions & practice

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

1. Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
2. Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
3. Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
4. Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

• The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
• The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

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

1. 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.
2. 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.
3. 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.
4. 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

Medium · window functions · event tables · frame semantics

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

1. 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.
2. 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.
3. 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.
4. 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?

Can you explain how dependency injection and the MVC pattern are implemented within the Spring Boot framework?

Medium · Technical and Architecture

Approach

1. Start from the ApplicationContext: @SpringBootApplication combines @SpringBootConfiguration, @EnableAutoConfiguration and @ComponentScan, so classes marked @Component, @Service, @Repository or @Controller become beans, @Bean methods add more, and auto-configuration registers defaults conditionally (@ConditionalOnClass, @ConditionalOnMissingBean).
2. Explain injection styles: I use constructor injection with final fields (a single constructor needs no @Autowired since Spring 4.3), so dependencies are explicit and the class is testable without the container. I resolve two candidates of one type with @Qualifier or @Primary, and I keep singleton beans stateless because one instance serves all threads.
3. Walk the MVC request path: DispatcherServlet is the front controller, RequestMappingHandlerMapping picks the handler method, a HandlerAdapter invokes it, argument resolvers bind @PathVariable, @RequestParam and @RequestBody, and HttpMessageConverters (Jackson) serialise the result. @RestController is @Controller plus @ResponseBody, so no ViewResolver is involved.
4. Describe the layering: thin controllers, business rules and @Transactional boundaries in @Service classes, data access in @Repository beans, which also get persistence exceptions translated into Spring's DataAccessException hierarchy.
5. Cover the edge cases: @Transactional and other AOP features work through proxies, so a call from one method to another in the same class bypasses them; since Spring Boot 2.6 circular references fail at startup by default, and constructor injection exposes them immediately.

Follow-up

• Why does a @Transactional method called from another method of the same class not start a transaction, and how would you fix it?
• How would you test a controller without starting the whole application context?
• Two beans implement the interface you inject. What happens at startup, and how do you choose between them?

How do you handle service-to-service communication, exception handling, and security in a microservices archit

Medium · Technical and Architecture

How do you handle service-to-service communication, exception handling, and security in a microservices architecture?

Approach

1. Split communication by need: synchronous REST (RestClient, WebClient or OpenFeign) or gRPC when the caller needs the answer now; messaging through a broker such as Kafka or RabbitMQ when the work can complete later and the services should not depend on each other's uptime. Mention how services find each other (a discovery registry or Kubernetes DNS behind a gateway).
2. Make every remote call defensive: a timeout on each call, a circuit breaker (Resilience4j: closed, open, half-open) so a failing dependency is not hammered, and a bulkhead so one slow service cannot exhaust every thread. Retry with exponential backoff and jitter, but only for idempotent calls or calls carrying an idempotency key.
3. Centralise exception handling with @RestControllerAdvice and @ExceptionHandler, map domain exceptions to status codes, and return one error shape (Problem Details, RFC 9457, which Spring 6 supports as ProblemDetail) without stack traces. Retry rules by status: 4xx is not retryable, except 429 (honour Retry-After) and 408; timeouts and 5xx are retryable only when the call is idempotent or carries an idempotency key, so a 5xx on a non-idempotent write is never retried blindly. Propagate a trace ID (W3C traceparent) so one failure can be followed across services.
4. For security, authenticate users with OAuth2/OIDC and have each service act as a resource server that checks the JWT signature, expiry, audience and scopes, not only the gateway. For service-to-service calls use the client-credentials grant or mTLS, apply least privilege per service, and keep secrets in a vault rather than in config files.
5. State the trade-offs: validating tokens in every service costs a little latency but stops a compromised internal service from calling anything; JWTs cannot be revoked easily, so keep them short-lived.

Follow-up

• A downstream service is slow rather than down. What do your timeouts, retries and circuit breaker do in that case?
• How does the end user's identity reach a service three hops away, and what stops an internal service from forging it?
• A client retries a write after a timeout. How do you make sure the change is applied only once?

How do you optimize database queries and manage CRUD operations using Spring Data JPA and Hibernate?

Medium · Technical and Architecture

Approach

1. Find the problem before tuning: log the generated SQL (logging.level.org.hibernate.SQL=DEBUG) or enable Hibernate statistics, and count the queries per request. The usual culprit is N+1: one query for the parents, then one more per lazy association.
2. Fix N+1 per use case with JOIN FETCH, @EntityGraph, or batch fetching (@BatchSize or hibernate.default_batch_fetch_size). Map associations as LAZY everywhere, since @ManyToOne and @OneToOne default to EAGER. Disable spring.jpa.open-in-view, which defaults to true, so lazy loading cannot hide in the view layer.
3. For reads, return DTO or interface projections instead of whole entities, mark the method @Transactional(readOnly = true), and page with Pageable: a Page runs an extra count query and a Slice does not. For deep pages, switch to keyset pagination (WHERE id > last seen id ORDER BY id) instead of a large OFFSET.
4. For writes, rely on dirty checking inside a transaction (a managed entity needs no explicit save), turn on hibernate.jdbc.batch_size with order_inserts, and use SEQUENCE ids with a pooled optimizer because IDENTITY generation disables JDBC insert batching. Bulk @Modifying queries bypass the persistence context, so clear it afterwards (clearAutomatically = true).
5. Finish at the database: run EXPLAIN ANALYZE on the generated SQL, add composite indexes that match the WHERE and ORDER BY columns, and use @Version for optimistic locking when two users can edit the same row.

Follow-up

• A paginated endpoint that fetch-joins a collection is slow and Hibernate warns it is paginating in memory. How do you fix it?
• When would you bypass JPA for native SQL or JdbcTemplate?
• Two requests update the same entity concurrently. What does @Version do, and what should the API return to the losing client?

Can you explain event-driven design patterns and how they apply to cloud-based security and system scalability

Medium · Technical and Architecture

Can you explain event-driven design patterns and how they apply to cloud-based security and system scalability?

Approach

1. Name the patterns precisely: event notification (a small event, consumers call back for details), event-carried state transfer (the event carries the data), event sourcing (the event log is the source of truth) and CQRS (separate write and read models). For a workflow across services, compare a choreographed saga with an orchestrated one, both relying on compensating actions instead of a distributed transaction.
2. Cover delivery guarantees: brokers usually deliver at least once, so consumers must be idempotent (deduplicate on an event ID). Use a transactional outbox so the database write and the publish cannot diverge, send poison messages to a dead-letter queue, and remember that Kafka orders events only within a partition, so choose the partition key for the entity whose order matters.
3. Explain the scalability gain: producers do not wait for consumers, a queue absorbs bursts, and a consumer group scales out up to the number of partitions (extra consumers sit idle). Watch consumer lag as the scaling signal, and accept eventual consistency as the price.
4. Tie it to security: authenticate producers and consumers (mTLS, SASL or cloud IAM roles), grant per-topic ACLs on least privilege, encrypt in transit and at rest, and keep personal data out of payloads or encrypt those fields. Validate events against a schema registry so malformed events are rejected; the immutable log also serves as an audit trail, and security events such as failed logins can stream to a detection consumer.
5. Close with the hard parts: duplicates, out-of-order events, debugging a flow with no single call stack (needs correlation IDs and tracing), and evolving schemas with backward-compatible changes only.

Follow-up

• How do you guarantee an event is published if and only if the database transaction committed?
• One message keeps failing in a consumer. What happens to the messages behind it in that partition, and how do you handle it?
• How do you add or rename a field in an event without breaking consumers that have not been redeployed?

Walk us through a complex project from your past experience where you made a critical architecture or design t

Medium · Project and Practical Experience

Walk us through a complex project from your past experience where you made a critical architecture or design trade-off.

Approach

1. Pick one decision that had real alternatives and that you made or drove yourself. Open with the constraints in numbers you can defend: load, data volume, team size, deadline, and any compliance or security requirement.
2. Good material for this employer, since candidates describe the role as including modernization of older policy-management systems: a trade-off story about splitting a monolith versus a strangler migration, shared database versus each service owning its data, or consistency versus availability for policy or claim data.
3. Lay out two or three options and the criteria you compared them on (latency, consistency, operational cost, delivery time, team skills), then say why one won and, in plain words, what you gave up by choosing it.
4. Explain how you reduced the risk: a spike or prototype, a load test, a feature flag, or an incremental migration such as the strangler-fig pattern rather than a big-bang rewrite.
5. Give the outcome with a measurement (latency, incident count, cost, delivery date) and one thing you would now do differently. Keep it in the first person singular, and know every component well enough to go one level deeper: the data model, how failures are handled, and why the rejected option would have failed.

Follow-up

• What would have had to be true for you to choose the other option?
• What went wrong after launch, and how did you find out?
• If load grew tenfold tomorrow, which part of that design would you change first?

Can you explain a UML diagram or system design concept verbally without drawing it out?

Medium · Project and Practical Experience

Approach

1. Open with the purpose and the parts before any detail, so the listener has a map: what the system does, who uses it, and the components in one list (for example, a gateway, two services, a message queue and one database).
2. Walk one concrete request from end to end, as a sequence diagram in words, numbering the steps and saying for each arrow whether it is a synchronous call or an asynchronous event.
3. For a class diagram, name the classes, then each relationship with the right UML term and its multiplicity: generalization (inheritance), interface realization, association (one policy has many claims), aggregation (the part can exist on its own) and composition (the part's lifecycle is bound to the whole).
4. Keep names consistent, stop after each section to summarise, and offer to go deeper on one component instead of describing everything at the same depth.
5. Practise aloud on a system you actually built and record it: if a listener could not sketch the diagram from your recording, reorder the explanation.

Follow-up

• What is the difference between aggregation and composition? Give an example of each.
• Describe, step by step, what happens when a user logs in to a system you built.
• In the design you just described, which component failing would hurt most, and why?

What methodologies do you use to ensure code quality, testing, and continuous integration in your daily work?

Medium · Project and Practical Experience

Approach

1. Describe a test pyramid with concrete tools: many fast unit tests (JUnit 5, Mockito), Spring slice tests (@WebMvcTest for controllers, @DataJpaTest for repositories), integration tests against real dependencies with Testcontainers, consumer-driven contract tests (Pact or Spring Cloud Contract) between services, and only a few end-to-end tests.
2. Explain the quality gates around the code: reviewed pull requests with small diffs, static analysis (SonarQube, SpotBugs or Checkstyle), and coverage from JaCoCo used to find untested branches rather than as a number to hit.
3. Describe the CI pipeline: every push or pull request builds, runs the fast tests first and the slower ones after, runs static analysis and a dependency vulnerability scan (for example OWASP Dependency-Check), and keeps the main branch releasable through trunk-based development or short-lived branches.
4. Mention how changes reach production safely: feature flags to separate deploy from release, and canary or blue-green deployments with a quick rollback path.
5. Anchor it in one example of your own: a defect a test caught before release, or a pipeline change you made and what it improved, with a number.

Follow-up

• How do you test code that depends on another microservice?
• A flaky test blocks merges a few times a week. What do you do?
• Would you set a coverage threshold for the build, and at what level?

How do you approach learning a new technology or domain when starting a new project?

Medium · Project and Practical Experience

Approach

1. Start from what you must deliver, then learn just enough to do it: read the official documentation and getting-started guide, build a small end-to-end spike, and study how the existing codebase already uses the technology before writing new code.
2. For a new business domain, build a glossary with the product owner or domain experts and map each term to the data model; in insurance that means words such as policy, premium, claim and underwriting.
3. Shorten the feedback loop: pair with an experienced teammate, ship a small first change early, and ask for detailed code review on it.
4. Write down what you learn (notes, an architecture decision record, or onboarding documentation) so the next person ramps up faster.
5. Tell it as one real example: the technology or domain, how long it took you to become productive, a mistake you made early on, and what you shipped.

Follow-up

• What was the last technology you learned this way, and what did you get wrong at first?
• How do you decide that you know enough to start building?
• How would you get up to speed on a large legacy codebase with little documentation?

How do you approach debugging performance bottlenecks in a production environment?

Medium · Project and Practical Experience

Approach

1. Pin down the symptom with numbers first: which endpoint or job, p50 against p99 latency, throughput, error rate, and when it started. Correlate the start time with deploys, traffic changes, configuration changes and data growth. If customers are affected, mitigate first (roll back, scale out) and investigate after.
2. Narrow it down with distributed tracing to find the slow span, then check the resources behind it: CPU, heap and GC, thread pools, and database connection pool wait time (HikariCP exposes pending-connection metrics).
3. On the JVM, take several thread dumps a few seconds apart (jcmd <pid> Thread.print or jstack) to spot threads stuck BLOCKED on a lock or waiting on a pool; read the GC logs for long pauses or a heap that never shrinks; use JFR or async-profiler flame graphs for CPU hotspots, since both are low-overhead enough for production.
4. On the database, look at the slow query log or pg_stat_statements, run EXPLAIN ANALYZE on the worst queries, and check for N+1 access patterns, missing indexes and lock waits.
5. Change one thing at a time, confirm the fix with the same metric that showed the problem, and leave something behind: an alert on that metric, a load test or a regression test.

Follow-up

• CPU is low but latency is high. Where do you look next?
• p99 latency doubled while p50 stayed flat. What does that pattern suggest?
• How would you reproduce a problem that only appears with production data volumes?

Suggested practice checklist

The plan follows the reported stages: framework and data access first, then microservices and events, design aloud, live coding and debugging, front-end, quality and containers, and finally the behavioral and HR conversations. Each day produces something you can check.

Day 1 — Map the loop and your CV

• List the five reported stages and note which question types each could hold.
• Inventory every project on your CV with stack, your role and one trade-off.
• Pick the three strongest projects for the architecture trade-off, production debugging and disagreement stories.

Deliverable: A one-page loop map, a project inventory, and three projects flagged as your main stories.

Day 2 — Spring Boot core and data access

• Trace one request through a small Spring Boot app, noting where each bean is injected and where the transaction begins.
• Create an entity with a lazy collection, log the SQL, reproduce an N+1 and fix it with a fetch join or entity graph.
• Work through the owner-filter index question to practise reading why a query ignores an index.
• Record spoken answers to the dependency injection and MVC question and the JPA tuning question.

Deliverable: A written request trace, before and after query counts for the N+1 fix, and two recorded answers.

Day 3 — Microservices communication, security and events

• For two services, write how A calls B: REST or messaging, timeout, retries on idempotent calls only, circuit breaker and error mapping.
• Outline securing the services with Spring Security: token validation, where scopes are checked and how identity is passed between services.
• Sketch an event-driven flow for a policy change, with at-least-once delivery, idempotent consumers and an outbox, plus a saga for cross-service consistency.
• Record spoken answers to the microservices and event-driven questions.

Deliverable: A one-page service interaction and security sheet, an event flow outline, and two recorded answers.

Day 4 — Design aloud and project trade-offs

• Talk through a notification service for a large policyholder base: queueing, fan-out, retries, preferences and delivery tracking.
• Describe splitting a monolith into modules: seams, data ownership, strangler-style migration and what stays together.
• Explain a UML sequence or class diagram in words only, then check that it could be redrawn from your description.
• Write your architecture trade-off story: context, options, decision, cost.

Deliverable: Two spoken design walk-throughs, one verbal diagram explanation and a written trade-off story.

Day 5 — Live coding and production debugging

• Solve two of the three coding practice problems (rolling failure rate, overlapping attempts, ordered merge) in plain Java, narrating assumptions and complexity.
• Write a production slowness runbook: latency percentiles, slow query log, connection pool, thread dump, GC, tracing, then bisect and verify.
• Attempt the third coding problem under a self-set limit and note where you stalled.
• Record your answer to the production debugging question using the runbook.

Deliverable: Two or three solved Java problems with complexity notes, a one-page debugging runbook and one recorded answer.

Day 6 — Angular, quality practice, containers and learning

• Write your answer on Angular with REST: typed services, an auth interceptor, token refresh, cross-origin setup and error states.
• Describe your testing and continuous integration setup: unit, slice and integration tests, what blocks a merge and how failures surface.
• Write how you containerize a Spring Boot service (image build, non-root user, configuration and secrets from the environment) and what Kubernetes adds: readiness and liveness probes, config and secrets, scaling.
• Prepare a real example of picking up an unfamiliar technology or domain, with the steps you took.

Deliverable: A written Angular integration answer, a quality and CI summary, a container and Kubernetes note, and one learning example.

Day 7 — Behavioral and HR rehearsal

• Outline stories for the insurance move, disagreement, shifting priorities, five-year direction and values questions, each with situation, action, result and lesson.
• Record all five answers aloud and cut any that run long or lack a personal action.
• Write your salary-range statement and your list of questions for the HR stage.

Deliverable: Five story outlines, five recordings, and a short HR-stage sheet.

Insurance move, disagreements, priorities and values

The behavioral questions candidates report cover your reasons for moving into insurance, a disagreement, shifting priorities in an agile cycle, your leadership direction, and how your values meet reliability, professionalism and customer trust. For a Java backend role, stories about production incidents, design disagreements and scope changes on a sprint all fit. Prepare stories where you made the decision, name the cost, and say what you learned.

1. What keeps you motivated, and how do you stay engaged with repetitive or maintenance-heavy work?

What is your experience with frontend frameworks like Angular, and how do you integrate them with backend REST

Medium · Technical and Architecture

What is your experience with frontend frameworks like Angular, and how do you integrate them with backend RESTful APIs?

Approach

1. Anchor the answer in one real Angular and REST project: say which screens needed which data, which endpoints served them and what you personally built. If your Angular experience is light, say so and go deeper on the Spring Boot contract side.
2. Client structure: a typed service layer around HttpClient with interfaces matching the response DTOs, an interceptor that attaches the bearer token and maps errors to one shape, and RxJS used deliberately (switchMap to cancel stale searches, the async pipe or takeUntilDestroyed to avoid leaked subscriptions).
3. Contract: agree resource names, status codes, pagination and validation-error format before building, and publish an OpenAPI spec so client types can be generated and drift fails the build instead of the browser.
4. Cross-origin and auth: explain the preflight request, configure allowed origins explicitly in Spring (never a wildcard when credentials are sent) or use a dev proxy locally, and state where the token lives and the XSS versus CSRF trade-off of that choice.
5. User-visible failure: loading, empty and error states, validation errors shown next to fields, retries only for idempotent GETs, and a defined behaviour on 401.

Follow-up

• How does your interceptor behave when an access token expires and several requests fail at once?
• Where do you store the token, and which attack does that choice leave open?
• How do you stop the frontend and backend from drifting apart when a response shape changes?

Why do you want to transition into the insurance domain, and what challenges do you anticipate?

Medium · Behavioral and Cultural Alignment

Approach

1. Lead with a reason tied to the work, not the industry's reputation: policy, claim and payment data that stays around for years makes correctness, auditability and safe migration matter. Link it to something you built with those properties, in any domain.
2. Show you have done homework. Use two or three domain terms correctly (policy, premium, claim, underwriting) and mention that candidates describe the role as including modernization of older policy-management systems, then say what attracts you to incremental migration work.
3. Name real challenges and your counter for each: unfamiliar rules and vocabulary (shadow a business analyst, trace one claim end to end), regulated change processes (learn the release and approval path early), thinly tested legacy code (write characterization tests before changing behaviour).
4. If you already work in insurance or finance, reframe from why the industry to why this company and scale, and do not criticise your current employer.
5. The answer that sinks: pay or stability as the only reason, or a vague appetite for change with no direction.

Follow-up

• What would you do in your first weeks to learn how a policy moves through the system?
• Which skills from your current domain transfer, and which will you have to unlearn?
• What would tell you this move was a mistake?

Can you describe a situation where you had a disagreement with a stakeholder or team member and how you resolv

Medium · Behavioral and Cultural Alignment

Can you describe a situation where you had a disagreement with a stakeholder or team member and how you resolved it?

Approach

1. Pick a disagreement about something that mattered, such as a technical direction or a deadline, with a peer or a non-technical stakeholder. Describe it in two sentences, then spend most of the time on how you handled it.
2. Show you understood the other position first: "I asked what they were optimizing for before arguing my side." Name their goal fairly, and where it was right.
3. Bring evidence instead of opinion: a benchmark, a spike, a risk list or a cost estimate, and lay out two or three options with trade-offs so the choice becomes about criteria.
4. State how it was decided (a time-boxed experiment, a call by the owner, or escalation to an architect after the evidence was shared), what the outcome was, and what the working relationship looked like afterwards.
5. The mistake that sinks it: a story where you were simply right, no resolution, or constant "we" so your own action is invisible.

Follow-up

• What if they still disagreed after seeing the evidence?
• Was there a time the other person turned out to be right?
• How did you explain the final decision to people who had argued against it?

How do you handle shifting priorities and tight deadlines in an agile development cycle?

Medium · Behavioral and Cultural Alignment

Approach

1. Choose a concrete case: a requirement changed mid-sprint, or a date moved forward. Say what was committed, what changed, and who decided.
2. Show triage rather than heroics: separate must-have from nice-to-have, make the trade-off visible to the product owner (swap scope, not silent overtime), and agree what moves out of the sprint.
3. Describe how you protected quality while moving fast: a thin vertical slice first, a feature flag so unfinished work can ship dark, tests and code review kept in place, and the debt you consciously took written down.
4. Report the result honestly: what shipped, what was deferred, whether defects followed, and how you updated the team on progress as things changed.
5. The mistake that sinks it: a story of long hours and no process, or one where quality was quietly dropped.

Follow-up

• What exactly did you drop, and who agreed to that?
• How do you respond when every item is declared top priority?
• What happened to the debt you took on, and when was it repaid?

Where do you see your technical leadership and career path heading over the next five years?

Medium · Behavioral and Cultural Alignment

Approach

1. Answer with a direction and the concrete steps toward it, not a job title. For example, moving from owning services to owning cross-team designs, with the habits that build that: writing design documents, reviewing code, mentoring.
2. Show you already do part of it today: a design you drove, a junior engineer you coached, a practice you introduced. Evidence beats ambition.
3. Tie it to the work candidates describe, such as enterprise Java, microservices and modernization of older systems, and say what you would want to own there.
4. Stay open on the individual-contributor versus management question, and say what you would test before choosing.
5. The mistake that sinks it: a title-chasing answer, or one that implies you are using the job as a short stop.

Follow-up

• What skill do you most need to build to get there?
• Tell me about a time you led a piece of work without formal authority.
• How would you support a junior engineer who keeps missing estimates?

How do your personal values align with Allianz's commitment to reliability, professionalism, and customer trus

Medium · Behavioral and Cultural Alignment

How do your personal values align with Allianz's commitment to reliability, professionalism, and customer trust?

Approach

1. The question names reliability, professionalism and customer trust as the company's commitments, as candidates report it. Choose one or two and prove them with an incident, not a definition.
2. Reliability: a production incident you owned, what you did during it, and the follow-up that made it less likely, such as an alert, a test or a rollback path.
3. Customer trust: a time you held a release for a defect in a calculation or protected personal data, and how you explained the delay to stakeholders. Insurance systems carry money and personal information, so say that this is why it matters to you.
4. Professionalism: how you communicate when things go wrong, such as a prompt update, a clear handover and documentation another engineer can use.
5. The mistake that sinks it: repeating the three words back with adjectives about yourself and no event behind them.

Follow-up

• When did you delay or refuse a release because of quality?
• Tell me about a mistake of yours that you reported before anyone noticed.
• How do you act when a deadline conflicts with these values?