As a Software Engineer at Scalable Capital, you will play a critical role in building and scaling one of Europe's leading neo-brokers and digital wealth management platforms. The engineering team is responsible for developing highly secure, low-latency, and resilient financial systems that manage billions of euros in assets. Your work will directly impact over a million users who rely on the platform for trading stocks, ETFs, cryptocurrencies, and managing automated investment portfolios. The technical landscape here is both challenging and rewarding. You will work on complex distributed systems, real-time transaction processing, and cloud-native architectures that must handle massive traffic spikes during market volatility. Whether you are optimizing order execution pipelines, building intuitive frontend interfaces in React, or designing robust microservices, your contributions will maintain the high standards of security, compliance, and performance that define Scalable Capital. Engineering at Scalable Capital is highly collaborative but demands a strong sense of ownership. You will collaborate closely with product managers, security specialists, and site reliability engineers to design and deploy features continuously. The company values engineers who are not only technically proficient but also deeply curious about financial markets, user experience, and modern software design patterns.
Automated Coding Assessment
reportedCandidates begin with an automated coding assessment to evaluate baseline technical proficiency.
What to demonstrate
- Candidates begin with an automated coding assessment to evaluate baseline technical proficiency
- Depth in Backend API design (endpoints/controllers)
How to prepare
- Answer aloud and timed: Explain how a
ConcurrentHashMapworks internally in Java. How does it achieve thread safety without locking the entire map? - Answer aloud and timed: What is the difference between optimistic and pessimistic locking? In what scenarios would you choose one over the other in a trading environment?
Interactive Technical Rounds
reportedCandidates engage in deeper, interactive technical discussions with engineering leadership.
What to demonstrate
- Candidates engage in deeper, interactive technical discussions with engineering leadership
- Depth in Backend API design (endpoints/controllers)
How to prepare
- Answer aloud and timed: How do you use atomic variables like
AtomicIntegerto build thread-safe operations? - Answer aloud and timed: What are the main differences between processes and threads, and how does your language of choice handle multithreading?
Behavioral Assessment
reportedBehavioral assessments are conducted to evaluate cultural fit and collaboration skills.
What to demonstrate
- Behavioral assessments are conducted to evaluate cultural fit and collaboration skills
- Depth in Backend API design (endpoints/controllers)
How to prepare
- Prepare three examples from your own work, each with a decision you made and an outcome you can quantify.
- Re-read the description of the behavioral assessment above and write down what you would ask to confirm before it.
Final Offer Discussion
reportedCandidates receive a final offer discussion after successfully completing previous steps.
What to demonstrate
- Candidates receive a final offer discussion after successfully completing previous steps
- Depth in Backend API design (endpoints/controllers)
How to prepare
- Answer aloud and timed: How would you design a database indexing strategy for a high-frequency transaction table to ensure fast lookups without degrading write performance?
- Answer aloud and timed: If you were building a microservices-based trading system, how would you handle distributed transactions and data consistency across services?
PracHub editorial advice for the preparation topics above.
Master Concurrency Fundamentals
Be ready to discuss thread safety, locking mechanisms, and concurrent collections in detail. Interviewers frequently ask about how these concepts apply to financial ledger balances and order execution.
Test Your Code Thoroughly
Whether on Codility or in a take-home task, do not submit your code without writing robust unit tests. Ensure you handle edge cases, null inputs, and unexpected data formats.
Clarify API Requirements Early
During system design or coding interviews, do not make assumptions. Ask clarifying questions about expected scale, read-to-write ratios, and specific business constraints before you start designing or coding.
When completing automated coding tasks, pay close attention to the execution time and memory limits
Writing a working solution that fails to scale under load is a common reason for early-stage rejection.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain how a `ConcurrentHashMap` works internally in Java. How does it achieve thread safety without locking
Explain how a ConcurrentHashMap works internally in Java. How does it achieve thread safety without locking the entire map?
Approach
- Say what the runtime actually does before reasoning about the code.
- Name what is shared across threads and what owns each piece of state.
- Identify the window where an invariant is briefly untrue.
- Distinguish a value from a reference to it, and say which one you handed out.
Follow-up
- What happens if two callers reach this at the same time?
- Where could this allocate more than you expect?
What is the difference between optimistic and pessimistic locking? In what scenarios would you choose one over
What is the difference between optimistic and pessimistic locking? In what scenarios would you choose one over the other in a trading environment?
Approach
- Say what the runtime actually does before reasoning about the code.
- Name what is shared across threads and what owns each piece of state.
- Identify the window where an invariant is briefly untrue.
- Distinguish a value from a reference to it, and say which one you handed out.
Follow-up
- What happens if two callers reach this at the same time?
- Where could this allocate more than you expect?
How do you use atomic variables like `AtomicInteger` to build thread-safe operations?
How do you use atomic variables like AtomicInteger to build thread-safe operations?
Approach
- Say what the runtime actually does before reasoning about the code.
- Name what is shared across threads and what owns each piece of state.
- Identify the window where an invariant is briefly untrue.
- Distinguish a value from a reference to it, and say which one you handed out.
Follow-up
- What happens if two callers reach this at the same time?
- Where could this allocate more than you expect?
What are the main differences between processes and threads, and how does your language of choice handle multi
What are the main differences between processes and threads, and how does your language of choice handle multithreading?
Approach
- Say what the runtime actually does before reasoning about the code.
- Name what is shared across threads and what owns each piece of state.
- Identify the window where an invariant is briefly untrue.
- Distinguish a value from a reference to it, and say which one you handed out.
Follow-up
- What happens if two callers reach this at the same time?
- Where could this allocate more than you expect?
How do you prevent race conditions when two concurrent requests attempt to update a user's account balance at
How do you prevent race conditions when two concurrent requests attempt to update a user's account balance at the same time?
Approach
- Say what the runtime actually does before reasoning about the code.
- Name what is shared across threads and what owns each piece of state.
- Identify the window where an invariant is briefly untrue.
- Distinguish a value from a reference to it, and say which one you handed out.
Follow-up
- What happens if two callers reach this at the same time?
- Where could this allocate more than you expect?
Walk me through your implementation of the take-home task. Why did you choose this specific data structure to
Walk me through your implementation of the take-home task. Why did you choose this specific data structure to model the order book?
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- Name the brute-force solution and its complexity before improving on it.
- Choose the data structure from the access pattern, not from familiarity.
- State the target complexity and say which constraint rules the naive version out.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
Review this React component: identify potential performance bottlenecks, such as improper usage of `useCallbac
Review this React component: identify potential performance bottlenecks, such as improper usage of useCallback or side effects inside useEffect.
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- Name the brute-force solution and its complexity before improving on it.
- Choose the data structure from the access pattern, not from familiarity.
- State the target complexity and say which constraint rules the naive version out.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
Write a function to parse a string input representing financial transactions and calculate the final net balan
Write a function to parse a string input representing financial transactions and calculate the final net balance, handling decimal precision errors.
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- Name the brute-force solution and its complexity before improving on it.
- Choose the data structure from the access pattern, not from familiarity.
- State the target complexity and say which constraint rules the naive version out.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
What are some common code smells you look for during a pull request review, particularly regarding error handl
What are some common code smells you look for during a pull request review, particularly regarding error handling and resource cleanup?
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- Name the brute-force solution and its complexity before improving on it.
- Choose the data structure from the access pattern, not from familiarity.
- State the target complexity and say which constraint rules the naive version out.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
Write the update path that detects a concurrent edit
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
- 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.
- 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.
- 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.
- 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?
Explain why the owner filter ignores the listing index
The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.
Approach
- Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
- For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
- Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
- Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.
Follow-up
- 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
- A dashboard runs this for 40 owners in one page load. What changes about the design?
Design a simplified REST API for an order management system. What endpoints would you expose for creating, ret
Design a simplified REST API for an order management system. What endpoints would you expose for creating, retrieving, and canceling orders?
Approach
- Say who the caller is and what they do when the call fails halfway.
- Define the identity of a request so a retry cannot double-apply it.
- Separate accepted, pending, failed and confirmed; they are different facts.
- Design the error taxonomy before the success shape; callers branch on it.
Follow-up
- What happens if the caller retries after a timeout?
- How does a client discover it is on an old version of this contract?
How would you design a database indexing strategy for a high-frequency transaction table to ensure fast lookup
How would you design a database indexing strategy for a high-frequency transaction table to ensure fast lookups without degrading write performance?
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Choose a partition key and say what query it makes expensive.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What breaks first when traffic grows ten times?
- How does this behave when that dependency is down for an hour?
If you were building a microservices-based trading system, how would you handle distributed transactions and d
If you were building a microservices-based trading system, how would you handle distributed transactions and data consistency across services?
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Choose a partition key and say what query it makes expensive.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What breaks first when traffic grows ten times?
- How does this behave when that dependency is down for an hour?
How do serverless solutions like AWS Lambda compare to containerized solutions on AWS Fargate in terms of cold
How do serverless solutions like AWS Lambda compare to containerized solutions on AWS Fargate in terms of cold starts, scaling, and cost efficiency?
Approach
- Say who the caller is and what they do when the call fails halfway.
- Define the identity of a request so a retry cannot double-apply it.
- Separate accepted, pending, failed and confirmed; they are different facts.
- Design the error taxonomy before the success shape; callers branch on it.
Follow-up
- What happens if the caller retries after a timeout?
- How does a client discover it is on an old version of this contract?
How would you structure a CI/CD pipeline for a critical financial service to guarantee zero-downtime deploymen
How would you structure a CI/CD pipeline for a critical financial service to guarantee zero-downtime deployments?
Approach
- Say who the caller is and what they do when the call fails halfway.
- Define the identity of a request so a retry cannot double-apply it.
- Separate accepted, pending, failed and confirmed; they are different facts.
- Design the error taxonomy before the success shape; callers branch on it.
Follow-up
- What happens if the caller retries after a timeout?
- How does a client discover it is on an old version of this contract?
Why do you want to work at Scalable Capital, and how do you keep yourself updated on the latest trends in fint
Why do you want to work at Scalable Capital, and how do you keep yourself updated on the latest trends in fintech and software engineering?
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Choose a partition key and say what query it makes expensive.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What breaks first when traffic grows ten times?
- How does this behave when that dependency is down for an hour?
One customer endpoint stalls deliveries to every other destination
The egress service delivers about 1.5k webhooks/second across 40,000 destinations, with a per-destination concurrency cap of 4 and a 10-second connect-plus-read timeout. Throughput falls to 300/second, queue depth climbs, and p99 delivery latency for unaffected destinations goes from 200 ms to minutes, while the error rate barely moves. One tenant holds 900 destination rows whose URLs share a hostname that now answers in 9.5 seconds. Explain the mechanism with the arithmetic, then give the containment in the order you would apply it.
Approach
- Look at saturation before errors. A flat error rate with collapsing throughput says nothing is failing, things are waiting, so the first signal to pull is in-flight request count or pool wait time rather than the error counter. This is the distinction that decides the whole investigation.
- Group in-flight work by resolved host, not by destination id. The cap is keyed per destination row, so 900 rows sharing one hostname buy 3,600 concurrent slots against a single host, each held for 9.5 seconds. The bulkhead was never a bulkhead for that host, and grouping by the wrong dimension is why the dashboard looked healthy.
- Do the arithmetic in both directions. Required concurrency is arrival rate times latency, so 1.5k/second at 200 ms needs about 300 in flight, which is entirely consumed by 3,600 slow slots; conversely whatever concurrency is left sustains rate equals concurrency divided by 9.5 seconds, which is the 300/second you are seeing. Matching both numbers is what promotes this from a plausible story to the mechanism.
- Explain why the circuit breaker never helped. It opens on consecutive failures, and a 9.5-second response inside a 10-second timeout is a success. Slow is not failing, so an error-rate breaker cannot see this; you need a slow-call ratio, a deadline propagated from the caller's remaining budget, or a concurrency limiter.
Follow-up
- The host recovers to 80 ms. How long does the queue take to drain, and what does the drain do to the recovered host?
- Where should the 10-second timeout number actually come from?
Built from the rounds and topics Scalable Capital candidates report.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the Scalable Capital loop
- Write out the reported sequence: Automated Coding Assessment, Interactive Technical Rounds, Behavioral Assessment, Final Offer Discussion.
- For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.
Deliverable: A one-page map of the 4 reported rounds, with the weakest marked.
02Work Backend API design (endpoints/controllers)
- Spend the session on Backend API design (endpoints/controllers), which Scalable Capital candidates report being tested on.
- Write one worked example in Backend API design (endpoints/controllers) and time yourself on it.
Deliverable: One timed worked example in Backend API design (endpoints/controllers).
03Work Infrastructure as Code (Terraform)
- Spend the session on Infrastructure as Code (Terraform), which Scalable Capital candidates report being tested on.
- Write one worked example in Infrastructure as Code (Terraform) and time yourself on it.
Deliverable: One timed worked example in Infrastructure as Code (Terraform).
04Work Programming in Python (core language)
- Spend the session on Programming in Python (core language), which Scalable Capital candidates report being tested on.
- Write one worked example in Programming in Python (core language) and time yourself on it.
Deliverable: One timed worked example in Programming in Python (core language).
05Answer out loud: Backend & Concurrency
- Answer aloud, timed: Explain how a `ConcurrentHashMap` works internally in Java. How does it achieve thread safety without locking the entire map?
- Answer aloud, timed: What is the difference between optimistic and pessimistic locking? In what scenarios would you choose one over the other in a trading environment?
Deliverable: Spoken answers to 2 reported Backend & Concurrency question(s), under time.
06Answer out loud: API & System Design
- Answer aloud, timed: Design a simplified REST API for an order management system. What endpoints would you expose for creating, retrieving, and canceling orders?
- Answer aloud, timed: How would you design a database indexing strategy for a high-frequency transaction table to ensure fast lookups without degrading write performance?
Deliverable: Spoken answers to 2 reported API & System Design question(s), under time.
07Answer out loud: Coding & Technical Review
- Answer aloud, timed: Walk me through your implementation of the take-home task. Why did you choose this specific data structure to model the order book?
- Answer aloud, timed: Review this React component: identify potential performance bottlenecks, such as improper usage of `useCallback` or side effects inside `useEffect`.
Deliverable: Spoken answers to 2 reported Coding & Technical Review question(s), under time.
Expand any day for tasks and deliverables. Your progress is saved on this device.
Behavioural rounds judge the decision you made and what it cost.
Tell me about a time when you had to make a technical compromise to meet a tight business deadline. What was t
Tell me about a time when you had to make a technical compromise to meet a tight business deadline. What was the impact, and how did you manage it?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
How do you handle a situation where you disagree with a senior engineer or architect on a design decision?
How do you handle a situation where you disagree with a senior engineer or architect on a design decision?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
Describe a challenging bug you encountered in production. How did you diagnose it, and what steps did you take
Describe a challenging bug you encountered in production. How did you diagnose it, and what steps did you take to prevent it from happening again?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
- 01
Tell me about a time when you had to make a technical compromise to meet a tight business deadline. What was the impact, and how did you manage it?
- 02
How do you handle a situation where you disagree with a senior engineer or architect on a design decision?
- 03
Describe a challenging bug you encountered in production. How did you diagnose it, and what steps did you take to prevent it from happening again?
How technical is the initial screening interview?
The initial interview is a mix of behavioral questions and high-level technical concepts. While you won't be writing code live, you should be prepared to explain your past projects, technical choices, and basic concepts related to your core stack.
Scalable Capital Software Engineer candidate reports ↗What is the policy on remote and hybrid work?
Scalable Capital offers flexible hybrid working models depending on the office location (such as Munich, Berlin, or London) and the specific team. During the recruiting process, clarify the expectations for your target team, as policies can vary.
Scalable Capital Software Engineer candidate reports ↗How important is domain knowledge in finance or trading?
While prior experience in fintech or trading is a strong plus, it is not a strict requirement. The company values core engineering excellence, problem-solving skills, and a willingness to learn complex financial domains quickly.
Scalable Capital Software Engineer candidate reports ↗What is the typical timeline from the first interview to an offer?
The entire process usually takes between three to five weeks. This timeline depends on your availability for scheduling interviews and the speed at which you complete the take-home or coding assessments.
Scalable Capital Software Engineer candidate reports ↗Do I get feedback if I am rejected after a technical round?
Due to the high volume of applications, detailed, personalized feedback is not always guaranteed, particularly in the early automated stages. However, for late-stage technical and architectural rounds, the hiring team strives to provide constructive takeaways whenever possible.
Scalable Capital Software Engineer candidate reports ↗What topics does Scalable Capital test in interviews?
Scalable Capital interviews most often cover System Design, Problem Solving, Automated Testing, UX/UI Design, and Android. The exact emphasis depends on the specific role you apply for.
Scalable Capital 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.
- 01Scalable Capital 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.
SynergisticIT Software Engineer Interview Guide
What SynergisticIT asks Software Engineer candidates, from reported rounds and questions.
Smart Energy Water Software Engineer Interview Guide
What Smart Energy Water asks Software Engineer candidates, from reported rounds and questions.
S&P Global Software Engineer Interview Guide
What S&P Global asks Software Engineer candidates, from reported rounds and questions.
Robert Half Software Engineer Interview Guide
What Robert Half asks Software Engineer candidates, from reported rounds and questions.