Interview guides · Chartered Investment

Chartered Investment Software Engineer Interview Guide

Chartered Investment Software Engineer interview guide: three reported rounds, cloud, Kubernetes and Terraform design prep, and behavioral stories.

The 60-second brief

Chartered Investment is a financial firm, and the Software Engineer role described by candidates sits in the technology that supports its investment work. Reported areas include cloud infrastructure, algorithms used for investment analysis and AI-driven functionality. Candidates also report that industry topics such as ESG and carbon footprint reporting can come up, depending on the team. Beyond those areas, little is published about specific products or systems, so treat the stack named in this guide (AWS, Azure, Docker, Kubernetes, Terraform, and a mainstream language such as Java, Python, C++ or Go) as what to prepare against, and avoid guessing at internal systems.

This guide is for candidates interviewing for the Software Engineer role at Chartered Investment. It covers the three reported stages (Recruiter Screen, Technical Rounds, Managerial Discussions), the ten questions candidates report (four on design and architecture, one of them a walk-through of a hard technical problem, and the rest behavioral or experience-based), and the stack candidates describe for the role.

Candidates report three stages over about 3-5 weeks: a Recruiter Screen, Technical Rounds and Managerial Discussions. Timing is described as varying by team and location.

Focus areas

Infrastructure as Code (Terraform)
Container Orchestration (Kubernetes)
Cloud Computing (AWS)

Overview

The role as candidates describe it mixes hands-on coding with participation in architectural design, and it involves working alongside other engineers, product managers and sometimes risk or operations teams. That combination shapes the loop: you need working code with sound complexity, a clear view of how a system behaves under load and failure, and the ability to explain your own past decisions in plain language.

The reported technical themes are cloud platforms (AWS and Azure), containers and orchestration (Docker and Kubernetes), and infrastructure as code with Terraform. Reported design topics include handling high-frequency data updates and choosing between database architectures for a new service, and candidates also mention failure handling, disaster recovery and security-first architecture in a financial setting. For each of these, prepare a first-hand example from your own work, because you may be asked about every line of your resume, and the reasons behind your choices matter as much as the choices.

Coding preparation centres on data structures and algorithms, complexity analysis, design patterns, testing and code review practice. Candidates quote example prompts about optimising search and retrieval over a dataset and writing a function that stays correct under concurrent access, so rehearse stating complexity aloud and adding a thread-safe variant in the language you will use.

The behavioral side is substantial. Candidates report prompts about explaining a technical issue to a non-technical person, disagreeing with a colleague's technical direction, adapting to shifting priorities, why you are drawn to finance and software, and how you keep up with ESG and AI. Build a small bank of stories in the situation, task, action, result shape and make sure each one shows you collaborating rather than winning an argument; candidates describe teamwork as important here.

The Chartered Investment interview process

Candidates describe three stages, from a recruiter screen through technical rounds to conversations with management. The stages below are what candidates report, not a published process, and details vary by team.

Recruiter Screen

The first stage is a recruiter screen. Candidates describe it as an initial conversation about your background and high-level fit for the role. Nothing more specific is reported about its format, so prepare a clear account of your career and the reasons behind it. Use it to confirm which stages follow for your team, since candidates say the process varies by team and location.

What to demonstrate

Your background and how it lines up with a Software Engineer role
High-level fit for the position
How clearly you can describe past work to a non-engineer

How to prepare

Write a concise walk through your career that ends on the cloud, container or infrastructure-as-code work you have genuinely done, naming only technologies you can discuss in depth.
Prepare a short, honest answer on why you want to combine finance and software engineering, built on a real project rather than a slogan.
Have logistics ready: location, availability and any constraints, and ask what the next stages look like for this team.
Write down the two or three resume lines you expect to be asked about and the reasoning behind each decision you made.

Technical Rounds

The technical stage is reported as deep-dive interviews on problem-solving and coding. Candidates describe two areas: data structures and algorithms (complexity, design patterns, testing and code review practice, with prompts such as optimising search over a dataset or writing a function that is thread safe) and system architecture (AWS and Azure services, Docker and Kubernetes, Terraform, failure handling and disaster recovery, security in a financial environment). Plan to code while speaking your reasoning aloud, because candidates report that thinking out loud is encouraged when you are stuck.

What to demonstrate

Working code with correct time and space complexity
Practical use of design patterns, testing and code review habits
Architecture reasoning across cloud, containers and infrastructure as code
Handling of failure, disaster recovery and security in a financial setting

How to prepare

Rehearse the reported design questions: a system for high-frequency data updates (ingest, ordering, idempotent writes, backpressure) and choosing a database architecture for a new service (access patterns, consistency, growth).
Be able to describe how you use Docker, Kubernetes and Terraform: probes, resource limits, rollout strategy, state handling and plan versus apply.
Practise explaining how your design survives a zone outage and where secrets and access control live.

Managerial Discussions

The final stage is reported as conversations with management, aimed at alignment with team culture and your project experience. Candidates say behavioral questions deserve serious preparation, and the reported prompts cover technical communication, disagreement, shifting priorities and motivation for finance. Expect to go deep on projects: what you built, why you picked those tools and what changed as a result.

What to demonstrate

Alignment with team culture, as candidates describe the stage
Depth of understanding of your own past projects and architectural choices
Collaboration, handling of ambiguity and clear communication

How to prepare

Prepare a project deep dive for your two strongest systems: the problem, the options you rejected, the decision, the outcome and what you would change.
Build a story bank in situation, task, action, result form and map each story to the reported behavioral prompts, including disagreement, shifting priorities and explaining a technical issue to a non-technical person.
Prepare a walk-through of one genuinely hard technical problem, with the debugging or design steps in order.
Write questions for the managers about engineering culture, the team's current challenges and how technical debt is managed.

Where candidates lose points

Listing AWS and Azure services without saying why you chose them

For each service you mention, prepare the alternative you rejected, the trade-off and one thing you measured. If you only know one cloud, say so and map the concepts instead of bluffing.

Listing Kubernetes or Terraform on your resume and then being unable to explain how you used them

Candidates report that every resume line is fair game. Rehearse specifics: readiness and liveness probes, resource limits, rolling updates, Terraform state, plan versus apply, and one failure you debugged.

Starting the high-frequency data design with boxes and arrows before asking about load, ordering and consistency

Ask for the write rate, whether per-key ordering matters and how stale a read may be. Then cover ingest, backpressure, idempotent writes, failure recovery and where security controls sit, as the reported architecture topics suggest.

Telling a disagreement story in which you are right and the colleague is wrong

Present the other position fairly, show the criteria and evidence you used, and describe an outcome where the team moved forward together. Candidates report that team orientation counts and that coming across as overly competitive hurts.

Going quiet when stuck in a coding problem, or ignoring concurrency and complexity

Say your approach aloud, state time and space complexity before you are asked, and ask whether the function may be called from several threads so you can add a lock or a concurrent structure.

Questions & practice

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

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

Approach

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?

Stop tag and share joins from fanning out a page

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

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

Approach

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

Follow-up

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

How would you design a scalable system to handle high-frequency data updates?

Medium · Technical and Architectural Proficiency

Approach

Pin down the numbers before drawing anything: updates per second at peak, how many distinct keys, payload size, read fan-out, and whether readers need every update or only the latest value per key. The answer to that last question decides whether you can conflate updates.
Ingest through a partitioned, append-only log (Kafka, Kinesis or Event Hubs) keyed by entity id. Ordering is guaranteed only within a partition, so keying by entity gives per-entity order. Partition count caps how many consumers in one group can work in parallel, so size it for peak, not average.
Make consumers idempotent. At-least-once delivery means duplicates will arrive, so carry a per-key sequence number or version and apply an update only if it is newer than the stored one. This handles retries and late or out-of-order messages in one rule.
Split the storage paths: a latest-state store (an in-memory cache or a key-value table, written with a conditional update on version) for low-latency reads, and an append-only time-series or columnar store for history and analytics. Push to subscribers through pub/sub or WebSockets, and coalesce to the latest value per key when a client falls behind.
Name the trade-offs and failure modes: a hot key overloads one partition, consumer lag grows silently unless you alert on it, and strong consistency on every write costs throughput. Say where staleness is acceptable (dashboards) and where it is not (anything that drives a decision on current state).

Follow-up

One key gets a hundred times the traffic of the others. How do you keep its partition from becoming the bottleneck?
A consumer crashes after writing to the database but before committing its offset. What happens on restart, and how does your design stay correct?
How would you replay a day of updates to rebuild the latest-state store after a bad deploy corrupted it?

What is your approach to choosing between different database architectures for a new service?

Medium · Technical and Architectural Proficiency

Approach

Start from the access patterns and invariants, not the product names: list the top reads and writes with their rates, which operations must be atomic across rows, the expected data size in a year, and which queries are ad hoc or analytical.
Map those to families: a relational database when you need multi-row transactions, joins and enforced constraints; a key-value or wide-column store when access is by known key at very high write volume; a document store when records are self-contained and the schema changes often; a time-series or columnar store for append-heavy timestamped data and aggregations over large scans.
State the consistency requirement explicitly. Read replicas scale reads but add replication lag, which breaks read-your-own-writes unless you route those reads to the primary. Under a network partition a distributed store must choose between consistency and availability, and even without one it trades latency against consistency.
Treat sharding as a cost, not a default: choose the shard key from the dominant query, and say which queries become cross-shard scatter-gather. Keep reporting off the transactional database by streaming changes (change data capture) into a warehouse.
Close with operations: managed service versus self-hosted, backups and point-in-time recovery, schema migration strategy, encryption and audit requirements. A reasonable default is a relational database until a measured requirement rules it out, and you should say what measurement would make you switch.

Follow-up

Six months in, the analytics team runs heavy queries that slow down the service. What do you change?
How would you migrate this service from one database to another without downtime?
Your read replica serves a user a balance that does not include the write they just made. How do you fix that?

How do you integrate Kubernetes into your development workflow to ensure service reliability?

Medium · Technical and Architectural Proficiency

Approach

Separate the three probes and say why: a readiness probe failing removes the pod from the Service endpoints so it gets no traffic; a liveness probe failing restarts the container; a startup probe holds off the other two while a slow service boots. Keep liveness checks local, because a liveness check that calls the database restarts every pod when the database blips.
Set resource requests and limits deliberately: requests drive scheduling, a container over its memory limit is OOMKilled, and a CPU limit causes throttling rather than a kill. Add a HorizontalPodAutoscaler on CPU or a custom metric only after requests are realistic, since its utilisation targets are computed against requests.
Make deploys safe: a Deployment rolling update with maxUnavailable and maxSurge tuned, several replicas spread across nodes or zones with topology spread constraints or anti-affinity, and a PodDisruptionBudget so node drains cannot take every replica at once. Roll back with kubectl rollout undo or by reverting the manifest in Git.
Handle shutdown: on termination the pod receives SIGTERM, then SIGKILL after terminationGracePeriodSeconds (30 seconds by default). The app should stop accepting new work, finish in-flight requests and exit; a short preStop sleep covers the window before endpoints update.
Tie it to the workflow: build one immutable image in CI, keep manifests in Git (Helm or Kustomize), run the same manifests locally with kind or minikube, provision the cluster itself with Terraform, and promote the same image from staging to production rather than rebuilding it.

Follow-up

A pod is in CrashLoopBackOff. Walk through how you find the cause.
Your rolling deploy includes a database schema change. How do you keep old and new pods working at the same time?
Traffic doubles in a minute and the autoscaler is too slow. What do you look at?

Can you walk us through a complex technical challenge you faced and how you resolved it?

Medium · Technical and Architectural Proficiency

Approach

Choose a problem where you personally made the diagnosis or the design call and the root cause was technical: a race condition, a memory leak, a slow query, a data inconsistency, a scaling limit. Tell it in the first person singular; a story told as a team effort hides what you did.
Open with the symptom and its impact in two sentences, with a number if you have one (error rate, latency, records affected), then spend most of the answer on how you narrowed it down: the hypotheses, the measurement that ruled each one out, and the evidence that confirmed the cause.
Explain the fix and why you chose it over the alternatives you considered, including what it cost (complexity, performance, a migration). Candidates report that explaining the reasoning behind technical choices matters in these conversations, so the rejected option belongs in the answer.
Show how you verified it: the metric before and after, the test that reproduces the bug, a staged rollout. Then say what you changed so it cannot recur: an alert, a regression test, a runbook or a design guard.
Avoid the common failure: a story with no measurable outcome, or one where the challenge was organisational rather than technical. Keep a second story ready from a different area (infrastructure versus application code) in case a follow-up asks for another.

Follow-up

What other fix did you consider, and why did you reject it?
How did you prove the change actually fixed the problem rather than coinciding with it?
Looking back, what would have let you find the cause faster?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

The plan follows the three reported stages: a recruiter conversation, technical rounds covering coding and architecture, and managerial conversations. It leans on the reported stack (AWS, Azure, Docker, Kubernetes, Terraform) and the reported design and behavioral questions.

Day 1 — Resume inventory and the finance answer

List every technology and project on your resume and, for each, write the problem, the alternatives you rejected, your decision and the outcome. Mark anything you could not defend for ten minutes.
Write a short career walk-through for the recruiter screen that ends on the cloud, container or infrastructure-as-code work you have actually done.
Write and say aloud your answer on what draws you to finance and software engineering, built on a real project.

Deliverable: A resume inventory with decisions and outcomes, a short career walk-through and a written answer to the finance and software question.

Day 2 — Coding fundamentals and thread safety

Use your main language (Java, Python, C++ or Go).
After each solution, say the time and space complexity aloud and list the edge cases you tested.
Pick one of the three and write a variant that is safe under concurrent access, explaining the lock or concurrent structure you chose.

Deliverable: Three solved drills with spoken complexity statements, an edge-case list for each and one thread-safe variant.

Day 3 — Designing for high-frequency updates and choosing a database

Sketch a design for high-frequency data updates: ingest path, partitioning and per-key ordering, idempotent writes, backpressure, and what happens when a consumer falls behind.
Build a one-page comparison of database architectures (relational, key-value, document, wide-column, time-series) against access pattern, consistency and growth, then pick one for a new service and defend it.

Deliverable: A written design for high-frequency updates, a database comparison page with a justified pick, and two solved SQL drills.

Day 4 — Cloud, containers and infrastructure as code

Write your cloud experience answer around one real project: services used, trade-offs, security and recovery. Add a one-page map between AWS and Azure equivalents.
Outline how you use Kubernetes to keep a service reliable: probes, resource requests and limits, rolling updates, rollback, and what you watch afterwards.
Write a small Terraform configuration for a service and explain state, remote state locking, and what plan shows versus apply.

Deliverable: A cloud answer, an AWS and Azure equivalence map, a Kubernetes reliability outline, a working Terraform file and a written debugging sequence.

Day 5 — Hard technical problem and explaining it to non-engineers

Choose the hardest technical problem you have solved and outline it: symptoms, hypotheses, the first highest-information check, the fix and what you changed to prevent recurrence.
Write the same issue twice, once for an engineer and once for a non-technical stakeholder, with the business impact, options and recommendation.
Practise a failure and recovery explanation: how your design handles a zone outage, and where security controls sit in a financial environment.

Deliverable: A step-by-step problem walk-through, two audience-specific explanations of one issue and a one-page failure and security note.

Day 6 — Story bank for the managerial discussions

Write situation, task, action, result outlines for a technical disagreement and for a sudden change in priorities, each with the evidence, the trade-offs and the outcome.
Prepare an answer on keeping up with ESG and AI: your sources, one thing you tried, one thing you declined, and what a carbon footprint reporting pipeline needs from the engineering side.
Rehearse all outlines aloud and cut each to its essential beats.

Deliverable: Two written story outlines, a prepared ESG and AI answer, and a recorded run-through of each.

Day 7 — Full dry run

Run a mock of the three stages in order: a career walk-through, a coding problem followed by a design discussion, and a managerial conversation using your story bank.
Review your performance for unstated complexity, skipped clarifying questions and stories without a result.
Write the questions you will ask: engineering culture, the team's current challenges and how technical debt is handled.

Deliverable: A completed mock across all three stages, a list of fixes and the written questions for your interviewers.

Stories for teamwork, change and the finance context

Candidates report that the managerial stage is about team culture alignment and your project experience, and that teamwork, handling ambiguity and clear communication carry weight. For this role, that means stories that show you explaining a technical issue to non-engineers, working through disagreement without making it personal, and adapting to changing priorities. Ground each in a real decision, the trade-off and a result, and have an honest answer about why finance and software engineering appeal to you.

Can you explain your experience with cloud platforms like AWS or Azure and how you have used them in past proj

Medium · Technical and Architectural Proficiency

Can you explain your experience with cloud platforms like AWS or Azure and how you have used them in past projects?

Approach

Choose one or two real projects and name the exact services you used and why: compute, storage, networking, identity and a managed database. A service list without decisions is the weak version of this answer.
For each choice, give the trade-off you weighed (for example a managed database against self-hosting, or a queue against direct calls) and what you measured afterwards: cost, latency, availability or deployment time.
Cover how you provisioned and secured it: infrastructure as code or console, secrets handling, least-privilege roles, and how you would recover from a failure in one zone.
If you know only one of AWS and Azure, say so and map concepts across: virtual machines, object storage (S3 and Blob Storage), role-based access, managed Kubernetes (EKS and AKS). Do not claim experience with services you have only read about.

Follow-up

Why that service rather than the alternative, and what would make you switch?
How did you manage secrets and permissions, and how would you reduce the blast radius of a leaked credential?
What was your recovery plan if the region or zone went down, and had you tested it?