Adecco General Staffing Software Engineer Interview Guide

The 60-second brief

Candidates describe the Software Engineer role at Adecco General Staffing as building and maintaining software used both inside the business and by its customers: internal systems on one side, customer-facing applications on the other. The daily work they describe is coding, testing and debugging, gathering requirements with people from other functions, documenting what you build and taking part in code reviews, and some positions add mentoring junior developers. The technologies that appear in reports are Java, Spring Boot and Python, together with Jira and its query language, JQL. The requirements candidates cite ask for Java, Python or JavaScript, experience working within a development methodology, and a working knowledge of database management systems.

This guide is for software engineers preparing for the Adecco General Staffing Software Engineer loop, most likely with a Java or Python background. It covers the four reported stages and how to approach each one. It gives question-specific answers to all 15 reported questions: coding fundamentals, conceptual questions on OOP, code quality and Git, scenario questions on performance, debugging and changing requirements, and behavioral stories. It also covers the parts of the reported stack worth refreshing (Spring Boot, databases, Jira and JQL) and a seven-day plan that ends in working code and rehearsed answers.

Candidates report four stages over roughly 3-5 weeks: an initial screening call, one or more technical interviews, behavioral interviews, and discussions with hiring managers. Coding is reported as either a live session or a take-home assignment.

Focus areas

• Java
• Jira
• Jira Query Language (JQL)

Overview

The reported work is general application engineering. You design, build and maintain software that runs inside the business and in front of its customers, and candidates describe coding, testing, debugging, documentation and code review as all part of the job. Requirements are gathered with people outside engineering, and some positions include mentoring junior developers. The reported questions follow from that mix. Few of them are algorithm puzzles, and most ask how you build, review, ship and fix software alongside other people.

The 15 reported questions fall into four groups. Five are technical conversation questions: a hard problem you solved, the languages you know and their strengths, object-oriented programming, code quality and Git. Three are scenario questions: speeding up a slow application, debugging under a tight deadline, and a requirement that changes midway. Three are coding fundamentals: reverse a string, find two numbers that sum to a target, and implement a sort. Four are behavioral: a difficult teammate, a project you took charge of, prioritising across several projects, and handling feedback. Candidates report that the coding portion can be a live session or a take-home assignment.

Reports mention five technologies: Java, Spring Boot, Python, Jira and Jira Query Language (JQL). The requirements candidates describe ask for Java, Python or JavaScript, a development methodology you have worked in, and database knowledge. AWS or Azure, agile practice and React or Angular are listed as nice-to-haves. In practice, answer the conceptual questions from Java and Spring Boot code you can actually describe: interfaces, dependency injection, JPA queries and JUnit tests. Be able to solve the coding questions in Java or Python, and know enough JQL to filter a backlog by status, assignee and sprint.

The coding questions are fundamentals, so a strong answer is a finished one. Handle duplicates, empty input and null, state the time and space complexity, and explain why you picked a hash map or merge sort. The scenario questions work the same way. A sequence you can defend (measure, isolate, fix, verify) is a stronger answer than a list of tuning tricks, and a behavioral story needs a first-person action and a result you can state in numbers.

The Adecco General Staffing interview process

Candidates describe four stages, from a screening call through technical and behavioral interviews to conversations with hiring managers, over about 3-5 weeks. The descriptions below come from candidate reports, not from a published process.

Initial Screening Call

Candidates describe the first stage as a preliminary call about your background and your fit for the role. No coding is reported for it, so treat it as a conversation in which your history should line up with the requirements candidates cite: Java, Python or JavaScript, a development methodology you have worked in, and database experience. Prepare one sentence per recent role naming the language, the framework (Spring Boot if you have used it) and one thing you shipped. Use the call to ask what the technical stage looks like, because candidates report that coding can come either as a live session or as a take-home. If you can, also confirm which language you may use.

What to demonstrate

• Whether your background matches the role as candidates describe it (Java, Python or JavaScript, plus database work)
• Fit for the role, which is what candidates report the call covers

How to prepare

• Write a short walkthrough of your last two roles. For each one, name the language, the framework and a result you can state with a number.
• Write an honest proficiency ranking of Java, Python and JavaScript, with one project behind each language you claim.
• Prepare questions about the technical stage: live or take-home, which languages are allowed, and how many technical interviews to expect.

Technical Interviews

Candidates report one or more technical interviews on coding skills, problem-solving and domain knowledge. Coding work is reported as either live coding or a take-home assignment. The reported coding questions are fundamentals (string reversal, two numbers summing to a target, a basic sort). The technical and scenario questions are conversational: OOP, code quality, Git, a slow application, debugging under deadline pressure. These are the question types to have ready for this stage. For coding, restate the problem, name the brute-force solution, write working code, then walk through edge cases out loud and state the complexity. For conceptual questions, anchor every answer in Java or Python code you have written, not in textbook definitions.

What to demonstrate

• Working code, written live or delivered as a take-home
• Problem-solving: how you structure an approach and explain your reasoning
• Domain knowledge of software development principles

How to prepare

• Solve the two-sum, string-reversal and sorting questions in Java and in Python with edge-case tests, until you can write each one cleanly without notes.
• Build a small Spring Boot REST service with one entity, a Spring Data repository and a JUnit test. This lets you discuss dependency injection, layering and testing from your own code.
• Rehearse the OOP, code-quality and Git answers with a Java example each, and the slow-application answer as a measure, profile, fix, verify sequence.
• For a take-home, plan the README, the test suite and the run instructions before you start, so the submission is easy to review.

Behavioral Interviews

Candidates describe behavioral interviews that focus on teamwork, communication and cultural alignment. The behavioral questions candidates report cover a difficult teammate, a project you took charge of, prioritising across several projects, and handling feedback or criticism. The scenario questions about changing requirements and debugging under pressure are also best answered with real stories, so rehearse those for this stage too. Build each answer as a STAR story. Keep the situation short, tell the action in the first person, give a result you can measure, and end with what you would do differently.

What to demonstrate

• Teamwork and communication, as candidates report
• Cultural alignment, as candidates report
• Whether your stories show your own actions and a concrete outcome

How to prepare

• Write a story bank of five or six first-person stories, one per reported behavioral question plus a requirement-change story and a debugging story, each with a measurable result.
• For the difficult-teammate and feedback stories, write down what you changed in your own behaviour, not only what the other person did.
• Rehearse each story out loud and cut any situation-setting that does not affect the decision you made.

Discussions with Hiring Managers

Candidates describe conversations with hiring managers about overall compatibility with the team and the organisation. Nothing more specific is reported, so prepare two things. The first is a project narrative a manager can follow: what you owned, the trade-off you made, and the result. The second is your own set of questions about the team. Ask which stack the team runs (Java and Spring Boot, Python, a front-end framework such as React or Angular), how work is tracked in Jira, and what remote arrangements look like. Candidates report that remote arrangements vary by team and project.

What to demonstrate

• Overall compatibility with the team and organisation, as candidates describe it
• How clearly you explain your past projects and your own part in them

How to prepare

• Prepare two project narratives. In each, name the decision you owned, the alternative you rejected and the measured outcome.
• Write questions about the team's services, its Java and Python split, how tickets move through Jira, and what a new engineer works on first.
• Confirm remote or on-site expectations here, since candidates report that they depend on team and project.

Where candidates lose points

Writing the hash-map solution to two sum without checking for duplicates, which can reuse the same element or fail on [3, 3]

Before coding, ask whether to return indices or values and whether duplicates appear. Look up the complement before inserting the current value, then run [3, 3] with target 6, an empty list and a no-solution case out loud before you say you are done.

Answering the OOP or code-quality question with textbook definitions and no code

Bring one Java example you can sketch quickly: an interface with two implementations injected into a Spring service, plus the JUnit test that mocks it. Tie every pillar or practice to that example, and name a real defect a test or review caught.

Proposing fixes for the slow-application question before measuring anything

Open with how you would find the slowness: which endpoint and percentile, then traces, a profiler and the SQL log. Name N+1 JPA queries and missing indexes as things you would check, and finish with a before-and-after measurement.

Listing Java, Spring Boot, Python or Jira on your CV but being unable to go one level deeper

For each technology in the reported topics, prepare one concrete detail: how Spring wires a @Service into a @RestController, a JPA query you tuned, the GIL in Python, and a JQL filter such as project = X AND sprint in openSprints() AND status != Done.

Using one story for every behavioral question, or telling stories with no first-person action and no result

Build a story bank with a separate story for the difficult teammate, the project you led, prioritisation and feedback. Say 'I' for your actions and end each story with a number or a concrete change.

Questions & practice

Write a function to reverse a string in your preferred programming language.

Medium · Coding / Algorithms

Approach

1. Clarify the input: can it be null or empty, is it ASCII or full Unicode, and should the result be a new string or an in-place reversal of a char array?
2. Java: new StringBuilder(s).reverse().toString() is idiomatic and treats surrogate pairs as single units. Python: s[::-1]. Both run in O(n) time with O(n) space, because strings are immutable.
3. Show the manual version too: convert to a char array, swap with two pointers (i from the start, j from the end) while i < j, then build the string. That is O(n) time with O(1) extra space beyond the array.
4. Edge cases: null (return null or throw, and say which), the empty string, a single character, and Unicode. A naive char swap breaks surrogate pairs such as emoji, and no code-unit reversal handles combining characters (grapheme clusters).
5. Avoid recursion for long inputs: it uses O(n) stack depth and can overflow.

Follow-up

• Reverse the order of words in a sentence, not the characters.
• Check whether a string is a palindrome, ignoring case and non-alphanumeric characters.
• How would you handle emoji and accented characters correctly?

Given a list of integers, find the two numbers that add up to a specific target.

Medium · Coding / Algorithms

Approach

1. Clarify: return indices or values? Is exactly one answer guaranteed? Can there be negatives or duplicates? May the same element be used twice (no)? What should happen if no pair exists?
2. Brute force: check every pair in O(n^2) time and O(1) space. State it, then improve on it.
3. Optimal: one pass with a hash map from value to index. For each x, look up target - x. If present, return both indices; otherwise insert x. This is O(n) time and O(n) space, and checking before inserting handles [3, 3] with target 6 without reusing an element.
4. Alternative: sort (value, index) pairs and use two pointers from both ends, giving O(n log n) time. It is the right choice if the input is already sorted, where it needs O(1) extra space.
5. In Java, use HashMap<Integer, Integer>. Note that target - x can overflow int at the extremes (use long if the range allows it), and test the empty array, no solution and negative numbers.

Follow-up

• The array is sorted. Can you do it in O(1) extra space?
• Return all unique pairs that sum to the target.
• Extend it to three numbers summing to the target (3Sum) and give the complexity.

How would you implement a basic sorting algorithm?

Medium · Coding / Algorithms

Approach

1. Name the options by their deciding properties. Insertion sort: O(n^2), stable, in place, fast on small or nearly sorted input. Merge sort: O(n log n) guaranteed, stable, O(n) extra space. Quicksort: O(n log n) on average, O(n^2) worst case with bad pivots, in place, not stable. Heap sort: O(n log n), in place, not stable.
2. Implement one cleanly. Merge sort is safest to write live: split recursively, then merge two sorted halves with two indices, taking from the left on ties to keep it stable.
3. If you write quicksort, use a random or median-of-three pivot to avoid the sorted-input worst case, and explain the partition scheme you chose (Lomuto or Hoare).
4. Connect it to real libraries. Java's Arrays.sort uses dual-pivot quicksort for primitives and TimSort (stable) for objects, and Python's sorted is TimSort-based and stable.
5. Test the empty array, one element, duplicates, already sorted and reverse sorted input.

Follow-up

• What does stability mean, and when does it matter?
• How would you sort data too large to fit in memory?
• When can you beat O(n log n), for example with counting sort or radix sort?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

• The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
• How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

• A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
• Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Describe a challenging technical problem you encountered and how you solved it.

Medium · Technical / Domain Questions

Approach

1. Pick a problem with a real constraint (a production defect, a performance limit, a data inconsistency) where you did the diagnosis yourself. Open with the symptom and why it mattered, in one or two sentences.
2. Walk through the investigation in order: what you measured or reproduced first, which hypothesis it ruled out, and what finally pointed at the cause.
3. Name at least two fixes you considered and why you chose one, for example a schema change over an application-side workaround, with the cost of each.
4. Close with evidence: the metric before and after, the test you added so it cannot regress, and one thing you would do differently.
5. Avoid a story told entirely in the plural. Say 'I' for your own actions so your part is clear.

Follow-up

• Which alternative did you reject, and would it have worked?
• How did you confirm the fix addressed the root cause rather than the symptom?
• What would you do with another week on that problem?

What programming languages are you proficient in, and what are their main advantages?

Medium · Technical / Domain Questions

Approach

1. Rank your languages honestly and back each claim with a project. The requirements candidates cite name Java, Python or JavaScript, so cover whichever of those you know.
2. Java: static typing that catches errors at compile time, the JVM's JIT and garbage collector, mature concurrency in java.util.concurrent, and the Spring Boot ecosystem for services. The costs are verbosity and slower iteration.
3. Python: fast to write and read, a large library ecosystem, good for scripts, data work and services. The costs are dynamic typing (offset by type hints and mypy) and the GIL, which limits CPU-bound threading, so use multiprocessing or native extensions for that.
4. JavaScript: the language of the browser and of Node.js, with an event-loop model suited to I/O-heavy work. TypeScript adds static types on top.
5. Finish with when you would pick each one, for example Java and Spring Boot for a long-lived transactional service and Python for tooling and data scripts.

Follow-up

• When would you build a backend service in Python instead of Java?
• What is the GIL, and when does it matter?
• What is the difference between checked and unchecked exceptions in Java?

Explain the concept of object-oriented programming and its benefits.

Medium · Technical / Domain Questions

Approach

1. Define the four pillars with code, not slogans. Encapsulation means private fields behind methods that protect invariants. Abstraction means callers depend on an interface, not on internals. Inheritance shares behaviour through subclasses. Polymorphism means one call resolves to different implementations.
2. Use one Java example throughout: a NotificationSender interface with EmailSender and SmsSender implementations, injected into a service. The service calls send() without knowing which class it holds.
3. Name the benefits concretely: code that is easier to change in one place, implementations you can swap (and mock in unit tests), and reuse through composition.
4. Show judgement about the costs. Deep inheritance hierarchies are brittle (the fragile base class problem), so prefer composition over inheritance and keep interfaces small.
5. Separate compile-time polymorphism (overloading) from runtime polymorphism (overriding with dynamic dispatch).

Follow-up

• When would you use an abstract class instead of an interface in Java, given default methods since Java 8?
• Give an example where composition is better than inheritance.
• How does Spring's dependency injection relate to the dependency inversion principle?

How do you ensure code quality and maintainability in your projects?

Medium · Technical / Domain Questions

Approach

1. Answer in layers, each tied to something you have done. Before code: clear acceptance criteria on the ticket. While coding: small functions, clear names, consistent formatting. Before merge: code review and automated tests. After merge: CI and monitoring.
2. Testing: JUnit 5 and Mockito or pytest for unit tests, integration tests against a real database for persistence code (Spring's @DataJpaTest or Testcontainers), and a regression test for every bug you fix.
3. Automation: CI runs the build, tests and a linter or static analysis on every pull request, so review time goes to design questions instead of style.
4. Maintainability: small pull requests, documentation for non-obvious decisions, and refactoring as you touch code. The role description candidates cite lists documentation and code reviews as part of the job.
5. Give one concrete case where a review or a test caught a defect before release.

Follow-up

• What coverage target do you use, and how can coverage be misleading?
• How do you handle a pull request when you disagree with the author's design?
• How would you add tests to a legacy module that has none?

What experience do you have with version control systems like Git?

Medium · Technical / Domain Questions

Approach

1. Describe the workflow you have used: feature branches off main or trunk-based development, pull requests with required review, and protected main branches. Include branch names and commit messages that carry the Jira issue key so tickets and commits link up.
2. Merge vs rebase: rebase gives a linear history but rewrites commits, so only rebase local or private branches. Merge preserves history and is safe on shared branches.
3. Recovery commands: git revert to undo a pushed commit safely, git reset only on unpushed work, git reflog to find lost commits, and git cherry-pick to move a hotfix onto a release branch.
4. Debugging with Git: git bisect binary-searches the commit range to find the commit that introduced a regression, in O(log n) test runs.
5. Mention a merge conflict you resolved and how you checked the result (rebuild plus tests), not just that you resolved it.

Follow-up

• A bad commit is already on the shared main branch. How do you undo it?
• When would you squash commits, and what do you lose?
• How does git bisect work, and how can you automate it with a test script?

How would you approach optimizing an application that is running slowly?

Medium · Problem-Solving / Case Studies

Approach

1. Define 'slow' first: which page or endpoint, which percentile (p50 or p95), since when, and for all users or some. A recent change points to a deploy or to data growth.
2. Measure before changing anything. Use APM traces or request logs to find where time goes (database, external calls, CPU, garbage collection), a JVM profiler such as Java Flight Recorder or async-profiler, or cProfile for Python.
3. Database checks come first in a typical Spring Boot app: enable SQL logging to spot N+1 queries from lazy JPA relations (fix with a fetch join, @EntityGraph or batch fetching), run EXPLAIN ANALYZE on slow queries, and add missing indexes.
4. Then work on the code and infrastructure: replace O(n^2) loops with a map lookup, cache read-heavy data with a clear invalidation rule, check connection-pool size and GC pauses, and reduce payload size.
5. Verify the change with the same before-and-after measurement and add a guard (a performance test or alert) so the slowdown does not return.

Follow-up

• How would you detect an N+1 query problem in a Spring Data JPA service?
• When is adding a cache the wrong fix?
• Your change improved median latency but made p99 worse. What happened?

If a project requirement changes midway, how would you adapt?

Medium · Problem-Solving / Case Studies

Approach

1. Start by clarifying the change: what exactly is new, why it changed, and whether the deadline moves with it. Record the answer on the ticket so the decision is traceable.
2. Assess the impact concretely: which code, tests and data are affected, what already built can be reused, and how the estimate changes.
3. Offer options instead of a flat yes or no: absorb it and move the date, cut other scope, or ship in phases with the change in a follow-up. Let the person who owns the requirement choose.
4. Describe how you design to absorb change: small increments, interfaces around volatile parts, and feature flags. These fit the agile practice listed among the nice-to-haves.
5. Ground it in a real example with the outcome, including anything that had to be thrown away.

Follow-up

• The change arrives the day before release. What do you do?
• When would you push back on a requirement change?
• How do you limit rework when requirements are still unclear?

Describe a scenario where you had to debug a critical issue under tight deadlines. What steps did you take?

Medium · Problem-Solving / Case Studies

Approach

1. Tell it as a story with a sequence. Contain the damage first (roll back, disable a feature flag, or fail over), then tell stakeholders the impact and when the next update will come.
2. Gather evidence before theorising: error logs and stack traces, what changed recently (deploys, configuration, data), and whether the issue affects all users or a subset.
3. Narrow it down systematically: reproduce in a lower environment, compare a good and a bad case, and use git bisect or a deploy diff to isolate the change.
4. Fix with a test that reproduces the defect, release it, confirm the metrics recovered, then write up the root cause and one preventive action.
5. Show calm ordering under time pressure. Patching blindly in production without containment or evidence is the weak version of this story.

Follow-up

• How do you decide between rolling back and fixing forward?
• How did you keep stakeholders informed while you were debugging?
• What did you change afterwards to stop it from happening again?

Suggested practice checklist

Each day covers one group of reported questions or one listed technology (Java, Spring Boot, Python, Jira and JQL, databases). Each one ends in something you can reuse in the loop: working code, a written answer or a rehearsed story.

Day 1 — Map the loop and prepare the screening call

• Write the four reported stages in order and, for each, list the reported question types you need ready for it.
• Write your background walkthrough: each recent role with its language, framework and one measurable result.
• Write your answer to the programming-languages question, covering Java, Python and JavaScript strengths and costs with one project each.
• List questions for the screener about the technical stage format (live or take-home) and the allowed languages.

Deliverable: A one-page loop map, a background walkthrough, a written languages answer and a list of screening questions.

Day 2 — Coding fundamentals: strings and two sum

• Implement string reversal in Java (StringBuilder and a two-pointer char-array version) and in Python, with tests for null, empty, single-character and emoji input.
• Implement two sum with a hash map in Java and Python, plus the sorted two-pointer variant, with tests for [3, 3], no solution and negative numbers.
• Solve both again from a blank file while talking through complexity out loud.

Deliverable: Tested Java and Python solutions for string reversal and two sum, and a spoken run-through of each.

Day 3 — Sorting and complexity

• Implement merge sort and quicksort (random pivot) in your interview language, with tests for empty, single, duplicate, sorted and reverse-sorted input.
• Write a comparison table of insertion, merge, quick and heap sort: time, space, stability and best use.
• Write down what Java's Arrays.sort and Python's sorted use and why stability matters for multi-key sorts.

Deliverable: Two tested sort implementations and a one-page comparison table of sorting algorithms.

Day 4 — Java, OOP and Spring Boot from your own code

• Build a small Spring Boot REST service: one controller, one service behind an interface, one Spring Data JPA repository and a JUnit test with a mocked dependency.
• Use that service to write your OOP answer: encapsulation, abstraction, polymorphism, and composition over inheritance.
• Write your code-quality answer (tests, review, CI, documentation) and your Git answer (branching, revert vs reset, rebase rules, bisect).

Deliverable: A running Spring Boot service with a test, plus written OOP, code-quality and Git answers that reference it.

Day 5 — Performance, debugging and databases

• Turn on SQL logging in the day 4 service, create an N+1 query through a lazy relation, fix it with a fetch join, and record the query count before and after.
• Work the database practice questions on backfilling a denormalised column and detecting concurrent edits, linking the second to JPA's @Version optimistic locking.
• Write your slow-application answer as a measure, profile, fix, verify sequence, and your debugging-under-deadline story in STAR form.

Deliverable: A before-and-after N+1 measurement, two database practice answers, and written slow-application and debugging answers.

Day 6 — Behavioral story bank and Jira workflow

• Write first-person STAR stories for the difficult teammate, the project you led, prioritisation, feedback, a changing requirement and a hard technical problem, each with a measurable result.
• Write three JQL filters you would actually use (your open work by priority, the current sprint's unresolved bugs, tickets updated in the last week) for the prioritisation story.
• Rehearse every story out loud and cut anything that does not lead to the decision you made.

Deliverable: Six written STAR stories, three working JQL filters, and a spoken rehearsal of each story.

Day 7 — Hiring-manager preparation and full mock

• Write two project narratives for the hiring-manager discussion, each naming the decision you owned, the alternative you rejected and the outcome.
• Write your questions for the team: its stack, how work flows through Jira, what a new engineer works on first, and remote arrangements.
• Run a mock from a blank file: two sum and the slow-application question out loud, then the difficult-teammate story, and note any gaps to fix.

Deliverable: Two project narratives, a list of questions for the team and notes from a full mock run.

Behavioural preparation

Candidates report a behavioral stage that focuses on teamwork, communication and cultural alignment, followed by hiring-manager discussions about compatibility with the team. Build a bank of first-person stories with measurable results and rehearse them out loud. The prompts below are questions candidates report, quoted as given.

1. If a project requirement changes midway, how would you adapt?
2. Describe a challenging technical problem you encountered and how you solved it.

Tell me about a time you had to work with a difficult teammate. How did you handle it?

Medium · Behavioral / Leadership

Approach

1. Choose a real friction about the work (missed handoffs, dismissive reviews, a disagreement over design), not a personality clash you can only describe with adjectives.
2. Situation in two sentences, then the action. Show that you first worked out the other person's constraint or motive, then raised it privately and specifically ('the last two PRs merged without tests').
3. Show a concrete working agreement you reached, such as review turnaround, ownership split or a design doc before coding, and escalation only after a direct conversation failed.
4. Give the outcome in work terms (fewer reopened tickets, a delivered feature) and what you changed in your own behaviour.
5. What sinks this answer is blaming the teammate throughout or ending with 'they left the team'. The story must show what you did.

Follow-up

• What would you have done if the conversation had not changed anything?
• Looking back, what part of the friction was yours?
• How is your working relationship with that person now?

Describe an instance where you took the lead on a project. What was the outcome?

Medium · Behavioral / Leadership

Approach

1. Pick a project where you owned the outcome: the scope, the plan and the decisions, not just a large share of the code.
2. Explain how you broke the work down (for example epics and stories in Jira, with dependencies ordered so others were not blocked) and how you kept people informed.
3. Name one hard decision, such as cutting scope or changing the technical approach mid-way, with the trade-off and who you consulted.
4. State the outcome with a number (shipped on date X, latency cut from A to B, N users moved over) and one thing that went wrong and how you handled it.
5. Use 'I' for your own actions. A story told only as a group effort hides the leadership the question asks about.

Follow-up

• What was the hardest trade-off, and would you make it the same way again?
• How did you handle a teammate who fell behind?
• What would you change if you ran the project again?

How do you prioritize tasks when working on multiple projects?

Medium · Behavioral / Leadership

Approach

1. Give a method, then prove it with a real week. Rank work by impact and deadline, put items that unblock other people first, and slot quick fixes in around the larger work.
2. Make the order visible: keep an ordered backlog or board (for example a Jira board, with a JQL filter such as assignee = currentUser() AND resolution = Unresolved ORDER BY priority DESC, duedate ASC).
3. When two stakeholders' priorities collide, do not decide silently. Show both the cost of each order and get the people who own the priorities to choose.
4. Say what you deferred or dropped and how you communicated the slip early. An answer where nothing was dropped is not believable.
5. Avoid 'I make a to-do list and work hard'. It shows no judgement.

Follow-up

• Two managers each say their request is top priority. What do you do?
• Tell me about something you deprioritised that turned out to matter.
• How do you handle urgent interruptions such as a production issue during planned work?

Can you share an example of how you handled feedback or criticism?

Medium · Behavioral / Leadership

Approach

1. Pick specific, uncomfortable feedback about your work (unclear pull requests, underestimating tasks, communication in meetings), not a disguised strength.
2. Be honest about your first reaction, then show how you checked whether it was fair, for example by asking for examples or looking at your last few PRs.
3. Describe the concrete change you made and the evidence that it stuck: smaller PRs, estimates closer to actuals, or the same reviewer later noting the improvement.
4. Optionally add how you now give feedback, using the same specificity you found useful.
5. What sinks this answer is 'my weakness is that I care too much' or a story where the feedback was wrong and you were proven right.

Follow-up

• Tell me about feedback you disagreed with. What did you do?
• How do you give critical feedback to a peer?
• What is the most recent feedback you received?