The reported loop splits into three kinds of conversation. The first two rounds are about you: background, language skills, salary expectations and location flexibility with an HR recruiter, then soft skills, career goals and fit with current projects with a Business Manager. The next two are technical: an online coding game on your main programming language followed by a technical interview, then a deeper technical interview with a Tech Lead or Engineering Manager. The last round is with the client, who checks technical fit for a specific team and stack. Preparation therefore has three tracks: your story and profile, your fundamentals, and your fit for one client's stack.
The twenty reported questions fall into four groups. Technical knowledge: OOP and polymorphism in C++ or Java, a REST API for asynchronous processing, Docker experience, relational versus NoSQL, and minimum and maximum searches across sub-arrays. Architecture: a microservices application in Java Spring or Python, how Kafka handles high-throughput events, CI/CD in client-driven projects, concurrency in backend systems, and joining a legacy codebase. Project experience: a thesis or complex project, tools and testing frameworks, a hard bug, picking up a new framework quickly, and documentation for handoff. Consulting mindset: ambiguous or changing requirements, quality against deadlines, updates for non-technical stakeholders, why consulting, and multi-location collaboration. Several of these ask for your experience (Docker, CI/CD, tools) rather than a definition, so each needs a real project behind it.
The topics reported most often are programming languages in general, coding challenges and coding games, hard-skill technical interviews, Java and C++. Choose one primary language and know it well enough to explain why a feature works, not only how: virtual dispatch, collections, threading and memory behaviour. Add SQL (joins, GROUP BY, indexing, a multi-tenant schema), basic algorithm analysis, and one backend stack story each for Spring Boot or Python, Docker and Kafka. Candidates also describe completing a Professional Profile (a competence dossier) with the Business Manager, so every technology you list there should be one you can discuss in depth.
The consulting side matters as much as the code. For recent graduates, candidates report that the weight falls on how solid the thesis is, on computer science fundamentals and on genuine interest in consulting, more than on hands-on framework experience. Experienced candidates should frame stories in a client context: what the client needed, what changed, how you reported progress and what the business got. The requirements candidates describe list fluency in Spanish and working English, so rehearse your key stories in both languages.
Phone Screening
reportedCandidates report a call with an HR recruiter about your background, language skills, salary expectations and geographic flexibility. Treat it as a structured conversation where short, factual answers matter: a clear CV walkthrough, your languages and level, your location constraints and your availability. Reports also say a Professional Profile is completed early in the process, so decide now which technologies belong on it.
What to demonstrate
- Career background and the technologies you have used
- Spanish and English language skills
- Salary expectations and geographic flexibility
How to prepare
- Write a CV walkthrough that ties each job or project to one technology and one result, ending with why consulting.
- Decide your salary range, location limits and availability before the call, and answer each in a sentence.
- Tag every technology on your CV as 'can explain in depth', 'used' or 'leave off', and keep only the first two on the Professional Profile.
- Be ready to answer part of the call in English as well as Spanish.
Business Manager Interview
reportedCandidates report a broader conversation with a Business Manager covering soft skills, career goals and alignment with current projects. The wider process descriptions add that this stage reviews your experience, discusses delivery streams and completes the Professional Profile. This is where the consulting-mindset questions (ambiguity, quality against deadlines, working across locations, why consulting) are most useful to rehearse.
What to demonstrate
- Soft skills and communication
- Career goals and how they match available projects
- Experience as it will appear in the Professional Profile
How to prepare
- Prepare two project stories in STAR form, each stating your personal contribution, the tools and the outcome.
- Write your answer to the reported question about choosing consulting over a product company, including the trade-off you accept.
- Ask about delivery streams, training certifications, typical client domains and career paths, as candidates are advised to.
- Write the Professional Profile skills section so each line has a project that backs it up.
Technical Assessment
reportedCandidates report an online coding game that tests your main programming language, followed by a technical interview. Candidates describe coding tests that target OOP, array manipulation, string algorithms and SQL queries. Pick your strongest language and practise in it: arrays and strings, hash maps, sorting, stack and queue operations, plus the complexity of each solution said aloud. The reported coding question about minimum and maximum values across sub-arrays is good practice for the format.
What to demonstrate
- Working code in your primary programming language
- Algorithm and data structure fundamentals with Big-O reasoning
- Core concepts discussed in the follow-on technical interview
How to prepare
- Solve the reported sub-array problem in your language: minimum of the first half, maximum of the second half, then arbitrary ranges, stating the complexity of each version.
- Write out edge cases before coding: empty array, one element, odd length, duplicates, negative numbers.
- Review SQL basics: JOIN types, GROUP BY with HAVING, and when an index helps.
- Practise explaining your code while writing it, since candidates are advised that clear communication counts alongside the answer.
Technical Interview
reportedCandidates report a deeper technical conversation with an Alten Tech Lead or Engineering Manager. Candidates also mention data structures, framework concepts and design patterns. Prepare depth in your own stack with mechanism-level answers: how polymorphism is implemented, how a Spring application is wired, how Kafka partitions scale consumers, and how you control shared state across threads.
What to demonstrate
- Depth in your primary language and OOP principles
- Framework and backend concepts such as Spring, REST, SQL and messaging
- Architecture reasoning and trade-offs
How to prepare
- Explain OOP and polymorphism with a short code example in Java or C++ and say how the runtime picks the method.
- Sketch a microservices application in Spring Boot or Python: service boundaries, database per service, sync versus async calls, Docker packaging.
- Rehearse a Kafka answer covering topics, partitions, consumer groups, offsets and delivery guarantees.
- Prepare one concurrency example with a shared-state bug and its fix, and one relational versus NoSQL decision from your own work.
Client Interview
reportedIn the last round, candidates report meeting the client, who checks whether your technical profile suits their particular team and stack. Because the stack is specific, the most useful preparation is to find out what the assignment uses and to line your Professional Profile up against it. Prepare to discuss each technology you list in detail, and to explain how you would work with a client's team.
What to demonstrate
- Technical fit with the specific team and tech stack
- Depth behind each technology listed on your profile
- Communication with a client audience
How to prepare
- Ask the Business Manager what the client's stack and domain are, then review those technologies specifically.
- Prepare an account of how you would approach a legacy codebase in your first weeks, including requirement analysis and architecture trade-offs.
- Rehearse your thesis or most complex project, naming the architecture decisions you personally made and what you would change now.
- Practise explaining progress and technical choices to non-technical listeners, in English as well as Spanish.
5 candidate reports. Individual accounts describe a particular role and hiring cycle.
Alten Delivery Centre Spain Software Engineer interview experience: Java Coding Game
After the recruiter stage, I took a Coding Game test. They emailed a list of technologies I could choose from, and the assessment used game-like questions and problems. My prompts were connected to Java, with a focus on logic, algorithms, and problem solving. It was not just theoretical. I had to reason through the prompts and apply the concepts to reach an answer. Afterwards, I spoke with the re…
Read full experienceAlten Delivery Centre Spain Software Engineer interview: client-mission fit
I first spoke with a recruiter about my background, then we discussed how my profile fit the work they were seeking. Even though it was an initial conversation, they followed up on what I had said with more detailed questions. I then spoke with the relevant business manager and, finally, had a technical interview with the client. The discussion centered on how I related to the planned work and th…
Read full experienceAlten Delivery Centre Spain Software Engineer Interview Experience: A missed appointment and no technical feedback
My process began frustratingly. Even while arranging it, I noticed misalignment and little care around timing. I had appointments where the other person seemed more focused on their own CV than on what was actually needed for the technical interview. In one instance, I arrived on time and waited without anyone coming. I flagged it immediately, but got neither an explanation nor an apology for the…
Read full experienceAlten Delivery Centre Spain Software Engineer Interview Experience: a backend task and disorganized client preparation
They contacted me on LinkedIn even though I hadn't applied. HR described a more one-time process and said my profile would stay in their database for future opportunities even if I decided not to continue. It sounded simple at first. In practice, it took much longer and was less organized than they'd led me to expect. I started with an HR screen and an interview with a backend technical lead. Tha…
Read full experienceAlten Delivery Centre Spain Software Engineer interview experience: broad role and compensation
After the first contact, the process was presented as a clear sequence: an introductory call to understand who I was, then a personal interview that was also meant to get to know me, and finally a dedicated technical interview where my skills were tested. The experience itself was smooth, without obvious detours or problems. I expected a narrower focus, but the role appeared to carry a fairly bro…
Read full experiencePracHub editorial advice for the preparation topics above.
Describing the thesis or most complex project as 'we built it' without naming your own architecture decisions
Prepare the walkthrough as decisions: the options you considered, the one you chose, why, and what it cost. Say which parts were yours. Recent graduates in particular are reported to be judged on thesis rigour, so be ready to defend the method and the results.
Listing technologies on the CV or Professional Profile that you cannot explain beyond the name
Tag each skill as 'can explain in depth', 'used' or 'leave off' before the Business Manager stage, and remove the last group. If Kafka or Spring Boot is on the page, be ready to cover partitions and consumer groups, or dependency injection and testability.
Answering the sub-array minimum and maximum question with nested loops and no complexity or edge cases
Clarify the exact ranges first (for example how an odd-length array splits into halves), write the single-pass O(n) version, state O(1) extra space, and test empty, single-element and duplicate inputs. Then say what changes for many arbitrary range queries: a sparse table (O(1) query after O(n log n) preprocessing) for a static array, or a segment tree (O(log n) query and update) if the array changes.
Reciting OOP definitions without a mechanism, such as 'polymorphism means many forms'
Give the mechanism: in C++ a virtual function is dispatched through the object's vtable pointer at runtime, while a non-virtual call is bound at compile time; in Java instance methods dispatch dynamically unless private, static or final. Add a short overriding example and mention overloading is resolved at compile time.
Answering consulting questions as personal obstacles, with no client, no trade-off and no business outcome
Frame each story around the client's need, the change or constraint, the options you priced, and what you reported. For 'why consulting', state the trade-off honestly rather than disparaging product companies.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How do you implement minimum and maximum value searches across sub-arrays, and what is the time complexity of
How do you implement minimum and maximum value searches across sub-arrays, and what is the time complexity of your approach?
Approach
- For the reported variant (minimum of the first half, maximum of the second half), fix the split before coding: mid = n / 2, and say which half gets the middle element when n is odd. Handle n = 0 and n = 1 explicitly instead of returning a sentinel by accident.
- One pass, or two loops over the two halves, is O(n) time and O(1) extra space, and that is optimal: any element left unread could be the answer. Initialize from the first element of each half so an empty half cannot silently return a sentinel such as INT_MAX, and handle empty halves explicitly.
- If both min and max of one range are needed, compare elements in pairs: about 3n/2 comparisons instead of 2n.
- For many queries on a static array, prefix sums do not work for min or max (no inverse); a sparse table answers in O(1) after O(n log n) preprocessing because overlapping ranges are fine for min. If the array is also updated, a segment tree gives O(log n) queries and updates after O(n) build.
- For the maximum of every window of size k, a monotonic deque of indices gives O(n) total, because each index is pushed and popped at most once.
Follow-up
- The array now receives point updates between queries: what structure do you use, and what are its costs?
- Return the maximum of every sliding window of size k. What does the deque hold, and why is it O(n)?
- How do your tests cover an odd length, duplicates and negative numbers?
What strategies do you use to manage concurrency and multithreading in enterprise backend systems?
What strategies do you use to manage concurrency and multithreading in enterprise backend systems?
Approach
- Start by naming the shared mutable state; the best fix is to have less of it: immutable objects, thread confinement, and request-scoped data instead of fields on singleton beans.
- Use executors, not raw threads: a bounded ThreadPoolExecutor sized near the core count for CPU-bound work and larger for blocking I/O, with a bounded queue and a rejection policy so overload is visible. On Java 21, virtual threads suit blocking I/O.
- Pick the lightest correct tool: ConcurrentHashMap and atomic classes (compare-and-swap) for counters and maps, synchronized or ReentrantLock for multi-step invariants, volatile only for visibility of a single flag. Avoid deadlock with a consistent lock order or tryLock with a timeout.
- JVM locks do not span service instances. For shared data use the database: optimistic locking with a version column (JPA @Version, retry on conflict) for low contention, SELECT ... FOR UPDATE for hot rows, unique constraints for idempotency.
- In Python, the GIL of standard CPython builds lets only one thread run bytecode at a time, so threads or asyncio fit I/O-bound work and multiprocessing fits CPU-bound work.
Follow-up
- Two instances decrement the same stock count at the same moment. Show the race and two ways to fix it.
- How would you diagnose a suspected deadlock in a running JVM?
- Why can a thread fail to see another thread's write without volatile or a lock?
Diff a projection against the primary without per-row point reads
The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.
Approach
- Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
- Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
- For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
- Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.
Follow-up
- The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
- Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?
Find version gaps and relay lag with window functions
outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.
Approach
- Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
- Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
- Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
- Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.
Follow-up
- Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
- Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?
Denormalise tenant onto revisions and backfill it live
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
- 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.
- 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.
- 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.
- 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?
Explain the core principles of Object-Oriented Programming (OOP) and how polymorphism is implemented in C++ or
Explain the core principles of Object-Oriented Programming (OOP) and how polymorphism is implemented in C++ or Java.
Approach
- Name the four principles with one concrete line each: encapsulation (private state behind methods that keep invariants), abstraction (callers depend on an interface, not an implementation), inheritance (an is-a relationship that reuses and extends behaviour), polymorphism (one call site, behaviour chosen by the object's type).
- Separate the two kinds of polymorphism: compile-time (overloading, and templates in C++) is resolved from static types; runtime polymorphism (overriding) is resolved from the object's dynamic type when the call happens.
- C++: only functions marked virtual dispatch dynamically, and only through a pointer or reference. Typical compilers give each polymorphic class a vtable and each object a hidden vptr; the standard does not mandate this layout. Passing a derived object by value slices it to the base.
- Java: non-static, non-private, non-final instance methods are virtual by default (invokevirtual / invokeinterface); static methods are hidden, not overridden. The JIT can devirtualize and inline a call site that only ever sees one type.
- Close with the trade-off: deep inheritance trees couple classes tightly, so I prefer an interface plus composition unless there is a true is-a relationship.
Follow-up
- Why does a C++ base class need a virtual destructor if objects are deleted through a base pointer?
- What happens when a constructor calls a virtual method, in C++ compared with Java?
- When would you choose composition over inheritance in a class you are designing?
How do you design and structure a REST API to handle asynchronous data processing effectively?
How do you design and structure a REST API to handle asynchronous data processing effectively?
Approach
- Split submission from result: POST /jobs validates the payload, stores a job row and returns 202 Accepted with a Location header pointing at GET /jobs/{id}.
- Model the job as a resource with explicit states (queued, running, succeeded, failed, cancelled), a progress field and an error object; once it succeeds, link to the result resource from the status response.
- Make submission idempotent: accept an Idempotency-Key header, store key to job id, and return the existing job on a retry so a client timeout cannot create duplicate work.
- Behind the API, workers pull from a queue (Kafka or RabbitMQ). Write the job row and the outbox message in one transaction so a crash cannot leave a job that is never enqueued; retry with backoff and route poison messages to a dead-letter queue.
- Offer polling with a Retry-After header for simple clients and a signed webhook callback for others; webhooks are delivered at least once, so receivers must dedupe on the job id.
Follow-up
- How would a client cancel a running job, and what does the worker do with half-finished output?
- How long do you keep results, and what does GET return after they expire?
- What changes if one request fans out into thousands of sub-tasks?
What are the main differences between relational databases and NoSQL systems, and when would you choose one ov
What are the main differences between relational databases and NoSQL systems, and when would you choose one over the other?
Approach
- Relational: fixed schema, normalized tables, joins, constraints (foreign keys, unique) and multi-row ACID transactions; SQL supports ad hoc queries you did not plan for. Scaling usually starts with indexes, a bigger machine and read replicas; sharding is possible but manual.
- NoSQL is several families, not one: document (MongoDB), key-value (Redis, DynamoDB), wide-column (Cassandra) and graph (Neo4j). They are modelled around known access patterns, often denormalize, and partition horizontally by key as a built-in feature.
- Correct the common myth: many NoSQL stores now offer transactions (MongoDB has multi-document transactions since 4.0), and relational engines store JSON (PostgreSQL jsonb). The real difference is the data model and how queries and scaling are shaped.
- Consistency: in Cassandra-style quorum systems, choosing R + W > N gives reads that see the latest acknowledged write; lower settings trade that for latency and availability.
- Choose relational for entities with relationships and integrity rules (orders, accounts, ledgers) or unknown future queries; choose NoSQL for very high write volume on a key-based access pattern, flexible document shapes, or caching. Polyglot setups use both.
Follow-up
- How would you model a one-to-many relationship in a document store: embed or reference, and why?
- What would you try on PostgreSQL before deciding you need to move to a NoSQL store?
- With eventual consistency, how do you make sure a user sees their own write right away?
Walk us through how you would architect a microservices-based application using Java Spring or Python.
Walk us through how you would architect a microservices-based application using Java Spring or Python.
Approach
- Split services by business capability (orders, catalogue, billing), each owning its own database; a shared database across services recreates a monolith with network calls. For a small team I would also say when a modular monolith is the better start.
- Edge and wiring: an API gateway (Spring Cloud Gateway, or a reverse proxy in front of FastAPI services) for routing and authentication, service discovery through Kubernetes DNS or Eureka, and externalized configuration.
- Communication: synchronous REST or gRPC when the caller needs the answer now, events on Kafka when other services only need to react. Every remote call gets a timeout, bounded retries with backoff, and a circuit breaker (Resilience4j in Spring).
- Cross-service writes: no distributed ACID transaction; use a saga (orchestrated or choreographed) with compensating actions, and a transactional outbox so the database change and the published event cannot diverge.
- Operations: one Docker image per service, health and readiness endpoints (Spring Boot Actuator), a correlation id passed on every call, distributed tracing with OpenTelemetry and centralized logs; services deploy independently through their own CI pipeline.
Follow-up
- An order must reserve stock and take a payment in two different services. Walk through the saga, including the failure path.
- How do you change an API that three other services call without breaking them?
- How do you test the contract between two services without starting the whole system?
Explain how message brokers like Kafka handle high-throughput event processing in distributed environments.
Explain how message brokers like Kafka handle high-throughput event processing in distributed environments.
Approach
- A topic is split into partitions, and each partition is an append-only log on disk. Partitions spread across brokers, so throughput scales by adding partitions and consumers.
- Throughput comes from the storage design: producers batch and compress records, brokers write sequentially and rely on the OS page cache, and consumers pull in large reads; with TLS off, brokers can send log data with zero-copy sendfile.
- Ordering is guaranteed only within a partition. The producer hashes the record key to pick a partition, so all events for one key (one customer id, say) stay in order; a skewed key creates a hot partition.
- Consumer groups: each partition goes to exactly one consumer in a group, so a group's parallelism is capped at the partition count. Consumers commit offsets; committing after processing gives at-least-once delivery, so handlers must be idempotent.
- Durability: replication factor 3, with acks=all and min.insync.replicas=2, means a write is acknowledged only once it sits on enough in-sync replicas. Idempotent producers and Kafka transactions give exactly-once within Kafka read-process-write pipelines.
Follow-up
- What happens to in-flight messages during a consumer group rebalance, and how do you avoid processing them twice?
- One key produces most of the traffic. How do you find the hot partition and fix it?
- How do you watch consumer lag, and what do you do when it keeps growing?
Describe how you approach requirement analysis and architecture trade-offs when joining an existing legacy cod
Describe how you approach requirement analysis and architecture trade-offs when joining an existing legacy codebase.
Approach
- First make it run: build it, run the existing tests, and trace one real request from entry point to database to map modules and dependencies. Read the issue history and ask the people who maintain it which areas break most.
- Collect requirements as functional behaviour plus constraints (performance, compliance, client release windows) and confirm them in writing; much of a legacy system's behaviour is undocumented, so the code is part of the requirements.
- Before changing anything, write characterization tests that pin current behaviour, including behaviour that looks wrong, then refactor behind those tests through seams such as interfaces and dependency injection.
- Prefer incremental replacement to a rewrite: the strangler fig pattern routes one capability at a time to new code, with branch by abstraction or feature flags for switching back, and expand-and-contract database migrations so old and new code run side by side.
- Record each trade-off (refactor or rewrite, keep or replace a library) as a short architecture decision record with the cost and risk of each option.
Follow-up
- When would you argue for a rewrite instead of incremental refactoring?
- How do you change a module that has no tests and no one who understands it?
- How would you refactor a legacy module without downtime for the services that depend on it?
Detail your university thesis or most complex professional project, focusing on your specific architecture dec
Detail your university thesis or most complex professional project, focusing on your specific architecture decisions.
Approach
- Open with the problem and the hard constraint (data volume, latency, hardware, deadline) in two sentences, then sketch the architecture as four or five components and how data moves between them.
- Pick two or three decisions you personally made and give each the same shape: the options, the one chosen, why, and the measurable consequence (for example, PostgreSQL over MongoDB because the data had relations and needed transactions).
- Separate your contribution from the team's or your supervisor's; say "I" for what you built and name what others built.
- Give evidence the design worked: benchmarks, test coverage, accuracy figures or user results, plus one limitation you found and how you would design it differently now.
- Prepare to go a level deeper on every technology you list, since each one is a likely follow-up.
Follow-up
- What would break first if the load or data grew by ten times?
- Why that framework or database instead of the obvious alternative?
- How did you test or validate the result?
What development tools, IDEs, and testing frameworks have you used in recent production environments?
What development tools, IDEs, and testing frameworks have you used in recent production environments?
Approach
- Name the tools you actually used, grouped: IDE (IntelliJ IDEA, VS Code, Eclipse), build (Maven or Gradle, npm, pip or Poetry), version control and CI (Git, pull requests, a pipeline such as GitHub Actions, GitLab CI or Jenkins).
- Testing by layer: unit tests (JUnit 5 with Mockito, pytest, GoogleTest, Jest), integration tests (Spring Boot Test, Testcontainers against a real database instead of an in-memory one with a different SQL dialect), and a few end-to-end tests at the top of the pyramid.
- Quality tooling: coverage (JaCoCo, coverage.py) as a signal, not a goal; static analysis and linters (SonarQube, Checkstyle, ESLint, flake8) run in CI on every pull request.
- Debugging and performance tools: the IDE debugger, a profiler (VisualVM, async-profiler, cProfile), EXPLAIN on slow queries, and log aggregation.
- For each tool, give one reason it was chosen or a problem it caught, and keep the list consistent with your CV and professional profile.
Follow-up
- What is the difference between a mock, a stub and a fake, and when do you use each?
- How do you test code that calls an external API you do not control?
- What coverage target do you set, and why is coverage alone not a quality measure?
Can you explain a complex bug or performance bottleneck you encountered in a previous project and how you reso
Can you explain a complex bug or performance bottleneck you encountered in a previous project and how you resolved it?
Approach
- Tell it as a debugging sequence: the symptom and who saw it, how I reproduced it, the baseline measurement, how I narrowed it down, the root cause, the fix, and the measured result.
- Narrowing tools worth naming: logs with correlation ids, a profiler or flame graph, a heap or thread dump, EXPLAIN ANALYZE for SQL, and git bisect to find the commit that introduced a regression.
- Pick a case with a concrete mechanism, such as an N+1 query in JPA fixed with a JOIN FETCH or entity graph, a missing index found through a sequential scan in the plan, a connection pool exhausted by a leaked connection, or a race that only showed under load.
- Separate root cause from symptom: say what evidence ruled out the first hypothesis, and why the fix addresses the cause rather than raising a timeout.
- End with prevention: a regression test, a metric or alert, and the before/after numbers (for example, p95 latency or memory use).
Follow-up
- How did you prove that was the root cause and not a coincidence?
- What would you have done if the issue only happened in production and not locally?
- What monitoring would have caught it earlier?
Describe a scenario where you had to quickly pick up a new framework or programming language to satisfy projec
Describe a scenario where you had to quickly pick up a new framework or programming language to satisfy project needs.
Approach
- Name the specific framework or language, the deadline and why it was needed, then the learning plan: official documentation and tutorial, then a small throwaway prototype of the exact feature needed.
- Map new concepts onto ones you already know and name the real differences (for example, Spring dependency injection and bean scopes compared with manual wiring, or React hooks compared with class components).
- Learn the codebase's conventions alongside the framework: read existing modules, pair with someone experienced, and take a small ticket first so review feedback arrives early.
- Name one concrete mistake you made while learning (a framework pitfall, not a typo) and how review or tests caught it.
- Give the outcome: when you shipped the first production change, and what you can now explain about the framework's internals.
Follow-up
- What did you get wrong at first, and how did you find out?
- How did you check your code matched the framework's idioms rather than just working?
- If the next project used a stack you have not touched, what would your first week look like?
How do you document your code, requirements, and technical architecture for handoff to client teams?
How do you document your code, requirements, and technical architecture for handoff to client teams?
Approach
- Layer the documentation by reader: a README with setup, build, run and test commands that a newcomer can follow; an architecture overview (C4 context and container diagrams); and runbooks for deployment and common failures.
- Document APIs from the code: OpenAPI generated with springdoc-openapi or FastAPI, with example requests and error responses, so the contract cannot drift from the implementation.
- Record why, not only what: architecture decision records for major choices, and code comments that explain intent or a non-obvious constraint; Javadoc or docstrings on public interfaces.
- Keep requirements traceable: link each requirement id to its tickets, code changes and tests, so the receiving team can see what covers each one.
- Keep documentation in the repository next to the code and review it in the same pull request; finish a handoff with a walkthrough session where the receiving team runs the system from the docs alone.
Follow-up
- How do you stop documentation from going stale after the handoff?
- What does a client team need on day one compared with month three?
- How would you show that every requirement is covered by a test?
Exports duplicate a row range about once a week
Roughly once a week an export writes a file containing a duplicated range of rows. The affected job_run rows show attempt = 1, status = succeeded, one started_at, and a lease_owner naming a different host from the one whose logs show the job starting. Leases last 30 seconds and are heartbeated every 10 from inside the handler; lease_expires_at is computed on the worker and compared against the database's now(). Find the mechanism, and give a fix that holds even if you cannot fix the clocks.
Approach
- Start from the fact that eliminates the obvious answer. attempt = 1 means no retry was recorded, so this is not a re-run after failure; two workers ran the same row concurrently and the takeover path never touched the counter. lease_owner naming a host other than the one that started the job is the same statement from the other side.
- Enumerate the mechanisms that cause a premature takeover, then find the signal that separates them. Either the lease genuinely expired because the heartbeat did not fire, which is what happens when the heartbeat runs on the handler's own thread and the handler makes a long blocking call, or it only appeared expired because two clocks disagree, since lease_expires_at is written from the worker's clock and evaluated against the database's. The discriminator is the distribution: incidents clustered on the longest exports indict the heartbeat, incidents clustered on one host indict skew. Measure both, and measure each host's offset against the database directly.
- Read the reclaim query precisely. In PostgreSQL now() is transaction start time, not statement time, so a reclaimer holding a long transaction compares against an older timestamp than expected; clock_timestamp() is the statement-time function. This is worth ruling in or out before you redesign anything, because it changes which rows look expired.
- Remove the second clock rather than trying to synchronise it. Issue and extend the lease in the database, with lease_expires_at = now() + interval '30 seconds' in both the claim and the heartbeat, so exactly one clock is ever compared and worker skew stops mattering to this predicate.
Follow-up
- The displaced worker has already streamed half the file to object storage. What makes that side effect safe to repeat?
- You now count takeovers. What alert fires on that counter, and at what threshold?
The plan follows the reported rounds: a profile day, the coding game and language fundamentals, backend and data topics, architecture, delivery stories, and a final mock that runs the Business Manager, technical and client conversations. Days point at reported questions by subject and, where useful, at PracHub's separate practice drills.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and audit your profile
- Write the five reported rounds in order and, beside each, the topics candidates report for it and the one you are weakest on.
- Tag every technology on your CV as 'can explain in depth', 'used' or 'leave off', and write the Professional Profile skills section from the first two groups.
- Write your phone-screen answers: salary range, location limits, availability, and your language levels in Spanish and English.
Deliverable: A loop map with your weakest round marked, a tagged skills inventory with a Professional Profile skills section, and a phone-screen answer sheet.
02Coding game: arrays, strings and Big-O
- In your primary language, solve the min-of-first-half and max-of-second-half array problem, then the version with arbitrary sub-array ranges, and write the complexity of each.
- List edge cases (empty, single element, odd length, duplicates, negatives) and test each against your code.
- Work one PracHub coding drill, the one about diffing a projection against the primary, and explain its complexity aloud.
Deliverable: Working solutions for the sub-array problem (single range and many ranges) with a written complexity and edge-case table, plus one solved practice drill.
Practice prompt ↗Practice prompt ↗03OOP and concurrency in your language
- Write a small class hierarchy with overriding in Java or C++, and explain how dispatch works at runtime.
- Write code with a data race on a shared counter, then fix it two ways (a lock or synchronized, and an atomic type).
- Say the OOP principles aloud with one example each, then answer the polymorphism question and the concurrency strategies question as a spoken answer.
Deliverable: A runnable hierarchy example, a race-and-fix program, and two spoken answers (OOP and polymorphism, concurrency strategies).
Practice prompt ↗Practice prompt ↗04Data and API design
- Write a two-scenario answer on relational versus NoSQL, naming the access pattern, consistency and schema needs that decide it.
- Sketch a REST API for asynchronous processing: a request that returns an accepted status with a status resource to poll, idempotency on retries and error codes.
- Practise SQL fundamentals: write queries with INNER, LEFT and self joins, aggregate with GROUP BY and HAVING, then take one slow query, add an index and compare the query plan before and after.
- For window-function practice, work the PracHub drill on version gaps and relay lag, then the drill on adding a tenant column and backfilling it, to prepare for a multi-tenant schema discussion.
Deliverable: A relational-versus-NoSQL answer sheet, an API sketch with status and retry behaviour, a set of join, GROUP BY and indexing exercises with before and after plans, and two solved SQL practice drills.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗05Architecture: microservices, Kafka and legacy code
- Draw a microservices application for Java Spring or Python: service boundaries, a database per service, synchronous versus event-driven calls, and Docker packaging.
- Explain Kafka aloud: topics, partitions, consumer groups, offsets, ordering within a partition and delivery guarantees.
- Write a first-weeks plan for joining a legacy codebase: read tests and logs, map entry points, agree requirements with owners and record architecture trade-offs.
Deliverable: A microservices diagram, a Kafka explanation you can say from memory, and a written legacy-codebase plan.
Practice prompt ↗Practice prompt ↗Practice prompt ↗06Delivery experience: Docker, CI/CD, tools, bugs, documentation
- Write your Docker answer (image build choices, environment promotion) and your CI/CD answer (stages, approval gates, rollback) from real projects.
- List the IDEs, testing frameworks and tools you used recently, with one sentence on why you picked each, and outline a handoff document for a client team.
- Prepare a bug or performance story with the sequence you followed, and rehearse the method on the PracHub debugging drill about duplicated export rows.
Deliverable: Written Docker and CI/CD answers, a tools list with reasons, a handoff document outline and a rehearsed bug story.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗07Project and consulting stories, then a full mock
- Write the thesis or complex-project walkthrough around your own architecture decisions, and a story about picking up a new framework quickly.
- Write STAR outlines for ambiguous requirements, quality against deadlines, an update for non-technical stakeholders and multi-location collaboration, plus the answer to why consulting.
- Run a spoken mock in three parts (Business Manager conversation, technical questions, client conversation) and repeat the weakest part in English.
Deliverable: A project walkthrough, a new-framework story, five STAR outlines and a recorded or written mock with notes on what to fix.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report that the Business Manager and client stages cover soft skills, career goals, fit with projects and fit with a client team. The behavioral prompts for this role centre on consulting: handling unclear or shifting requirements, balancing quality with deadlines, explaining progress to non-technical people and working across locations. Prepare each as a story with your own decision and a result, in Spanish and English.
Describe your experience with containerization using Docker and how you deploy applications across isolated en
Describe your experience with containerization using Docker and how you deploy applications across isolated environments.
Approach
- Choose one service you actually containerised and walk it end to end: the base image and why (a slim or distroless image rather than a full OS image), a multi-stage build that keeps compilers and test tooling out of the final image, a non-root user and a .dockerignore so the build context stays small.
- Explain layer order: copy dependency manifests (pom.xml, requirements.txt, package.json) and install first, then copy source, so a code-only change reuses the cached dependency layer.
- Cover isolated environments: build the image once, tag it by commit SHA and promote that same image through dev, test and production. Environment differences live in variables, mounted config and a secret store, never in rebuilt images or baked-in credentials.
- Say how you ran it: docker compose for the app plus its database or broker locally, health checks, resource limits, and volumes for state that must outlive a container. If Kubernetes was another team's job, say so; the requirements candidates describe list it only as a nice-to-have.
- Close with one problem you debugged, such as a container that exits at startup or works locally but not in the pipeline, and the commands you used (docker logs, docker inspect, a shell inside the container).
Follow-up
- How would you shrink a 1 GB image?
- How do you keep secrets out of the image and its layer history?
- A container works on your laptop but crashes in the test environment. What do you check first?
How do you handle continuous integration and continuous delivery (CI/CD) pipelines in client-driven delivery p
How do you handle continuous integration and continuous delivery (CI/CD) pipelines in client-driven delivery projects?
Approach
- Describe the pipeline as stages you owned: on each pull request, build, unit tests and linting or static analysis; then integration tests against containerised dependencies; then one artifact versioned by commit; then automatic deployment to a test environment.
- Say how production is gated in a client project: a manual approval or a client-controlled release window, with the same artifact promoted rather than rebuilt, and a rollback path (redeploy the previous artifact, blue-green or a feature flag).
- Cover client constraints: when the client owns the infrastructure or tooling, you adapt your jobs to their runners, access rules and restricted networks. Name only tools you have really used.
- Include database changes: backward-compatible migrations (add the column, backfill, switch reads, remove the old column later) so rolling back the application never breaks the schema.
- Anchor the answer in one measured improvement, for example a flaky suite quarantined or jobs run in parallel, and give the number that changed.
Follow-up
- The pipeline is red on release day and the client wants the build shipped. What do you do?
- How do you deal with flaky tests?
- How do you roll back a release that included a schema migration?
How do you handle situations where client requirements are ambiguous or change mid-sprint?
How do you handle situations where client requirements are ambiguous or change mid-sprint?
Approach
- Open with a specific story: a requirement that was vague, or reversed after sprint planning. State the situation in two sentences and the cost of guessing wrong.
- Show your first move: ask targeted questions of whoever owns the requirement (client contact, product owner or Business Manager), write down the assumption you will build on, and get it confirmed in writing before going further.
- Show how you contained the change: split the work into the smallest slice that stays correct under either answer, demo a working increment early, and make the trade-off explicit, including what leaves the sprint for the new item to enter.
- State the outcome and the process fix, such as acceptance criteria written per story and a change log, so the next change arrives as a priced request rather than a surprise.
- Avoid the stories that sink this answer: silently absorbing the change and missing the date, or building on an unconfirmed guess and reworking it.
Follow-up
- The client changes the same requirement a third time. What do you change about your process?
- How do you tell a client that a change will move the delivery date?
- What if the new request contradicts the agreed specification?
Describe a time when you had to balance strict technical quality standards against tight delivery deadlines.
Describe a time when you had to balance strict technical quality standards against tight delivery deadlines.
Approach
- Choose a case with real tension and name both sides: the quality standard at stake (test coverage on the core path, code review, error handling, a security check) and the deadline with its consequence.
- Show the decision, not just the outcome: which part of the standard was non-negotiable and why (anything that loses data or is hard to fix after release), and which part you consciously deferred.
- Describe how you negotiated scope rather than silently cutting quality: you offered the client two options with dates, dropped a feature instead of tests, or released behind a flag.
- Record the deferral: a ticket with an owner and a date, and say whether the debt was repaid. A story without follow-through sounds like corner cutting.
- Close with the result and a rule you now apply, for example a minimum bar for merging that you suggested to the team.
Follow-up
- What exactly did you cut, and what would have happened if it had failed?
- Did the deferred work ever get done?
- What if the client had insisted on skipping code review entirely?
How do you present technical concepts and progress updates to non-technical stakeholders or client managers?
How do you present technical concepts and progress updates to non-technical stakeholders or client managers?
Approach
- Lead with the decision or status the listener needs, then the reason: 'I recommend dropping reporting from this sprint so the release date holds', before any mechanism.
- Translate mechanisms into consequences: instead of 'the message queue backs up', say 'orders can arrive late during peaks'. Use at most one analogy.
- Report progress as done, in progress, blocked and at risk, each with a date or a named dependency, rather than loose percentages.
- Offer two or three options with cost, risk and your recommendation, then check understanding by asking the listener what they will decide.
- Support it with a real example where a stakeholder chose differently because of how you framed the issue, and mention that you can give the same update in Spanish and English if the audience is mixed.
Follow-up
- A manager wants a firm date for a task with unknown complexity. What do you say?
- How do you report a slip without losing client confidence?
- Explain one concept from your last project, such as eventual consistency, to someone non-technical.
Why do you want to work for Alten Delivery Centre Spain as a technology consultant rather than at a traditiona
Why do you want to work for Alten Delivery Centre Spain as a technology consultant rather than at a traditional product company?
Approach
- This is a motivation answer, not a STAR story. Build it in three short parts: what attracts you to consulting work, evidence from your own history, and the trade-off you accept.
- Attraction: breadth. Candidates describe projects across automotive, aerospace, banking and telecommunications with stacks that change by client. Tie that to a moment when changing stack or domain taught you more than staying put.
- Evidence: cite a time you learned a framework or language quickly, a client or stakeholder interaction you handled well, or thesis and academic projects if you are a recent graduate.
- Trade-off: say honestly that you will own one product for less time than at a product company, and why that suits you, for example you enjoy delivering and handing over cleanly.
- Avoid criticising product companies or reciting generic ambition. Mention only company facts candidates report: client projects, a delivery centre, the Professional Profile and the Business Manager relationship.
Follow-up
- What would you miss about working on a single product?
- Which client domain would you most want to work in, and why?
- How would you react to being assigned a stack you did not choose?
How do you maintain productive team collaboration when working across hybrid or multi-location delivery center
How do you maintain productive team collaboration when working across hybrid or multi-location delivery centers?
Approach
- Name concrete mechanisms: written-first communication (a decision log, pull request descriptions that explain why), agreed overlapping hours, a shared definition of done, and short stand-ups with notes for anyone who misses them.
- Describe how you remove ambiguity across sites: move to a call once a chat thread has gone back and forth more than twice, then post a written summary of what was agreed.
- Cover handoffs: documented module ownership, runbooks and architecture notes, so work that moves between locations does not depend on one person's memory.
- Tell one story: duplicated work, merge conflicts or a missed dependency between two locations, what you changed and the evidence it helped, such as fewer conflicts or faster reviews.
- Cover the client side: how client managers see progress across locations, and how you handle time zones and language norms.
Follow-up
- A teammate at another site is unresponsive and blocks your task. What do you do?
- How do you onboard someone who joins remotely?
- How do you keep review quality when authors and reviewers are in different locations?
- 01
How do you handle situations where client requirements are ambiguous or change mid-sprint?
- 02
Describe a time when you had to balance strict technical quality standards against tight delivery deadlines.
- 03
How do you present technical concepts and progress updates to non-technical stakeholders or client managers?
- 04
Why do you want to work for Alten Delivery Centre Spain as a technology consultant rather than at a traditional product company?
- 05
How do you maintain productive team collaboration when working across hybrid or multi-location delivery centers?
- 06
Describe a scenario where you had to quickly pick up a new framework or programming language to satisfy project needs.
How technical is the Alten Delivery Centre Spain interview process?
Candidates report technical content in three places: an online coding game on your main language followed by a technical interview, a deeper interview with a Tech Lead or Engineering Manager, and a client interview about the client's stack. Depth varies with the team and client. Prepare OOP, data structures, basic algorithms with Big-O, SQL, and one backend stack story.
Alten Delivery Centre Spain Software Engineer candidate reports ↗What is the Professional Profile (dossier de competences)?
Candidates describe it as a standard CV-style template summarising skills, education and project experience, completed early so Business Managers can present you to delivery leads or client projects. List only technologies you can explain in depth, since the same profile can shape the later technical conversations.
Alten Delivery Centre Spain Software Engineer candidate reports ↗How long does the process take?
Candidates report five rounds over roughly 4-6 weeks, with the gap between stages depending on client project schedules and delivery-centre demand. Ask the recruiter in the phone screening what the next stages are and when to expect them.
Alten Delivery Centre Spain Software Engineer candidate reports ↗Is hybrid or remote work available?
Candidates report that hybrid arrangements are common across delivery projects, with the details depending on the client's requirements and security rules. Ask about the arrangement for your specific assignment in the early calls, and prepare for the reported question about collaborating across multi-location teams.
Alten Delivery Centre Spain Software Engineer candidate reports ↗Which programming language should I prepare?
The requirements candidates describe list at least one primary language from Java, C++, Python, C# or JavaScript/TypeScript, plus SQL, OOP and Git. Reported questions mention polymorphism in C++ or Java and microservices in Java Spring or Python. Use your strongest language for the coding game and know two or three of its internals well enough to explain them.
Alten Delivery Centre Spain Software Engineer candidate reports ↗I am a recent graduate. How should I prepare differently?
According to candidates, graduate applicants are judged mostly on the quality of their thesis work, their grasp of computer science basics and their interest in a consulting career, with less weight on professional framework use. Prepare a thesis or project walkthrough covering your design decisions and results, revise data structures and OOP, and be ready to explain why consulting appeals to you.
PracHub Software Engineer practice ↗Do I need Spanish and English?
The requirements candidates describe list fluency in Spanish and working proficiency in English, and the phone screening is reported to cover language skills. Rehearse your CV walkthrough and two project stories in both languages, and practise explaining a technical choice simply in each.
Alten Delivery Centre Spain Software Engineer candidate reports ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01Alten Delivery Centre Spain Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Zoom Video Communications Software Engineer Interview Guide
What Zoom Video Communications asks Software Engineer candidates, from reported rounds and questions.
Wizeline Software Engineer Interview Guide
What Wizeline asks Software Engineer candidates, from reported rounds and questions.
W.W. Grainger Software Engineer Interview Guide
What W.W. Grainger asks Software Engineer candidates, from reported rounds and questions.
Unify Software Engineer Interview Guide
What Unify asks Software Engineer candidates, from reported rounds and questions.