Cegeka Software Engineer Interview Guide

The 60-second brief

Candidates describe Cegeka as a company that builds and runs technology for clients, with work reported across infrastructure, cloud services and custom applications. Projects are described as possibly involving large-scale data processing, integration with cloud platforms and enterprise applications. A Software Engineer there is described as designing, building and maintaining applications for client needs, from internal tools to applications that clients use directly, reviewing teammates' code, taking part in the whole delivery cycle from requirements to deployment, and troubleshooting running applications. The guide treats the role as engineering work that also involves talking to the people who own the requirements.

This guide is for candidates applying to Cegeka as a Software Engineer. It covers the three reported stages, the fifteen questions candidates report (languages and programming paradigms, the development lifecycle and Agile, high availability, architectural patterns, REST API design, troubleshooting, unclear requirements, behavioral stories, and basic coding such as reversing a linked list and binary search), and the topics candidates associate with the loop: Java, SQL, Domain-Driven Design, pair programming and problem solving.

Candidates report three stages over roughly 3-5 weeks: an HR Interview, a Technical Interview and Stakeholder Engagement. The reports describe the stages, not a published schedule, and do not say which question belongs to which stage.

Focus areas

• Java
• SQL
• Design Domain: DDD (Domain-Driven Design)

Overview

The work candidates describe is broader than writing code. Responsibilities reported for the role include code reviews, taking part in the whole delivery cycle from gathering requirements to deployment and maintenance, talking to stakeholders, and debugging running applications. That shape explains the reported question mix: alongside coding there are questions on the development lifecycle, Agile, architecture, troubleshooting and teamwork. Prepare to speak about a project end to end, not only about the code you wrote.

The stack candidates mention is mainstream enterprise tooling. Java, C# and Python appear as languages, with Spring and .NET as frameworks; Git and CI/CD pipelines, Agile and Scrum, and relational databases are listed as expected knowledge, and AWS, Azure, JIRA and Trello are listed as nice to have. Reported topics for the loop are Java, SQL, Domain-Driven Design, pair programming and problem solving. Pick one primary language and know it well enough to compare it with a second, refresh joins, aggregation, indexes and transactions in SQL, and learn the DDD vocabulary: entity, value object, aggregate, bounded context, repository and ubiquitous language, each with an example from a system you know.

The reported questions fall into six groups: your languages and the object-oriented versus functional difference; the development lifecycle and Agile; design (high availability and scalability, architectural patterns, designing a RESTful API); troubleshooting a slow web application and handling unclear requirements; behavioral stories (a challenging project, team conflict, advocating a technical decision, learning a technology quickly); and basic coding (reverse a linked list, implement binary search, explain the complexity of your solution). The coding items are standard exercises, so the preparation is accuracy under narration: edge cases, invariants and a complexity argument you can derive from your own loops. Since pair programming is among the reported topics, practise talking while you type.

The Cegeka interview process

Candidates describe three stages: HR Interview, Technical Interview and Stakeholder Engagement. Because the reports do not tie questions to stages, the preparation below is organised by what each stage covers and by question type.

HR Interview

Candidates describe an opening HR conversation about your motivation and background. It is the first place you explain who you are as an engineer, so go in with a short, specific account of your path, the languages you have used and why this kind of work interests you. The reported question about the languages you are most proficient in, and how you have used them, is a good rehearsal for this conversation even though the reports do not place it in a particular stage.

What to demonstrate

• Your motivation for the Software Engineer role and for Cegeka
• Background and experience relevant to the work, as you describe it
• How clearly you can summarise past projects and your part in them

How to prepare

• Write a short career narrative that names each language you have used professionally and one project where you used it.
• Prepare a reason for wanting this role that refers to the work candidates report: client projects across infrastructure, cloud services and custom applications.
• Decide which of Java, C# or Python is your strongest and be ready to say what you built with it, and where you used SQL.
• Write two or three questions about the team, the kind of projects and how engineers work with stakeholders.

Technical Interview

Candidates describe a Technical Interview covering coding skills, problem solving and understanding of software design principles. Reported topics for the loop include Java, SQL, Domain-Driven Design, pair programming and problem solving, but candidates do not say which topic lands in which stage, so treat coding, design and troubleshooting as all in play. Work on narrating while you code: state the approach, write it, test it on small inputs, then give the complexity.

What to demonstrate

• Coding skills: working code for standard exercises
• Problem solving: how you break a problem down and reason about it aloud
• Understanding of software design principles and architecture

How to prepare

• Write the reversal of a linked list iteratively and recursively, and binary search with a clear loop invariant, then test empty, single-element and duplicate cases.
• Practise stating time and space complexity for each solution, including the recursion stack.
• Outline a high-availability design, a RESTful API for a resource you know, and when you would use layered, event-driven or microservice styles.

Stakeholder Engagement

Stakeholder Engagement is described as meetings with various stakeholders, including team leads and possibly the business unit manager. The responsibilities candidates report for the role include gathering requirements and giving technical input to stakeholders, so expect to be judged on how you communicate as much as on code. Prepare to explain a technical choice in plain terms and to describe how you work with people who do not share your background.

What to demonstrate

• How you communicate with stakeholders, including non-engineers
• How you collaborate with a team and its leads
• Whether you can explain and defend a technical decision

How to prepare

• Prepare stories for team conflict, advocating a technical decision and starting a project with unclear requirements, each told in the first person.
• Practise explaining one design you built in three sentences for a business reader, then in more depth for an engineer.
• Prepare questions for a team lead and for a business manager about how requirements reach the team and how success is judged.
• Rehearse your answer on the development lifecycle and Agile with a real project and your role in it.

Where candidates lose points

Answering the object-oriented versus functional programming question with two definitions and no code

Contrast the two styles in your own language: mutable state in objects versus immutable data and pure functions, with a short example such as the same transformation written as a loop with a class and as a stream or LINQ pipeline. Say when each fits.

Writing a linked-list reversal or binary search that fails on empty, single-element or duplicate inputs

State the loop invariant before coding, keep a reference to the next node before relinking, compute the midpoint as lo + (hi - lo) / 2, and run empty, one-element and two-element cases by hand before saying it works.

Quoting a complexity figure without tying it to your code, or leaving out space

Derive time and space from your actual loops and recursion, including the call stack, and say how the answer would change for a different structure such as an array instead of a linked list.

Naming patterns and technologies in the design questions without trade-offs

Anchor high availability, scalability and REST API design in one concrete scenario and name what fails and how you recover. Use DDD terms only with an example, such as what your aggregate boundary protects.

Telling behavioral stories in the team's voice, or starting a project with unclear requirements by building straight away

Rewrite each story so your decisions are explicit, and describe a clarification step: list assumptions, ask stakeholders, agree a first small slice, then build.

Questions & practice

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Clarify the node type (singly linked, with a next field) and whether to reverse in place. Then state the plan: walk the list once and turn each next pointer around.
2. Iterative version with three references: prev = null and curr = head. Loop while curr != null: next = curr.next; curr.next = prev; prev = curr; curr = next. Return prev as the new head. This is O(n) time and O(1) extra space.
3. Recursive version: reverse the rest of the list, then set head.next.next = head and head.next = null, and return the new head from the base case. It is still O(n) time but uses O(n) stack. Java does not optimise tail calls, so a very long list can throw StackOverflowError, which is why I prefer the iterative version.
4. Walk through the edge cases out loud: an empty list (return null), a single node, and two nodes. Test by building a list in code and checking the values in order after reversal, and check that the old head's next is now null.
5. For a doubly linked list, swap each node's prev and next and return the last node visited.

Follow-up

• Reverse only the nodes between positions m and n in one pass.
• Reverse the list in groups of k nodes, leaving a final short group as it is.
• How would you check first whether the list contains a cycle?

How would you implement a binary search algorithm?

Medium · Coding / Algorithms

Approach

1. State the precondition first: the input must be sorted and support random access, such as an array or ArrayList. On a linked list, reaching the middle costs O(n), which removes the benefit.
2. Classic version on a closed range: lo = 0, hi = n - 1, loop while lo <= hi. Compute mid = lo + (hi - lo) / 2, or (lo + hi) >>> 1 in Java, because (lo + hi) / 2 overflows int for large arrays. If a[mid] equals the target, return mid. If it is smaller, set lo = mid + 1. Otherwise set hi = mid - 1. Return -1 if the loop ends.
3. For duplicates or insertion points, use the half-open lower-bound form: lo = 0, hi = n, loop while lo < hi; if a[mid] < target then lo = mid + 1, else hi = mid. It returns the first index whose value is >= target. Java's Arrays.binarySearch returns -(insertionPoint) - 1 when the key is missing and does not say which duplicate it finds.
4. Complexity: O(log n) comparisons, and O(1) space when iterative. Edge cases to test: an empty array, one element, a target below the minimum or above the maximum, and all elements equal.
5. Generalise it: binary search works on any monotonic predicate, for example finding the smallest capacity that ships all packages in D days by searching the range of possible answers.

Follow-up

• Return the first and last positions of a target in a sorted array with duplicates.
• Search for a target in a sorted array that has been rotated at an unknown pivot.
• Why does the loop condition change between the lo <= hi and lo < hi versions, and what bug does mixing them cause?

Can you explain the time complexity of your solution?

Medium · Coding / Algorithms

Approach

1. Define the variables before giving a bound: n is the list length, and m is a second input if there is one. Then count the dominant operation. A single pass is O(n), nested loops over the same input are O(n^2), and halving the search space each step is O(log n).
2. Always give time and extra space together. Iterative linked-list reversal is O(n) time and O(1) space, and the recursive version is O(n) space for the call stack. Iterative binary search is O(log n) time and O(1) space.
3. For recursion, write the recurrence and solve it. T(n) = 2T(n/2) + O(n) gives O(n log n), as in merge sort. T(n) = T(n/2) + O(1) gives O(log n), as in binary search. Naive recursive Fibonacci is exponential, and memoisation makes it O(n).
4. Say which case you mean: worst, average or amortised. ArrayList.add is amortised O(1) because the backing array grows by a constant factor (1.5x in OpenJDK), even though an individual add can copy everything. HashMap lookups are O(1) on average and degrade with heavy collisions.
5. Call out hidden costs in library calls: list.contains inside a loop is O(n*m), and repeated String concatenation in a Java loop copies the string every time, giving O(n^2) characters in total, while StringBuilder keeps it linear.

Follow-up

• You sort n items once and then answer k lookups with binary search: what is the total cost, and when does a HashSet do better?
• Why is ArrayList.add amortised O(1) when some calls copy the whole array?
• Can you do better than O(n log n) for this problem, and what lower bound applies to comparison sorting?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

What programming languages are you most proficient in, and how have you applied them in your previous projects

Medium · Technical / Domain Questions

What programming languages are you most proficient in, and how have you applied them in your previous projects?

Approach

1. Lead with one primary language and one secondary, not a list of ten. The requirements candidates describe for this role name Java, C# or Python, with Spring or .NET, so if one of those is yours, say so first and rank your depth honestly.
2. For each language, give one project in a fixed shape: what I built, its size or load, and one decision that depended on the language, such as choosing Spring's declarative transactions or using async/await in a .NET service to avoid blocking threads on I/O.
3. Show depth beyond syntax: the runtime and memory model (JVM or CLR garbage collection and what a long GC pause did to latency), the concurrency tools you used (ExecutorService, CompletableFuture, Task), and the build and test tooling (Maven or Gradle, JUnit, xUnit).
4. Know one sharp difference between the languages you name, for example that Java generics are erased at runtime (no new T(), no instanceof List<String>) while C# generics are reified.
5. Close with what you would pick for a new service and why. A language choice tied to team skills, libraries and deployment target is stronger than one based on preference.

Follow-up

• What does type erasure in Java stop you from doing, and how did you work around it?
• Describe a bug you hit that was specific to that language or its runtime.
• If the team used a language you know less well, how would you get productive in it?

Can you explain the difference between object-oriented and functional programming?

Medium · Technical / Domain Questions

Approach

1. Define both by how they handle state. Object-oriented code bundles mutable state with the methods that change it and relies on encapsulation and polymorphism through dynamic dispatch. Functional code treats functions as values, prefers pure functions over immutable data, and builds behaviour by composing them.
2. Use the expression problem to frame the trade-off. With OOP, adding a new type is easy (one new subclass) but adding a new operation means touching every class. With algebraic data types and pattern matching it is the other way round.
3. Show that modern Java and C# mix both styles: Java has lambdas and the Stream API (map, filter, reduce), records, sealed interfaces and pattern matching for switch (final in Java 21), and C# has LINQ and records. Write a short loop and the same logic as a stream.
4. Give the practical consequences. Immutable data is safe to share between threads without locks and easier to unit test. The costs are extra allocation and copying, and side effects such as I/O and database writes still have to live somewhere, usually at the edges (functional core, imperative shell).

Follow-up

• How would you make a Java class properly immutable, including a field that holds a List?
• Is a stream pipeline that mutates an external collection inside forEach still functional? What can go wrong if it runs in parallel?
• When would you choose a class hierarchy over a sealed type with pattern matching?

How would you design an application for high availability and scalability?

Medium · System Design / Architecture

Approach

1. Pin the requirements before drawing anything: an availability target (99.9% allows about 8.8 hours of downtime a year), peak traffic and read/write ratio, data size, and how much data loss and recovery time (RPO and RTO) are acceptable.
2. Make the application tier stateless so any instance can serve any request. Keep sessions in a shared store or a signed token, put instances behind a load balancer with health checks across at least two availability zones, and autoscale on CPU or request rate.
3. Scale the data tier in order of cost. Add indexes and a cache with a TTL first, then read replicas (stale reads because of replication lag), then a primary with automatic failover to a standby. Shard only when one primary can no longer take the writes, and name the shard key and the queries it makes expensive.
4. Plan for failure explicitly: timeouts on every remote call, retries with exponential backoff and jitter, circuit breakers, idempotency keys so a retry cannot double-apply, and a queue to absorb spikes for work that can run asynchronously.
5. Finish with operations: metrics and alerts on latency percentiles and error rate, rolling or blue-green deploys, and backups that are actually test-restored. Then name the single point of failure that is left.

Follow-up

• With asynchronous replication, what happens to writes the primary accepted just before it failed?
• How do you stop client retries turning a partial outage into a full one?
• Traffic grows tenfold overnight: which component fails first, and how would you know?

What architectural patterns are you familiar with, and when would you use them?

Medium · System Design / Architecture

Approach

1. Name four or five patterns and say when each one fits, rather than listing definitions. Good candidates are layered (n-tier), hexagonal (ports and adapters), modular monolith versus microservices, event-driven messaging, and CQRS.
2. Hexagonal: keep the domain free of framework and database code and reach it through ports, with adapters for HTTP, persistence and messaging. The benefit is domain logic you can unit test without Spring or a database. The cost is more interfaces and mapping code.
3. Microservices give each team independent deployment and scaling, at the cost of network calls, no cross-service transactions (use sagas plus the transactional outbox), and harder tracing. A modular monolith with enforced module boundaries is usually the right default for a small team.
4. CQRS separates the write model from read models when their shapes differ a lot, at the cost of eventual consistency. Event sourcing adds a full audit trail and replay, but event schema changes and snapshotting become ongoing work. Do not reach for either by default.
5. Candidates list DDD among the topics, so link the patterns to it. A bounded context marks a natural module or service boundary, an aggregate is the consistency boundary changed in one transaction, and domain events connect contexts.

Follow-up

• You are splitting a monolith: where do you draw the first boundary, and why there?
• How do you keep two services consistent without a distributed transaction?
• What is an aggregate in DDD, and what goes wrong when you make one too large?

Can you walk me through how you would approach designing a RESTful API?

Medium · System Design / Architecture

Approach

1. Start from the consumers and the domain. Model resources as nouns (/orders, /orders/{id}/items), keep nesting shallow, and write the contract first in OpenAPI so client and server teams can work in parallel.
2. Use HTTP semantics correctly. GET is safe and idempotent, PUT replaces the whole resource and is idempotent, PATCH updates part of it, DELETE is idempotent, and POST creates and is not idempotent. Return 201 with a Location header on create and 204 when there is no body.
3. Design errors as carefully as successes: 400 for malformed input, 422 for failed validation, 401 versus 403, 404, 409 for a state conflict, 429 for rate limiting. Use one error body format, such as application/problem+json (RFC 9457).
4. Handle the hard cases explicitly. Accept an Idempotency-Key header on POST so a retried create cannot double-apply. Use ETag with If-Match for optimistic concurrency (412 on a stale write). Prefer cursor pagination over offset for lists that change while a client pages through them.
5. Cover evolution and security. Make additive changes freely and version (/v1 or a header) only for breaking changes. Use OAuth2 bearer tokens over TLS, validate input, and apply rate limits per client.

Follow-up

• A client times out on a POST and retries: how do you make sure only one order exists?
• How would you rename a field that existing clients already depend on?
• Two users edit the same resource at once: how does your API stop a lost update?

If you were given a project with unclear requirements, how would you proceed?

Medium · Problem-Solving / Case Studies

Approach

1. Find the problem behind the request before the features. Ask who uses the result, what they do today, and how success will be measured. Separate the people who decide from the people who are affected.
2. Write down assumptions and open questions in a short shared document, have the product owner confirm or correct them, and record the answers. This turns an unclear request into something both sides can check.
3. Turn what you learn into user stories with acceptance criteria (Given/When/Then), then rank them, for example with MoSCoW. Build the must-haves first as a thin end-to-end slice that can be demoed early.
4. Learn the domain's own vocabulary. DDD's ubiquitous language or an event-storming session brings out the business events and rules that nobody wrote down. Use those words in the code and the API so later misunderstandings are visible.
5. Keep decisions in uncertain areas reversible: put integrations behind interfaces and avoid committing to a data model for parts still in question. Review the result with stakeholders at the end of each sprint so new requirements show up as feedback, not as rework at the end.

Follow-up

• Two stakeholders give you contradictory requirements: what do you do?
• How do you decide you know enough to start building?
• A requirement changes after you have built it: how do you handle the cost and the conversation?

How would you troubleshoot a performance issue in a web application?

Medium · Problem-Solving / Case Studies

Approach

1. Make the symptom precise first: which endpoint or page, which percentile (p50, p95 or p99), since when, and for all users or a subset. Then check what changed at that time: a deploy, a config change, data growth or a traffic shift.
2. Split client from server. In browser devtools, compare time to first byte with download and render time. A long TTFB points to the server. A fast TTFB with a slow page points to bundle size, render-blocking scripts or too many requests.
3. On the server, use traces or per-span timing to see where the time goes: database, external calls, CPU or waiting. Typical causes are N+1 queries from ORM lazy loading (JPA/Hibernate), a missing index (check with EXPLAIN ANALYZE), an exhausted connection pool or thread pool, lock contention, and long GC pauses (read the GC logs).
4. Reproduce it under a load test that resembles production, change one thing at a time, and compare the same percentile before and after. Typical fixes are a join fetch or batch fetching, an index, a cache, a timeout on a slow dependency, or a bigger pool, but only if the database can take the extra connections.
5. Close the loop with an alert on the percentile that regressed and, if the cause was a query, a test or check that catches it in CI.

Follow-up

• p99 latency doubled while p50 stayed flat: where do you look first?
• How do you detect an N+1 query in a JPA application, and what are two ways to fix it?
• The slow query runs fast when you execute it by hand: what could explain the difference?

Suggested practice checklist

The plan follows the three reported stages and the reported topics: Java, SQL, DDD, coding, design and behavioral stories. Each day ends with something you can check.

Day 1 — Map the loop and inventory your experience

• Write the three reported stages and, beside each, what you must be able to say or show.
• List the fifteen reported questions grouped by type and mark the five you are least ready for.
• Make an inventory of four projects with the languages, your role and the outcome of each.

Deliverable: A one-page loop map, a grouped question list with weak spots marked, and a four-project inventory.

Day 2 — Java and programming paradigms

• Write the same small transformation twice in your strongest language, once object-oriented and once in a functional style, and note where each is clearer.
• Outline Java core topics you could be asked about: collections, equals and hashCode, generics, streams and concurrency basics.
• Answer aloud the question on languages you are proficient in and the object-oriented versus functional question.

Deliverable: Two code versions, a one-page Java topic outline and recorded spoken answers to both questions.

Day 3 — SQL refresh

• Review joins, grouping and aggregation, indexes and transaction basics.
• Write a one-page cheat sheet of query patterns you tend to forget.

Deliverable: Two worked SQL solutions and a one-page cheat sheet.

Day 4 — Coding fundamentals with narration

• Write linked-list reversal iteratively and recursively, and test empty, single and long lists.
• Write binary search with a stated invariant and test duplicates and missing targets.
• State the time and space complexity of each solution aloud while you work, as in a pair programming session.

Deliverable: Working, tested code for both exercises and a written complexity summary for each.

Day 5 — Design principles, patterns and DDD

• Outline an application designed for high availability and scalability: redundancy, stateless services, data layer and failure handling.
• Design a RESTful API for a resource you know: URIs, methods, status codes, versioning and idempotent retries.
• Write short notes on three architectural patterns and when you would pick each, and map a domain you know to DDD terms.

Deliverable: A design outline, an API sketch with error cases and a pattern-and-DDD cheat sheet.

Day 6 — Troubleshooting, requirements and the lifecycle

• Write a checklist for a slow web application: reproduce, measure, find the slow layer, check queries and caching, then fix and verify.
• Write the steps you take on a project with unclear requirements: assumptions, questions, a first small slice.
• Rehearse the answer on the development lifecycle and your Agile experience using one real project.

Deliverable: A troubleshooting checklist, a requirements-clarification outline and one spoken lifecycle answer.

Day 7 — Behavioral and stakeholder rehearsal

• Write four stories (challenging project, team conflict, advocating a decision, learning a technology fast) in first-person bullet form.
• Rehearse each aloud and cut anything that does not show your own decision.
• Prepare questions for a team lead and a business unit manager, then run a full mock covering all three stages.

Deliverable: Four rehearsed stories and a list of questions for the final stage.

Stories for the HR and stakeholder stages

The reported behavioral questions ask for your Agile and lifecycle experience, a challenging project, team conflict, advocating a technical decision and learning a technology quickly. The third stage is described as meetings with team leads and possibly a business unit manager, so prepare stories that show how you work with people as well as code. Tell each story in the first person with a clear role, a decision and a result.

1. If you were given a project with unclear requirements, how would you proceed?

Describe the software development lifecycle and your experience with Agile methodologies.

Medium · Technical / Domain Questions

Approach

1. Anchor the answer in one real project and walk it in order: requirements, design, implementation with code review, testing, release and maintenance. Say what you personally did at each step instead of reciting a textbook cycle.
2. Map your Agile experience to concrete practices: how the backlog was refined, what sprint planning produced, how daily stand-ups worked and what the review and retrospective changed. Name the framework you really used (Scrum, Kanban or a mix) and the tool, such as JIRA or Trello, if that is true.
3. Include one change that came out of a retrospective and what it improved, because a specific adjustment shows you used the process rather than attended it.
4. Be honest about where the process bent: a scope change mid-sprint, a hotfix that skipped the normal flow or a definition of done you tightened, and how you handled it.
5. The mistake that sinks this answer is a glossary: defining waterfall and Scrum with no project, role or outcome attached.

Follow-up

• How did your team decide that a story was done?
• What did you do when requirements changed in the middle of a sprint?
• Where did Agile work badly on that project, and what did you adjust?

Describe a challenging project you worked on. What was your role, and what challenges did you face?

Medium · Behavioral / Leadership

Approach

1. Choose a project where the difficulty was specific: a hard integration, a performance problem, an unfamiliar legacy codebase or a deadline with moving requirements. Give the situation in two sentences and say who it was for.
2. State your role as decisions and ownership: what you designed, built, reviewed or unblocked. Use I for your own choices and name teammates for theirs, so the listener can tell your contribution.
3. Split the challenges into technical and people problems, then take the biggest one and show the options you weighed, the one you chose and why.
4. Close with the outcome and something checkable, such as a release made, an error rate reduced or a process adopted, using only figures you can defend, and finish with what you would change.
5. The mistake that sinks it is a project whose only hardship was a large amount of work, or a story told entirely as the team's with no visible personal contribution.

Follow-up

• Which decision on that project would you reverse today?
• What was the hardest setback, and how did you handle it?
• How did you know the project had succeeded?

How do you handle conflicts within a team?

Medium · Behavioral / Leadership

Approach

1. Pick a real disagreement with substance, such as an API shape, review feedback, a priority call or an estimate, rather than a personality clash where the other person is plainly wrong.
2. Show the order of your actions: you first understood the other person's reasoning and restated it to check, then moved the discussion from opinions to something checkable like a benchmark, a small spike, a requirement or the effect on users.
3. Say how it was settled, whether by compromise, by adopting one view or by a team lead choosing after you set out the options, and what you gave up.
4. End with the working relationship afterwards and one habit you changed, for example writing decisions down or agreeing review conventions.
5. The mistake that sinks it is claiming you have never had a conflict, or telling a story where you win and the other person looks foolish.

Follow-up

• What would you have done if the other person had not agreed?
• When is it right to bring in a team lead?
• Tell me about a conflict where you turned out to be wrong.

Give an example of a time when you had to advocate for a technical decision.

Medium · Behavioral / Leadership

Approach

1. Pick a decision with real alternatives and a cost, such as a framework or library choice, a schema design, an API versioning approach, a refactor versus feature work, or adding a check to the CI pipeline.
2. Lay out the options, your criteria and the evidence you gathered: a prototype, a load test, incident history or a maintenance estimate. A decision backed by evidence reads as judgement, not preference.
3. Say who you needed to convince and how you adapted. Engineers want trade-offs and risks; a business stakeholder wants the effect on delivery, cost and risk in plain words, which matters for the stakeholder stage.
4. Give the outcome honestly, including a case where you were overruled and committed to the chosen path, or where you changed your mind after new evidence.
5. The mistake that sinks it is a story where advocating meant repeating your preference more firmly until others gave in.

Follow-up

• How would you explain that decision to a non-technical stakeholder?
• What would you have done if the team had still said no?
• Looking back, was the decision right?

Describe a time when you had to learn a new technology quickly to complete a project.

Medium · Problem-Solving / Case Studies

Approach

1. Set the stakes: what the project needed, the deadline and what you did not know. A new language, framework or cloud service, for example moving between Java, C# or Python, or onto Spring, .NET, AWS or Azure, makes a natural example if it is true for you.
2. Show how you triaged: you identified the smallest slice needed to deliver, read the official documentation for that slice, built a small spike and asked a colleague who knew it, instead of trying to learn everything.
3. Describe how you checked your understanding: tests you wrote, a review from someone experienced, and comparison with existing code in the repository.
4. State the result: what shipped, what remained shaky and what you studied afterwards.
5. The mistake that sinks it is an answer that stops at watching tutorials with nothing shipped, or one that implies you mastered the technology in a few days.

Follow-up

• How did you know you had learned enough to ship?
• What did you get wrong at first?
• How would you handle it if nobody on the team knew the technology?