Cognixia Software Engineer Interview Guide

The 60-second brief

Candidate-facing descriptions present Cognixia as a company that delivers software applications and digital solutions for clients and end-users. The reported material names no specific products, customers or teams, so treat anything beyond that as something to ask the recruiter. In this role, candidates describe designing, coding and testing applications, extending existing ones, building new features and sometimes working on internal tools, alongside product managers, designers and other engineers.

This guide is for candidates applying for a Software Engineer position at Cognixia, with the 1-3 years of development experience that candidates describe as typical. It covers all three reported rounds, the 18 reported questions (Java and design concepts, problem-solving cases, four coding problems and five behavioral prompts) and a seven-day plan that finishes with a full run-through.

Candidates report three rounds over roughly 3-5 weeks: a Recruiter Conversation, a Technical Assessment and a Behavioral Interview. Reported topics are Java, basic coding questions, computer science fundamentals and soft skills.

Focus areas

• Java
• Coding Interviews (basic coding questions)
• Computer Science Fundamentals

Overview

Candidates describe the Software Engineer role as everyday application work: designing, coding, testing and debugging software, translating requirements from product managers and designers into technical specifications, and taking part in code reviews. Typical projects are extending existing applications, building new features and internal tooling. The requirements candidates list are Java, Python or C#, an Agile working style, familiarity with databases and web technologies, and, as extras, a cloud platform (AWS or Azure), a front-end framework (React or Angular) and DevOps tooling.

The reported question set has four shapes. Five technical questions are about Java and engineering practice: abstract class versus interface, SOLID, a hard problem you solved, maintainable and scalable code, and design patterns you have used. Four problem-solving questions ask how you would outline a development process, debug a malfunctioning application, optimise existing software and trade performance against maintainability. Four are classic coding problems: reverse a linked list, binary search, a string problem such as anagrams, and the data structures behind an LRU cache. Five are behavioral prompts about conflict, motivation, leadership, prioritisation and learning quickly.

That mix shapes how to spend your time. The coding problems are standard, so the goal is fluent, bug-free Java (or your strongest listed language) that you can explain while writing. The conceptual and case questions are open-ended, so each needs a prepared structure and a real project behind it rather than a textbook definition. The behavioral round needs a small bank of stories with your own decisions and outcomes in them. Because the reported material gives no round-by-round format, use the recruiter conversation to ask what the technical assessment looks like and which language it expects.

The Cognixia interview process

Candidates report three stages, in this order, over roughly 3-5 weeks. The reports do not say how long each stage lasts or how they are scored, so ask the recruiter for the format of each one.

Recruiter Conversation

Candidates report the first stage as a conversation with a recruiter about your background and aspirations. Treat it as the point where your CV is matched to the role: the requirements candidates describe name Java, Python or C#, Agile practice, databases and web technologies. Go in with a short, specific account of what you built and which of those technologies you used, and use the call to ask how the technical assessment is run.

What to demonstrate

• How your background and career aims fit a Software Engineer role
• Whether your hands-on experience lines up with the languages and practices listed for the position
• How clearly you describe your own projects and your reasons for applying

How to prepare

• Write a walkthrough of your CV in which each project has your role, the stack (Java, Python, C#, database, web layer) and one outcome.
• Prepare two or three sentences on where you want to grow as an engineer, tied to the kind of work the role involves: new features, existing applications, internal tools.
• List questions to ask: the language and format of the technical assessment, who the behavioral interview is with, and what the team works on.
• Have your availability and logistics ready so the call stays on your skills.

Technical Assessment

Candidates report this stage as an assessment of coding skills and problem-solving, with the topics listed as Java, basic coding questions and computer science fundamentals. The reported questions that fit it by type are the Java and design concepts (abstract class versus interface, SOLID, design patterns), the four coding problems (linked list reversal, binary search, anagrams, LRU cache) and the problem-solving cases on debugging and optimisation. The format is not described, so prepare both for writing code and for explaining concepts aloud.

What to demonstrate

• Working code for standard data-structure and string problems
• Java and object-oriented design knowledge, including SOLID and design patterns
• Problem-solving approach on debugging, optimisation and trade-off questions
• Clarity when you explain your reasoning as you work

How to prepare

• Write the linked-list reversal, binary search, anagram check and LRU cache in Java from a blank file, then test each with empty, single-element and duplicate inputs.
• Prepare a precise answer on abstract class versus interface in Java, including default methods, state and single versus multiple inheritance, with a small code example.
• Give each SOLID letter a before-and-after example from code you have written, and name three design patterns you have actually used and why.
• Build a spoken sequence for debugging a malfunctioning application and for optimising existing software: reproduce, measure, narrow down, fix, verify.

Behavioral Interview

Candidates report the last stage as a behavioral interview about interpersonal skills and fit with the company's stated values. The reported prompts cover team conflict, motivation, leadership, prioritising across projects and learning a technology quickly. Treat each as a story you can tell with a clear situation, your action and a result, and prepare one story that can answer more than one prompt.

What to demonstrate

• Teamwork, communication and how you handle disagreement and feedback
• Your own role in a project, including any leadership without a formal title
• How you adapt, prioritise and pick up unfamiliar technology

How to prepare

• Write five stories, one per reported prompt, each with the situation in two sentences, your decision, the result and what you would change.
• Include at least one story from a code review, a production issue or a requirements change, since those are the situations the role involves.
• Rehearse each story aloud until you can tell it without notes and cut it short when asked.
• Prepare questions about how the team collaborates, how code review works and how new engineers are onboarded.

Where candidates lose points

Answering abstract class versus interface with a vague one-liner such as "interfaces are for contracts"

Prepare the concrete differences in Java: an abstract class can hold state and constructors and a class extends only one, while an interface allows many implementations and, since Java 8, default methods. Then add an example of when you would choose each.

Reversing the linked list but losing the rest of the list because the next pointer was overwritten, or failing on empty and single-node input

Keep previous, current and next pointers and save next before you rewire. Say that it runs in O(n) time with O(1) extra space, and walk through empty, one-node and two-node lists before saying you are done.

Naming a hash map and a linked list for the LRU cache without explaining how get and put each stay O(1)

Explain that the map points to nodes of a doubly linked list, with the most recent at the head. A get moves the node to the head, and a put at capacity removes the tail node and its map entry. Practise writing it out, including the capacity-one case.

Answering the debugging and optimisation questions with a scatter of guesses instead of a sequence

Practise one order: reproduce the failure, check logs and recent changes, narrow the area by bisecting, form one hypothesis, fix, then add a test. For optimisation, measure with a profiler first and confirm the change helped.

Giving behavioral stories in which "we" did everything and no decision, result or lesson belongs to you

For each story, write the action you took and the result in one line each, and cut the background to two sentences. Keep a story for conflict, leadership, prioritisation and fast learning, since those are the reported prompts.

Questions & practice

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Clarify the node type and the return value (the new head), and confirm whether the list is singly linked and may be empty.
2. Iterative solution with three references: prev = null, curr = head. In the loop, save next = curr.next, set curr.next = prev, then advance prev = curr and curr = next. Return prev when curr is null.
3. Complexity: O(n) time and O(1) extra space. The recursive version is also O(n) time but uses O(n) call stack, which can throw StackOverflowError in Java on a very long list.
4. Walk through the edge cases out loud: an empty list (return null), a single node, two nodes. Also check that the old head's next ends up null, so the result has no cycle.
5. Test it by building a list of 1..5, reversing it, and printing it, or by reversing twice and comparing with the original.

Follow-up

• Reverse only the part of the list between positions m and n.
• Reverse the list in groups of k nodes.
• How does the code change for a doubly linked list?

Explain how you would implement a binary search algorithm.

Medium · Coding / Algorithms

Approach

1. State the precondition: the input must be sorted (or the predicate monotonic). Binary search halves the search range each step, so it takes O(log n) comparisons and O(1) extra space when written iteratively.
2. Write it with clear invariants: lo = 0, hi = n - 1, loop while lo <= hi, compute mid = lo + (hi - lo) / 2 (or (lo + hi) >>> 1) to avoid int overflow, then return mid on a match or move lo = mid + 1 or hi = mid - 1.
3. Handle the variants: to find the first occurrence or insertion point, use a half-open range [lo, hi) with while (lo < hi), and set hi = mid when a[mid] >= target. That avoids infinite loops caused by mid not moving.
4. Edge cases: empty array, a single element, the target smaller or larger than every element, and duplicates. Java's Arrays.binarySearch makes no promise about which duplicate it returns, and when the key is absent it returns -(insertionPoint) - 1.
5. Mention that it needs random access: on a linked list, reaching the midpoint costs O(n), so it is no faster than a linear scan.

Follow-up

• Search for a target in a sorted array that has been rotated.
• Find the first bad version, or the minimum capacity that meets a constraint (binary search on the answer).
• How would you search a sorted file too large to fit in memory?

Solve a coding challenge involving string manipulation (e.g., checking for anagrams).

Medium · Coding / Algorithms

Approach

1. Clarify the rules first: case sensitivity, whether spaces and punctuation count, and the character set (ASCII lowercase or full Unicode).
2. Return false immediately if the lengths differ after normalisation. Then count: for lowercase ASCII, an int[26] incremented for one string and decremented for the other, with all zeros meaning an anagram. That is O(n) time and O(1) extra space.
3. For a general alphabet, use a HashMap<Character, Integer> or iterate codePoints(), because a Java char is a UTF-16 code unit and characters outside the Basic Multilingual Plane take two chars.
4. Mention the sorting alternative: sort both char arrays and compare. It is O(n log n), simpler, but slower.
5. For other string manipulation questions (palindromes, reversing words, removing duplicates), remember that Java strings are immutable. Build output with StringBuilder, because repeated + concatenation in a loop costs O(n^2).

Follow-up

• Group a list of words into anagram groups (key by the sorted word or by a count signature).
• Find every start index in a text where an anagram of a pattern begins (a sliding window with counts, O(n)).
• How does your solution change for Unicode input with accented characters?

What data structures would you use to implement a LRU cache?

Medium · Coding / Algorithms

Approach

1. Name the combination: a HashMap from key to node, plus a doubly linked list ordered by recency. The map gives O(1) lookup, and the list gives O(1) move-to-front and O(1) removal of the least recently used node at the tail.
2. get: look up the node, return a miss if absent, otherwise unlink it and insert it at the head. put: if the key exists, update its value and move it to the head; otherwise insert a new node, and if the size exceeds capacity, remove the tail node and its map entry.
3. Store the key inside each node so that evicting the tail can also delete the map entry, and use sentinel head and tail nodes to remove null checks at the ends.
4. Know the Java shortcut: new LinkedHashMap<>(capacity, 0.75f, true) gives access order, and overriding removeEldestEntry to return size() > capacity evicts automatically. Be ready to write the manual version too.
5. Edge cases and concurrency: capacity 0 or 1, and updating an existing key without evicting. LinkedHashMap is not thread-safe, and in access-order mode even get changes the list, so a read-write lock is not enough. Use an exclusive lock or a concurrent cache library.

Follow-up

• Make the cache thread-safe without one global lock becoming the bottleneck.
• Add a time-to-live per entry, or change the policy to LFU.
• How would you run this cache across several servers?

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?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

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

Approach

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

Follow-up

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

Explain the difference between an abstract class and an interface in Java.

Medium · Technical / Domain Questions

Approach

1. Start with the structural difference: an abstract class can hold instance fields, constructors and methods of any access level, while an interface field is implicitly public static final and an interface has no constructor.
2. Cover inheritance: a class extends one class but can implement many interfaces, and an interface can extend several interfaces. That is why interfaces describe capabilities shared by unrelated types (Comparable, Runnable).
3. Bring it up to date. Since Java 8 interfaces can have default and static methods, and since Java 9 private methods. So the remaining difference is state and constructors, not whether methods have bodies.
4. Give a concrete rule: I use an abstract class when closely related subclasses share state or a template method, and an interface when I am defining a contract that many implementations or a lambda (a functional interface with one abstract method) can satisfy.
5. Mention the edge cases: neither can be instantiated directly, an abstract class may have no abstract methods at all, and an abstract class can implement an interface without implementing all of its methods.

Follow-up

• If a class implements two interfaces that both define the same default method, what happens and how do you resolve it (override it, then call InterfaceName.super.method())?
• Would you turn an existing abstract class into an interface? What breaks for subclasses that relied on its fields or constructor?
• Where do sealed classes and sealed interfaces (Java 17) fit in this choice?

What is the significance of the SOLID principles in software development?

Medium · Technical / Domain Questions

Approach

1. Name all five principles with a one-line meaning each: Single Responsibility (one reason to change), Open/Closed (extend behaviour without editing tested code), Liskov Substitution (a subtype must honour its parent's contract), Interface Segregation (clients do not depend on methods they never call), Dependency Inversion (high-level code depends on abstractions, not concrete classes).
2. Explain why they matter: they lower coupling, so a change stays local and a class can be unit-tested in isolation, for example by injecting a fake repository through the constructor.
3. Give one concrete example per principle where possible, such as the Square/Rectangle case for Liskov: a Square that forces height to equal width breaks callers that set width and expect height to stay the same.
4. For Open/Closed, show the mechanism: replace a growing switch on payment type with a Strategy interface, so a new type is a new class rather than an edit to a shared method.
5. Close with the trade-off: applying SOLID mechanically produces one-implementation interfaces and deep indirection. I add an abstraction when a second variation or a test actually needs it.

Follow-up

• Show me a class from your own code that violated Single Responsibility. How did you split it?
• How is Dependency Inversion different from dependency injection?
• When have you deliberately not applied one of these principles, and why?

Describe a challenging technical problem you solved, and the approach you took.

Medium · Technical / Domain Questions

Approach

1. Pick a problem with real technical content (a race condition, a slow query, a memory leak, a failing integration), and say in one or two sentences why it was hard: intermittent, production-only, or with no clear owner.
2. Spend most of the answer on how you narrowed it down: what you measured, which hypotheses you ruled out and with what evidence (logs, profiler output, a minimal reproduction, a bisected commit).
3. Explain the fix and the alternatives you rejected, with the reason for each, for example 'adding a lock fixed it but serialised a hot path, so I made the counter atomic instead'.
4. Give a measurable result and what you did to stop it recurring: a regression test, an alert, a runbook entry.
5. Talk in first person singular about your own actions. A story told only at team level, or one with no numbers, leaves nothing for the listener to judge.

Follow-up

• What would you have done if your first hypothesis had been confirmed instead of ruled out?
• How did you verify the fix in production rather than only locally?
• What would you do differently if the same problem came up again tomorrow?

How do you ensure your code is maintainable and scalable?

Medium · Technical / Domain Questions

Approach

1. Split the answer into two parts, because maintainability and scalability are different properties: maintainability is how cheaply the next person can change the code, scalability is how it behaves as load or data grows.
2. For maintainability, name concrete practices: small cohesive classes and methods, clear names, unit tests around behaviour run in CI, code review, and static analysis (Checkstyle, SpotBugs or SonarQube in a Java codebase).
3. For scalability, name concrete risks and fixes: keep services stateless so they can scale horizontally, avoid N+1 database queries, add indexes for the real access paths, paginate large result sets, and cache only data whose staleness I can tolerate.
4. Say how you check both: complexity analysis and load tests for scale, test coverage of the change paths and review feedback for maintainability. Do not optimise before a measurement shows a bottleneck.
5. Tie it to an example from your own code: one refactor or one scaling fix, the before and after, and the number that moved.

Follow-up

• How do you safely change legacy code that has no tests (characterisation tests first)?
• Give an example where making code more scalable made it harder to maintain. How did you contain that?
• Which metric would tell you a service is about to hit a scaling limit?

What are some design patterns you have used in your projects?

Medium · Technical / Domain Questions

Approach

1. Name two or three patterns you have actually used, and for each give the problem it solved, the pattern and the consequence. A list of pattern names with no context is not an answer.
2. Strong concrete options: Strategy (swappable algorithms such as pricing or validation rules), Builder (objects with many optional fields, kept immutable), Factory (choosing an implementation from configuration), Observer (event listeners), Decorator (adding behaviour by wrapping, as java.io does with BufferedInputStream around an InputStream).
3. Be ready to sketch one in code: the interface, two implementations and the call site, and how a new variant is added without editing the caller.
4. Discuss the costs: Singleton brings global state and makes testing harder, so I prefer a single instance managed by dependency injection, and patterns add indirection that is only worth it when the variation is real.
5. Know the classic distinctions: Strategy versus State (the client chooses the strategy, a state object switches itself), and Adapter versus Decorator (Adapter changes the interface, Decorator keeps it and adds behaviour).

Follow-up

• How do you make a lazily created Singleton thread-safe in Java (the holder-class idiom, an enum, or double-checked locking with a volatile field)?
• Tell me about a time a pattern was overkill and you removed it.
• Which patterns does the Java standard library or a framework you use rely on?

Given a specific software requirement, how would you outline your development process?

Medium · Problem-Solving / Case Studies

Approach

1. Start by clarifying the requirement: who uses it, the inputs and outputs, the acceptance criteria and the non-functional limits (expected load, latency, security, data retention). Write the open questions down and confirm them with the requester.
2. Break the work into small, independently deliverable slices that fit an Agile iteration, and identify the riskiest unknown so you can spike it first.
3. Design before coding: data model, API contract and error cases, reviewed with a teammate. Record any decision someone will later ask about.
4. Implement with tests alongside the code (unit tests for logic, integration tests for the database and API boundaries), open small pull requests for review, and let CI run the suite on every change.
5. Deploy incrementally, ideally behind a feature flag, with logging and metrics on the new path, then confirm the acceptance criteria with the stakeholder and feed what you learn into the next slice.

Follow-up

• The requirement changes halfway through the work. What do you do with the work already done?
• How would you estimate this work, and what would you do when the estimate turns out wrong?
• Which tests would you skip under deadline pressure, and which never?

How would you approach optimizing an existing piece of software?

Medium · Problem-Solving / Case Studies

Approach

1. Define the goal and the metric before touching code: latency (p95/p99, not only the average), throughput, memory or cost, and record a baseline under a realistic workload.
2. Profile to find where the time actually goes (Java Flight Recorder, async-profiler, VisualVM, database query plans) instead of guessing. By Amdahl's law, speeding up code that takes 10% of the runtime can save at most 10%.
3. Fix in order of payoff: algorithmic complexity first (a nested-loop O(n^2) lookup replaced by a HashMap for O(n)), then I/O (N+1 queries, missing indexes, batching), then caching and concurrency, and micro-optimisations last.
4. Verify each change on its own against the baseline (JMH for Java microbenchmarks, a load test for the service), and keep the existing tests passing so behaviour does not change.
5. Name the costs: caching adds invalidation and staleness, concurrency adds race risk, and tuned code is harder to read, so stop once the target is met.

Follow-up

• The profiler shows time spread evenly with no single hotspot. What next?
• How would you stop the improvement from quietly regressing later?
• When would you choose more hardware over optimising the code?

Describe a scenario where you had to make a trade-off between performance and maintainability.

Medium · Problem-Solving / Case Studies

Approach

1. Pick a real decision with numbers on both sides: for example a hand-written SQL query or denormalised table in place of ORM calls, a cache in front of a slow dependency, or a plain loop replacing a stream pipeline in a measured hot path.
2. State the measured problem that forced the choice (latency, throughput, memory) and the two options, with what each costs in performance and in code complexity.
3. Explain the decision and how you contained the complexity: kept the optimised code behind a clean interface, documented why it exists, and added a benchmark or test that guards both its behaviour and its speed.
4. Give the outcome with numbers, and say whether you would make the same call today.
5. Avoid a story that ends with 'performance always wins' or 'readability always wins'. The answer should show you weighed both against a measured requirement.

Follow-up

• What would have made you choose the other option?
• How did you make the optimised code safe for the next engineer to change?
• Have you ever reverted an optimisation? Why?

What steps would you take to debug a malfunctioning application?

Medium · Problem-Solving / Case Studies

Approach

1. Pin down the symptom first: the exact error or wrong output, who is affected (all users or a subset), since when, and whether you can reproduce it. A reliable reproduction is the most valuable artefact in the whole process.
2. Ask what changed around the start time (a deploy, a config change, a dependency upgrade, a data change, traffic growth) and check logs, stack traces and metrics before forming a theory.
3. Narrow the search systematically: build a minimal reproduction, use a debugger or targeted logging, and bisect. git bisect finds the bad commit in about log2(n) test runs.
4. Use the right tool for each class of failure: read the full Java stack trace including 'Caused by', take a thread dump (jstack) for hangs or deadlocks, and a heap dump plus allocation analysis for OutOfMemoryError or a slow memory leak.
5. Fix the root cause rather than the trigger, add a regression test that fails without the fix, verify after deployment, and write down what detection would have caught it sooner.

Follow-up

• The bug only appears in production and never locally. What do you do next?
• How would you debug an intermittent failure that looks like a race condition?
• How do you tell the cause apart from something that merely changed at the same time?

Suggested practice checklist

The plan moves through the reported stages: Java concepts and design questions first, then the four coding problems, the debugging and optimisation cases, your own project stories, and finally a full run-through in the order candidates report.

Day 1 — Map the loop and plan around your stack

• Write the three reported rounds (Recruiter Conversation, Technical Assessment, Behavioral Interview) and mark the one you are least ready for.
• Make a stack inventory covering Java, Python or C#, the databases you have used, web technologies and any cloud or front-end experience, with one project for each.
• Write a CV walkthrough and a list of questions for the recruiter, including the assessment format and the language it uses.

Deliverable: A one-page round map, a stack inventory with a project per item, a written CV walkthrough and a list of recruiter questions.

Day 2 — Java object-oriented concepts and design vocabulary

• Write a small Java example with an abstract class and an interface (with a default method) and write the rules for choosing between them.
• For each SOLID principle, write a before-and-after code snippet and say what problem the change solves.
• Pick three design patterns you have used, such as strategy, factory or observer, and write when each helps and what it costs.

Deliverable: A Java file with the abstract class and interface example, five SOLID before-and-after snippets and a three-pattern note with trade-offs, each answerable aloud.

Day 3 — Coding problems: linked list, binary search, anagrams, LRU cache

• Write the linked-list reversal both iteratively and recursively and note the space cost of each.
• Write binary search with the loop invariant, then the first-occurrence variant, and test it on empty, single-element and duplicate arrays.
• Write the anagram check using a character-count array or map and compare it with sorting.
• Build the LRU cache from a hash map and a doubly linked list, with get and put in O(1) time.

Deliverable: Four Java solutions, each with its complexity stated and a short list of tested edge cases.

Day 4 — Problem-solving cases: process, debugging, optimisation, trade-offs

• Take a sample requirement and write the steps you would follow from clarifying questions through design, implementation, tests, review and release.
• Write a debugging sequence for a malfunctioning application, from reproducing the failure through to a regression test.
• Outline how you would optimise existing software, starting with measurement, and write one performance-versus-maintainability trade-off you have faced or can reason through.

Deliverable: Three written outlines (development process, debugging sequence, optimisation plan) and one trade-off example, each ready to say aloud.

Day 5 — Your own projects: hard problems, maintainability and the data layer

• Write the story of a challenging technical problem: the symptoms, what you tried, the fix and the result.
• Write your answer on keeping code maintainable and scalable, with examples such as tests, code review, module boundaries and handling load.

Deliverable: Two written project answers backed by real examples and two completed SQL practice problems with explanations.

Day 6 — Behavioral story bank

• Write one story each for team conflict, leadership, prioritising across projects and learning a technology quickly: situation, your action, result and lesson.
• Write a short answer on what motivates you, tied to a concrete thing you did.
• Say each story aloud and cut it until you can tell it clearly without notes.

Deliverable: Five rehearsed stories or answers, each in a written version with your decision and result stated in a line.

Day 7 — Full run-through in the reported order

• Rehearse the recruiter conversation using your CV walkthrough and your questions.
• Solve the LRU cache and linked-list problems again from scratch and explain the reasoning as you write.
• Answer the debugging and conflict questions aloud, and note which answers wandered.

Deliverable: A run-through of all three stages with the weakest answers noted and a short list of fixes.

Behavioral stories for the final round

Candidates report that the final round looks at interpersonal skills and fit with the company's stated values, and the reported prompts cover conflict, motivation, leadership, prioritising and learning quickly. For a developer with a few years of experience, the strongest stories come from code reviews, shared ownership of a feature, competing deadlines and picking up an unfamiliar stack. Each should show your own decision and the result.

1. Tell me about feedback you received in a code review and what you changed because of it.

Describe a time when you faced a conflict within a team. How did you handle it?

Medium · Behavioral / Leadership

Approach

1. Choose a real disagreement with a peer or lead, ideally about a technical approach, ownership or a deadline, and state the situation in two sentences.
2. Show that you understood the other person's position before arguing yours: say what you asked or restated, and what their concern was.
3. Describe the neutral criterion you used to settle it, such as a small prototype, a benchmark, the written requirement or the opinion of the person who owns the decision.
4. Give the outcome and the working relationship afterwards, and say what you would do differently.
5. The mistake that sinks this answer is a story where the other person is simply wrong, or where the conflict was solved by someone else escalating it.

Follow-up

• What if the other person still disagreed after you showed the evidence?
• What would you do differently if you ran that situation again?
• How did your working relationship look a month later?

What motivates you to excel in your work?

Medium · Behavioral / Leadership

Approach

1. Name one or two real motivators and back each with a specific behavior, such as shipping a feature users adopted, tracking down a hard bug, or helping a newer teammate get unblocked in review.
2. Tie them to the work the role involves (designing, coding, testing, improving existing applications) so the answer describes the job rather than a generic trait.
3. Give one short example where that motivation made you do something concrete, like adding tests nobody asked for or rewriting a confusing module, and say what came of it.
4. Avoid answers that are only about pay, title or being challenged, and avoid motivators that would be unmet in everyday maintenance work.

Follow-up

• What drains your motivation, and what have you done when that happened?
• Tell me about a project where your motivation dropped. How did you handle it?
• How do you keep your quality up on repetitive or unglamorous tasks?

Can you give an example of how you have demonstrated leadership in a project?

Medium · Behavioral / Leadership

Approach

1. Pick a project where you led without a title: owned a feature end to end, set up a testing or review practice, planned a migration or onboarded a new teammate.
2. Say what you decided, how you got others aligned (a short design note, a demo, pairing), and how you split or tracked the work.
3. Keep the scope honest and quantify the result where you can, such as defects reduced, a release delivered or a teammate productive sooner.
4. Include one thing that did not go smoothly and how you adjusted.
5. The common mistake is describing what the team achieved without saying what you personally decided.

Follow-up

• How did you handle a teammate who did not follow the approach you set?
• How did you decide what to delegate and what to do yourself?
• What did that experience teach you about how you want to lead next time?

How do you prioritize tasks when working on multiple projects?

Medium · Behavioral / Leadership

Approach

1. State your method briefly: list what is due, rank by impact on users or the business, deadline and dependencies, and estimate effort so you can see what fits.
2. When two commitments collide, say that you go to the people who set the priorities, show the trade-off and agree explicitly what slips, rather than quietly working longer hours.
3. Give one concrete collision, for example a production bug landing in the middle of a feature, and walk through what you did first, what you postponed and how you told people.
4. Mention how you keep it visible (a board or written list) and how you re-check priorities when something changes.
5. A framework with no example, or an answer that amounts to working harder, will not persuade.

Follow-up

• What do you do when two managers each say their task is the most urgent?
• How do you handle an urgent bug that interrupts planned work?
• How do you decide something can safely be dropped or deferred?

Describe a situation where you had to learn a new technology quickly.

Medium · Behavioral / Leadership

Approach

1. Pick a situation with a real deadline, such as a new framework, a language outside your usual one among Java, Python or C#, a front-end library or a cloud service, and say why you had to learn it fast.
2. Describe your method: define the minimum you needed, read the official documentation, build a small spike, then apply it to a real task and ask a teammate to review.
3. Say how you checked you understood it, through tests, reading the framework's error messages and explaining the design back to a colleague, not just copying working snippets.
4. Close with the result delivered and what you got wrong early on.
5. Stories that consist of watching tutorials, with no shipped outcome, are the ones that fall flat.

Follow-up

• How did you know you understood it well enough to ship?
• What did you get wrong at first, and how did you find out?
• How would you approach an unfamiliar cloud platform or front-end framework for this role?