DEV Community: E F

Multi-stage interview process to fintech

E F — Wed, 26 Aug 2026 17:40:41 +0000

ᯅ Multi-Stage Interview Process to Fintech

⚡ Did I get an offer? I will leave the answer for the end.

✉ If you want to know the real name of fintech company R, message me on LinkedIn and like any post: https://www.linkedin.com/in/egor-f-a214b2411/

𝙿𝚢𝚝𝚑𝚘𝚗 · 𝐌𝐋 · 𝙰𝙸 𝐚𝐠𝐞𝐧𝐭𝐬 · 𝚁𝙰𝙶 · 𝐬𝐲𝐬𝐭𝐞𝐦 𝐝𝐞𝐬𝐢𝐠𝐧

⏱ Eight stages, several teams, live coding, RAG, agents, and a final round.

They actually reached out to me first, even though I had tried several times to get into this fintech company myself.

⚙ 1-stage: Demo Day

My way into the company started with what they called a Demo Day, where it was possible to get an offer in a single day.

It started with Python.

Question: Why would you use TypeVar and Protocol?

Answer: TypeVar connects an input type with an output type, while Protocol defines an interface through duck typing. Inheritance is not the important part: having the required methods is. They also asked about mutable default arguments. def f(x, l=[]) creates that list once, when the function is defined, so a dataclass needs default_factory=list for a list field.

Question: What does the GIL actually limit, and where does asyncio fit?

Answer: In CPython, only one thread executes Python bytecode inside a process at a time. Threads are mainly useful for I/O, while processes are better for CPU-bound work. asyncio is concurrent execution of coroutines inside an event loop. It works well for HTTP, databases, and files, but not for heavy CPU workloads. ContextVar stores a separate context value for every async task, so values do not get mixed together.

Question: What is the difference between __new__ and __init__, and where can recursion appear?

Answer: __new__ creates an object; __init__ initializes it. __getattribute__ runs on every attribute access, while __getattr__ runs only when an attribute is not found. Calling self.name from inside __getattribute__ can create infinite recursion.

Question: How does Python execute code?

Answer: Tokenization, AST, bytecode, then execution by the virtual machine. That is why Python both compiles to bytecode and is interpreted.

⌚ Two hours after I learned that I had passed the first filter, I went to the second part, where I got window-based tasks.

The first task was a rate limiter using a sliding window. The naive approach filters the whole request list in O(n). The better approach uses a deque: remove expired timestamps from the left and get close to O(1) work per request.

from collections import deque

window_to_see = 3
limit_to_rate = 2
requests = {}

def fun(user_id, now):
    if user_id not in requests:
        requests[user_id] = deque()
        # requests[user_id] = []

    # Naive O(n) approach:
    # new_requests = []
    # for ts in requests[user_id]:
    #     if ts > now - window_to_see:
    #         new_requests.append(ts)
    # requests[user_id] = new_requests

    # Move from O(n) to O(1)
    while requests[user_id] and requests[user_id][0] <= now - window_to_see:
        requests[user_id].popleft()

    if len(requests[user_id]) >= limit_to_rate:
        return False

    requests[user_id].append(now)
    return True

They also asked how ML CI/CD differs from regular CI/CD. In a regular pipeline, you build an artifact such as a Docker image and deploy it. The main criterion is whether tests passed.

ML CI/CD has extra moving parts: versioned data, models as artifacts, and quality metrics such as accuracy, F1 score, and latency.

Data validation:
--drift-threshold 0.1

If the distribution moves by more than 10%, fail the pipeline.

Nightly retraining:
schedule:
  - cron: "0 2 * * *"

Evaluation gate:
--min-improvement 0.02

Deploy only if F1 improves by at least 2%.

F1 is the balance between precision and recall.

Then came an ErrorCounter task: ingest accepts error codes and timestamps, get_top_3 returns the three most frequent codes over the last n minutes, and get_total_errors returns the total error count. Calls arrive in chronological order, and multiple errors can happen in the same second.

from typing import Union, List, Tuple

ErrorCode = Union[str, int]

class ErrorCounter:
    def __init__(self) -> None:
        self.errors: List[Tuple[ErrorCode, int]] = []

    def ingest(self, error_code: ErrorCode, timestamp: int):
        self.errors.append((error_code, timestamp))

    def get_top_3(
        self,
        n_mins: int,
        timestamp: int
    ) -> List[Tuple[ErrorCode, int]]:
        start_timestamp = timestamp - n_mins * 60 + 1
        counts = {}

        for error_code, error_timestamp in self.errors:
            if start_timestamp <= error_timestamp <= timestamp:
                if error_code in counts:
                    counts[error_code] += 1
                else:
                    counts[error_code] = 1

        result = list(counts.items())
        result.sort(key=lambda item: item[1], reverse=True)
        return result[:3]

    def get_total_errors(self, timestamp: int) -> int:
        return len(self.errors)


counter = ErrorCounter()

counter.ingest("E1", 1)
counter.ingest("E2", 10)
counter.ingest("E1", 20)
counter.ingest(500, 30)

print(counter.get_top_3(1, 40))
# [('E1', 2), ('E2', 1), (500, 1)]

print(counter.get_total_errors(40))
# 4

✦ I solved the tasks and my tests passed. One of the interviewer’s tests for the second task did not pass, though. He even said he did not know why it was failing, then said: “Well, never mind. The important part is that yours passed.” Then we went back to theory.

After ErrorCounter, they asked what meaningful work I had done in my latest project. I said that I had improved recall in a RAG system.

Then came regression, classification, and regularization. One question was whether regression could be used to solve a classification problem. My answer was: technically yes, but it would not make much sense. We also discussed the sigmoid function.

After that, we moved through the NLP timeline.

Bag of Words treats words as indices. TF-IDF stands for Term Frequency and Inverse Document Frequency. Term Frequency is how often a word occurs in a text. Inverse Document Frequency lowers the weight of words that appear everywhere.

TF-IDF is a cheap way to turn words into numbers for search and classification. BoW counts frequency; TF-IDF adds importance. Its limitations are clear: it does not understand context, and sparse vectors contain a lot of zeros. A practical trick is using n-grams, where you consider neighboring words rather than one word in isolation.

import pandas as pd
from sklearn.feature_extraction.text import TfidfVectorizer

texts = [
    "python python python django",
    "python python python fastapi",
    "python python python sklearn"
]

words = ["python", "django", "fastapi", "sklearn"]

tfidf = TfidfVectorizer(vocabulary=words)
X = tfidf.fit_transform(texts)

print(pd.DataFrame(X.toarray().round(3), columns=words))

#    python  django  fastapi  sklearn
# 0   0.872   0.490    0.000    0.000
# 1   0.872   0.000    0.490    0.000
# 2   0.872   0.000    0.000    0.490

python appears in all three texts, so its IDF is low. django, fastapi, and sklearn occur in only one document each, so their IDF is higher.

BM25 improves on TF-IDF by taking document length into account, giving more flexible tuning and usually better ranking.

Then came Word2Vec. These are dense but non-contextual embeddings. The classic example is king - man + woman = queen. CBOW predicts one word from several context words and is usually faster. Skip-gram predicts several context words from one target word and works well with rare words and smaller corpora. Negative Sampling updates positive and randomly sampled negative pairs instead of the entire vocabulary.

After Word2Vec came GloVe and FastText. GloVe relies on a large word co-occurrence matrix; adding a new word changes the matrix and requires recalculation. FastText extends Word2Vec with character n-grams.

RNNs process sequences step by step, passing hidden state forward. They cannot parallelize sequence processing and suffer from vanishing gradients. CNNs reuse the same filter across positions but only see local neighborhoods. LSTMs use a memory cell with input, forget, and output gates, so they preserve context better than a simple RNN, although they are slow.

Then came the GPT history: GPT-1 was a decoder-only Transformer trained for next-token prediction, then adapted for downstream tasks. GPT-2 became a larger zero-shot model. GPT-3 showed few-shot in-context learning without changing weights. InstructGPT added SFT on instruction-answer pairs and RLHF. ChatGPT became a dialogue system with alignment, tools, feedback, web search, vector search, code execution, human-in-the-loop flows, guardrails, multimodality, and memory.

⏲ I did not reach the final through the first Demo Day, but I did get into the hiring funnel.

⛓ 2-stage: AI Agents

The next stage was about agent architecture and coding in Google Colab:

https://colab.research.google.com/

They asked what an agent consists of, how to design its architecture, what to keep in memory, how it calls tools, and where checks should live.

My agent runtime looked like this:

External events / cron / user messages
                |
                v
        Event router / FSM start
                |
                v
      Context and tool router
                |
      +---------+----------+-----------------+
      |         |          |                 |
      v         v          v                 v
Vector search  Web search  Community RAG   User data
      |         |          |                 |
      +---------+----------+-----------------+
                |
                v
      Context aggregator + cache
                |
                v
         Planner -> Reviewer
                |
                v
  Chain classifier -> block constructor
                |
                v
      Local tests -> global validation
                |
                v
        Escalation guard / HITL
                |
                v
             Finalizer

In Google Colab, there was Pandas and live code review rather than a separate algorithmic challenge. They checked __call__, the Singleton pattern, an object behaving like a function, and similar Python mechanics. It was mostly about how I write and explain code in real time.

The agent runtime itself was a visual finite-state machine with more than twenty sub-agents, hooks, tools, and webhooks for inbound and outbound conversations. There was debounce, PII removal, and omnichannel communication through a chatbot and a mini landing page.

For memory, I described short-term memory as context-window management, compactization, invalidation, extension, caching, and message history. Long-term memory was a vector database with episodic and semantic memory.

Localization was not just translation. It meant preserving meaning, terminology, tone, channel-specific style, cultural context, sensitive fragments, ambiguity, and confidence level.

The architecture choices were a single agent for linear workflows, a router that sends money questions to an accounting agent and bug questions to a technical agent, or multi-agent collaboration, such as one agent writing SQL and another reviewing it.

Testing was especially important. An agent should never promise a refund before checking an order in the database. It should not confirm discounts that do not exist in CRM. It must ignore instructions to forget or change its system prompt. If a customer asks for an individual price, it should say: “I am not authorized to change the price. I will forward this request to a manager.”

⚠ Adversarial checks: will the agent give a 99% discount, leak its system prompt, become rude, run a dangerous command, promise a refund without verification, or ignore the policy after “forget your previous instructions”?

The metrics were accuracy, deflection rate, and CSAT.

⌖ 3-stage: Algorithmic Interview

I was redirected to another team, and the process almost restarted: repeated theory plus another algorithmic interview.

This became a real multi-stage process. Teams could redirect candidates between each other, and by the time you are moving through the pipeline, the original opening may no longer be the exact role you started with.

The coding platform for this stage was LeetCode:

https://leetcode.com/

The first task was PALINDROME. The first version creates a cleaned string. The second version uses two pointers and does not allocate a new string. Its complexity is O(n) time and O(1) additional memory.

def is_palindrome(text: str) -> bool:
    cleaned = ""

    for char in text:
        if char.isalnum():
            cleaned += char.lower()

    return cleaned == cleaned[::-1]


print(is_palindrome("A man, a plan, a canal: Panama"))
# True

print(is_palindrome("race a car"))
# False

def is_palindrome(text: str) -> bool:
    left = 0
    right = len(text) - 1

    while left < right:
        while left < right and not text[left].isalnum():
            left += 1

        while left < right and not text[right].isalnum():
            right -= 1

        if text[left].lower() != text[right].lower():
            return False

        left += 1
        right -= 1

    return True

The second task was sorting ages with counting sort. Since valid ages are in the 0..120 range, we count each age first and then write them back in order.

def fun(input_path="f1.txt", output_path="f2.txt"):
    MAX_AGE = 120
    WRITE_BATCH_SIZE = 100_000
    counts = [0] * (MAX_AGE + 1)

    # First pass: count people of each age.
    with open(input_path, "r", encoding="utf-8") as f1:
        for line in f1:
            age = int(line)
            counts[age] += 1

    # Second pass: write ages in order.
    with open(output_path, "w", encoding="utf-8") as f2:
        for age in range(MAX_AGE + 1):
            how_many_people = counts[age]
            one_person = f"{age}\n"

            while how_many_people > 0:
                batch = min(how_many_people, WRITE_BATCH_SIZE)
                f2.write(one_person * batch)
                how_many_people -= batch

∑ Time complexity: O(n + k)

⌘ Memory complexity: O(k)

⚡ 4-stage: ML

This was the ML section and an ndcg_at_k task.

⌖ The live-coding room for this exact nDCG task was:

https://interview.cups.online/live-coding/?room=7fdf45e7-fe28-4ee0-9df7-e049952f1ad0

We calculate the metric for one query: search output is a list of document IDs sorted by descending score, labels are {id: relevance}, relevance is an integer from 0 to 3, gain is linear, and the discount is log2(i + 1).

import math

def ndcg_at_k(ranked_ids, relevance, k):
    dcg = 0.0
    idcg = 0.0

    for pos, doc_id in enumerate(ranked_ids[:k], start=1):
        r = relevance.get(doc_id, 0)
        dcg += r / math.log2(pos + 1)

    ideal_dcg = sorted(relevance.values(), reverse=True)[:k]

    for pos, rel in enumerate(ideal_dcg, start=1):
        idcg += rel / math.log2(pos + 1)

    if idcg == 0.0:
        return 0.0

    return dcg / idcg

rel = {"a": 3, "b": 2, "c": 3, "d": 0, "e": 1}

assert abs(ndcg_at_k(["a", "c", "b", "e", "d"], rel, 5) - 1.0) < 1e-9
assert abs(ndcg_at_k(["d", "e", "b", "a", "c"], rel, 5) - 0.6458) < 1e-4
assert abs(ndcg_at_k(["b", "a", "c"], rel, 3) - 0.9152) < 1e-4
assert abs(ndcg_at_k(["a", "c"], rel, 2) - 1.0) < 1e-9
assert abs(ndcg_at_k(["e", "d"], rel, 2) - 0.2044) < 1e-4
assert abs(ndcg_at_k(["a", "c", "b"], rel, 10) - 0.9319) < 1e-4
assert ndcg_at_k([], rel, 5) == 0.0
assert ndcg_at_k(["x", "y"], rel, 2) == 0.0
assert ndcg_at_k(["d"], {"d": 0}, 1) == 0.0

print("All good!")

They also asked for definitions of retrieval and RAG metrics.

Recall@K answers: what proportion of all relevant documents appears in top-K?

Recall@K = relevant documents in top-K / all relevant documents

It mostly ignores the order inside top-K. In RAG, this is critical. If the required document never reaches top-K, the LLM cannot use it in the answer. A concrete example: before improvements, the right document appeared in top-10 for 72 out of 100 queries; after improvements, it appeared for 88 out of 100.

MRR, Mean Reciprocal Rank, measures how high the first relevant result appears. A relevant result in first position gives 1.0, in second position 0.5, in third position roughly 0.33.

MRR = 1/N * Σ(1/rank)

MAP, Mean Average Precision, is stricter. It cares about all relevant documents and their order, not just the first correct one.

DCG accounts for ranking order and graded relevance. NDCG compares the real ranking with the ideal ranking, so it normally lies between 0 and 1.

IDCG@3 = 3/log2(2) + 1/log2(3) = 3.631
NDCG = DCG / IDCG

HitRate@K answers whether there is at least one relevant result in top-K. Precision@K is relevant documents in top-K divided by K, which matters when you want clean context for the LLM. PFound estimates whether a user is likely to find an answer.

MMR, Maximal Marginal Relevance, is not a metric. It is a retrieval strategy that avoids selecting highly similar chunks. For example, retrieve fetch_k = 10 chunks and select a diverse k = 3. A lambda_mult close to 1.0 favors relevance; closer to 0.0 favors diversity.

To choose K for a retriever, I would test values such as 20, 50, 100, and 1000, and compare recall, ndcg@K, MRR, p95/p99 latency, and API cost. I would choose the smallest K after which quality almost stops improving while latency and cost still fit the SLA.

After generation, faithfulness measures whether an answer is supported by context:

Faithfulness = supported_claims / all_claims

Answer relevance checks whether the answer actually answers the question. Context precision or relevance checks how much retrieved context is useful. Answer correctness asks whether the answer is correct. Context recall asks whether all necessary facts made it into the context.

For generated text, they asked about G-Eval, BLEU, ROUGE, and newer alternatives. G-Eval is LLM-as-a-judge with a numeric score for correctness, coherence, completeness, and relevance. BLEU compares n-grams with a reference and penalizes very short answers, but it does not understand meaning well. ROUGE-1/2/L is a recall-oriented family for summarization; ROUGE-L uses the longest common subsequence.

FineSurE evaluates faithfulness, conciseness, and completeness. BLEURT and COMET are trained metrics. SEAHORSE evaluates clarity, repetition, grammar, factuality, key ideas, and conciseness. BERTScore compares semantic similarity through embeddings. For RAG, none of these is enough on its own, so much of modern validation uses LLM-as-a-judge.

For the retriever pipeline, they asked about Multiple Negatives Ranking Loss, InfoNCE or contrastive loss with in-batch negatives, and triplet margin loss. A bi-encoder or dual-encoder retriever is optimized for Recall@K: the query should be closer to the relevant document and farther from negatives.

For the reranker pipeline, they asked about pointwise Binary Cross-Entropy or MSE on graded relevance; pairwise RankNet, BPR, and margin ranking loss; and listwise ListNet, ListMLE, and LambdaRank. A cross-encoder reranker puts top-K results in order, so the relevant metrics are nDCG@K, MRR, and MAP.

⚒ 5-stage: AI Agents

This was another agent interview, but this time with Docker, model weights, MCP, and Transformers.

One question was how to mount model weights. My answer: use a volume.

The harness runs the agent loop, connects tools and MCP servers, logs tool calls and token usage, runs evaluations, checks permissions, requires approval for dangerous actions, and stores the audit trail.

For agent security, I split the answer into three layers: sandboxing, permission model, and audit trail.

Sandboxing means isolated execution: a separate container or pod with CPU, memory, network, filesystem, and timeout restrictions. No access to secrets by default.

The permission model defines allowed actions. Read-only tools can be available immediately. Deploy, delete, payment, database migration, email sending, and PII access require explicit approval. Permissions should be task-specific and scoped by user or admin role.

The audit trail records who started the task, which prompt was used, which tools and arguments were called, which files changed, token usage, approvals, and the result.

Function calling is a mechanism where the application exposes a function to the model. Tool calling means calling external actions from a conversation, for example internal APIs, CRM, databases, or external sources.

MCP, Model Context Protocol, standardizes how an AI application connects to external systems. MCP consists of an MCP client, such as an IDE, agent, or chat application; an MCP server; tools as allowed actions; resources such as files and tables; and prompts.

MCP flow:

Handshake
  -> tool discovery with parameters
  -> client request
  -> routing
  -> a specific tool response

A tool is a function. MCP is a standardized client-server architecture around tools, resources, and prompts.

To protect MCP, I mentioned OAuth, RBAC, scopes for every tool, allowlists, rate limits, audit logs, HITL, and prompt-injection defenses. External documents should be treated as untrusted data. System instructions should stay separate from retrieved content. Tool arguments must be validated, secrets should not be passed to the model, and critical operations should require human approval.

For Transformers, I covered embeddings, positional information, and self-attention. Query, Key, and Value connect tokens in context. Multi-head attention captures different dependencies. Residual connections and normalization stabilize training. A decoder-only Transformer predicts the next token.

There were also Kubernetes questions: deployments, services, ingress, environment variables and secrets, resource requests and limits, health checks, and autoscaling. Helm charts parameterize dev, stage, and production environments. GitLab CI/CD builds Docker images, runs tests and linters, pushes to a registry, and deploys through helm upgrade.

Agent testing included routing tests, golden datasets, adversarial tests, replaying production traces, and shadow mode. Multi-agent workflows included thinking traces, streaming, vision with image bytes or base64, structured output through Pydantic or JSON, parallel tool calling, multi-turn tool calling through an agent loop, context-window management, heartbeats, and permission limits.

Context compactization included summaries, key-fact extraction or NER, removing old tool results, deduplicating goals, constraints, tool results, file links, chunks, errors, and next actions. Older information can be retrieved when needed.

⚲ Zero trust matters: agents should be isolated.

⚖ 6-stage: Principal Tech Lead, RAG

This was a separate day and a separate stage: a short interview, around 30 minutes, with a Principal Tech Lead. It was heavy on RAG questions, not a continuation of the agent-architecture discussion.

Question: What would you do if faithfulness dropped by 5% after the system was already in production?

That led to follow-up questions: how to distinguish a retrieval problem from a generation problem; which offline and production metrics to inspect; how to build a golden dataset and replay production traces; how to compare old and new versions of the retriever, embeddings, chunking, reranker, and prompt; how to detect data drift and document freshness issues; and what to do when there is no source, insufficient context, or a hallucination.

More RAG questions covered Recall@K, Precision@K, HitRate, MRR, MAP, DCG, and NDCG; which metrics belong to the retriever and which to the reranker; how to evaluate citations, answer relevance, context relevance, and faithfulness; why chunk size, overlap, metadata filters, query rewriting, hybrid search, BM25, vector search, RRF, and reranking matter; when to abstain or call a human; and how to use A/B testing, shadow mode, rollback, and versioning for data, indexes, embeddings, and models.

On my previous project, I had improved RAG recall. The important part here was not one number. It was explaining where the loss came from: document indexing, chunking, retrieval, ranking, context construction, or the final answer, and proving it with data rather than intuition.

⚙ 7-stage: System Design

In system design, I did not list infrastructure components in isolation. I designed one system: RAG with hybrid search over corporate documents, returning an LLM answer with citations.

I started with requirements: is it B2B, B2C, or internal? What are the document volume and freshness requirements? What is the SLA, peak QPS, read/write ratio, PII policy, and acceptable latency?

The goal is not simply to produce text. It is to retrieve the required sources, send a controlled amount of context to the LLM, and return verifiable citations.

⟁ Core metrics: faithfulness, retrieval recall, context size, p50/p95/p99 latency, RPS/QPS/tokens, concurrency, CPU/GPU/database/network/storage usage.

Documents
  -> S3 / blob storage
  -> extraction and chunking
  -> PII filtering
  -> embeddings + metadata
  -> OpenSearch: BM25 + vector index

Query
  -> API Gateway
  -> hybrid retrieval: BM25 + kNN
  -> RRF / weighted score
  -> cross-encoder reranker
  -> top-K context
  -> LLM answer + citations

On the query path, the API Gateway provides authentication, rate limiting, routing, observability, versioning, and X-API-Key validation. The query service sends the request to OpenSearch. BM25 provides lexical search, vector kNN provides semantic search, RRF or a weighted score combines results, and a cross-encoder reranker orders them. Then top-K chunks go into the LLM together with citations.

Every component has a role in answer quality: the retriever owns recall, the reranker owns ranking order, and the LLM owns the final answer and faithfulness.

The document path goes in the other direction. Raw files live in S3 or blob storage. Private files use pre-signed URLs with a signature and expiration time. An ingestion worker runs extraction, PII filtering, chunking, embedding, and indexing with metadata and ACL.

I would not keep long-running ingestion inside an HTTP request. I would put it into Kafka, RabbitMQ, or SQS. I would not create a Kafka topic per user. Instead, there is a user_events topic, and Kafka distributes users across partitions using hash(user_id). Consumer groups can read independently. Transactional outbox and idempotency prevent duplicate indexing or repeated operations. A DLQ collects documents that could not be processed.

Storage is chosen by role. PostgreSQL or YandexDB stores tenants, users, ACL, job status, and relationships. PgBouncer limits physical connections from services and workers to the database; read replicas serve read traffic. OpenSearch or Elasticsearch handles ranking, aggregations, and hybrid retrieval. The vector index handles embedding search. ClickHouse or Snowflake can store query and quality analytics.

MongoDB makes sense when the whole object is primarily JSON. ScyllaDB or Cassandra, with LSM storage, fit very high write throughput but do not replace PostgreSQL where joins and relationships matter. Neo4j is relevant only if the system adds graph permissions, social relationships, or fraud detection.

Caching also belongs to this RAG task, not to a random infrastructure checklist. Browser cache, CDN, Nginx reverse proxy, external Redis, and internal cache reduce p95 for frequent queries and repeated retrieval. CDN pull works for ordinary static attachments; CDN push works when edge locations are prefilled.

The DNS path is browser, DNS resolver, root DNS, .com DNS, authoritative DNS, then IP, although in practice much of it is hidden behind TTL caching. Redis can hold query cache, sessions, rate-limit counters, and distributed locks. After a deployment, cold cache can be handled with cache warming. Redis Sentinel can switch the master after a failure. Invalidation is mandatory: otherwise the LLM may cite a document that was updated or closed.

For this RAG endpoint, I would use Fixed Window, Sliding Window, or Token Bucket rate limiting at both Nginx and the endpoint level. Rate limiting only by IP is not enough because of proxies.

Nginx can balance through Round Robin, Weighted Round Robin, Least Connections, Least Response Time, Random, or IP Hash. If services use gRPC with a long-lived HTTP/2 connection, an L7 load balancer is needed; otherwise one connection can break normal balancing.

For resilience, I would use retries with exponential backoff and jitter, a Circuit Breaker with Closed/Open/Half-Open states for external embedding or LLM providers, and Bulkheads so one failed provider cannot consume all available resources.

On the production side, that means metrics, logs, tracing, alerts, Sentry, documentation, and unit/integration/end-to-end tests. Security means roles, 2FA, HTTPS, access checks at the chunk and tenant level, guardrails, and HITL moderation for risky actions. Deployment should be zero-downtime, with several stateless workers, rate limits, and rollback.

Strong consistency is needed for ACL updates and document deletion. Eventual consistency is acceptable when a new embedding appears in search a few seconds later.

Sharding also belongs to this exact system when tenant and document counts grow. Options are range-based, hash-based with hash(tenant_id) % N, directory-based with a separate mapping table, geographic, and time-span sharding. For vector or index nodes, consistent hashing minimizes data movement: if you move from nine servers to ten, roughly 10% of data moves instead of almost all data.

For deep search results, I would use cursor or search_after pagination because offset becomes expensive. Metadata and ACL in the database are the source of truth; the search index is a rebuildable read model.

⚖ The core trade-off: latency, consistency, cost, and retrieval freshness.

It was at system design that I finally reached the final, unlike the Demo Day, where I got into the funnel but did not reach the end.

★ 8-stage: Final

By the final, this was already the eighth stage.

For some reason, the final questions were almost entirely about databases, message brokers, Kafka, Redis, RabbitMQ, replication, sharding, partitioning, microservices, and monoliths.

Redis came up as cache, session storage, rate limiting, distributed locks, counters, and leaderboards. Kafka came up as a log with topics, partitions, consumer groups, DLQ, retries, idempotency, and transactional outbox. RabbitMQ came up as queues, routing, and acknowledgements.

We discussed asynchronous and synchronous replication with read replicas. Partitioning means splitting a large table, for example by time. Sharding means distributing data across independent nodes by range, hash, directory, geography, or time span.

A monolith makes sense for a local or early-stage product: it is easier to develop, deploy, and keep transactions consistent. Microservices make more sense for multiple geographies, independent business domains, and separate teams: auth, users, vehicles, rentals, payments, and notifications.

Services should be stateless, so new instances can be started horizontally; databases are replicated. The trade-off is that microservices add network complexity, observability, schema evolution, distributed transactions, Saga patterns, retries, and idempotency.

The system-design questions I now ask at the start are simple: What is the business goal? What are the functional and non-functional requirements? What are the constraints and success metrics? Is this B2C, B2B, or internal? What are DAU/MAU, peak QPS, growth, and read/write ratio? Does p95 need to be under 200 ms, or are 2-3 seconds acceptable? Do we need strong consistency or eventual consistency? Are real-time updates required? How many entities already exist, how many are created per day, and which fields are used for search and filtering?

★ The whole process, from the Demo Day and getting into the funnel, took from July 4 to August 25, 2026.

Fintech company R: I will reveal the real name on LinkedIn. Find me here, send me a DM, and like any post. I will reply:

https://www.linkedin.com/in/egor-f-a214b2411/

∞ My main takeaway: in this company, teams choose candidates for themselves and, crucially, they do not see your results from previous interviews. That gives you a real chance to try again.

✦ One last aside: here is another piece of code from one of my interviews:

https://codeinterview.io/QJQIDBHIMS

Yes, that was also fintech, but another fintech, another story.. ♥

Technical Interview for an Agentic Technical Lead Role

E F — Fri, 31 Jul 2026 16:36:34 +0000

The company name has been slightly modified.

(I will share the original company name after you subscribe to my DEV.to and https://www.linkedin.com/in/egor-f-a214b2411.)

Today I had a real technical interview for an Agentic Technical Lead position at 4nd-ever.

The interview focused on LangGraph, MCP, LangFuse, evaluation, observability, routing, tool calling, and the architecture of production-ready agentic systems.

2. Role Overview

2.1. Main Goal

The role was focused on building an internal platform that allows engineering teams to create, configure, evaluate, observe, and deploy agentic systems.

The goal was not to build one AI agent. The goal was to build reusable infrastructure for many teams and use cases.

2.2. Main Responsibilities

Design an agentic systems framework.
Build LangGraph-based orchestration.
Create reusable MCP Server and MCP Client templates.
Implement evaluation pipelines with LangFuse.
Support datasets, experiments, and LLM-as-a-Judge.
Add tracing, cost monitoring, latency metrics, and drift detection.
Support RAG, tool calling, structured outputs, and prompt chaining.
Provide reusable components through Backstage.
Own production reliability, retries, fallbacks, releases, and rollbacks.
Mentor engineers and define the platform roadmap.

2.3. Main Stack

Python
LangGraph
LangFuse
MCP Servers and Clients
PostgreSQL
Backstage
AWS
Kubernetes
GitLab
Vector databases
RAG
Tool calling

3. Theoretical Interview Questions

3.1. How did you use LangGraph, and how was the agent structured?

I used LangGraph as an explicit state graph.

Nodes perform individual steps, while edges define transitions and branches. The agent stores its current state, calls tools, supports retry and fallback paths, and terminates when a defined terminal condition is reached.

3.2. What were the inputs and outputs of the planner layer?

The planner received:

the user goal;
the current state;
available tools;
system constraints.

It returned a structured plan containing:

execution steps;
selected tools;
tool arguments;
completion criteria.

3.3. What does a typical LangGraph flow look like?

User request
-> classification and routing
-> retrieval or tool execution
-> result validation
-> final response

Failure branches may include:

retry
fallback
clarification
human escalation

3.4. Where should deterministic logic be implemented: in the MCP client or MCP server?

Both components require deterministic logic.

The MCP client manages:

timeout;
retry;
routing;
request format;
response parsing.

The MCP server manages:

schema validation;
authorization;
idempotency;
safe tool execution.

3.5. How did you build observability and evaluation?

Observability answers:

What happened inside the workflow?

It includes:

traces;
prompts;
tool calls;
latency;
cost;
errors.

Evaluation answers:

How well did the agent complete the task?

It includes:

offline datasets;
metrics;
regression testing;
experiments;
human review.

3.6. Did you use LangFuse or another tool?

LangFuse is a strong primary layer for:

LLM tracing;
datasets;
experiments;
evaluation.

Infrastructure monitoring still requires additional tools such as:

CloudWatch;
Grafana;
Prometheus;
structured application logs.

3.7. How do you create evaluation datasets when agents can follow different paths?

An agentic dataset should contain more than input and output.

It should include:

user goal;
initial state;
available tools;
allowed trajectories;
forbidden actions;
expected final state;
edge cases.

I would begin with real production cases and then add synthetic edge cases.

3.8. Is evaluation context created automatically or manually?

The best approach is hybrid.

Humans define:

taxonomy;
rubric;
quality criteria;
safety boundaries.

Automation extracts:

traces;
tool calls;
outputs;
latency;
errors;
cost.

Important or ambiguous cases should pass human review.

3.9. What context should be provided to an LLM-as-a-Judge?

The judge should receive:

the original task;
the rubric;
the expected result;
constraints;
the actual execution trace;
tool calls;
the final answer.

It should score specific criteria such as:

correctness;
safety;
completeness;
trajectory quality.

3.10. What should be included in an evaluation dataset?

For a simple LLM feature:

input + golden answer

For an agentic workflow:

initial state;
available tools;
allowed tool calls;
key intermediate steps;
negative cases;
success conditions;
failure conditions.

3.11. Which metrics matter for agentic systems and tool calling?

task-completion rate;
tool-selection accuracy;
argument accuracy;
tool success rate;
trajectory accuracy;
latency per step;
retries and fallbacks;
cost;
schema validity;
safety violations.

3.12. What should the classifier predict?

The classifier should classify the user request and select an intent or route.

Example classes:

RAG;
action or tool use;
support;
billing;
research;
validation;
unknown.

It may also estimate:

risk;
domain;
confidence;
escalation requirements.

3.13. What data does the classifier use?

the current user request;
recent conversation history;
user and tenant metadata;
current workflow state;
previous tool results.

Training data may include:

labeled real requests;
production traces;
synthetic rare cases.

3.14. How do you route arbitrary user requests?

I would use a router with a confidence threshold.

First, the system determines:

intent;
risk;
confidence.

Then it routes the request to:

RAG;
action workflow;
research;
specialist agent.

Low-confidence or high-risk requests should trigger clarification or human review.

4. Practical Architecture Task

4.1. The Main Requirement

After the theoretical questions, I was asked to design a production-ready agentic architecture using LangGraph.

The key condition was:

The system does not know in advance what request the user will send or what context will be required.

This was the most important part of the task.

The interviewer clearly expected the architecture to introduce a classifier before full context collection and tool execution.

The expected insight was not simply:

User -> RAG -> LLM -> Answer

The expected insight was:

User -> Classifier -> Required Context -> Route -> Execution

The classifier is essential because the system must first determine:

what the user wants;
which domain the request belongs to;
what context is required;
which tools are allowed;
whether the request is risky;
whether human review is needed.

4.2. Architecture Diagram

Excalidraw Whiteboard

Excalidraw is a virtual collaborative whiteboard tool that lets you easily sketch diagrams that have a hand-drawn feel to them.

excalidraw.com

suggested

[FIGURE 1 - LangGraph Agentic Architecture]

Figure 1 shows the proposed architecture with:

Trigger or Cron;
Pre-check node;
Intent classifier;
Context builder;
Router;
Execution node;
Validation node;
Checkpointer;
HITL User;
HITL Admin;
Circuit Breaker;
Redis, relational database, and vector database.

A critical detail in Figure 1 is that several nodes contain internal iterations.

These iterations are not decorative. They represent repeated processing inside the workflow.

Examples:

build_context iterates over context sources;
router iterates over candidate tools;
execution_node iterates over planned tasks;
validate_node iterates over evaluation metrics;
checkpointer_node controls retry loops.

4.3. Main Flow

Trigger
-> Pre-check
-> Intent Classifier
-> Context Builder
-> Router
-> Execution
-> Validation
-> Final Response

Additional branches:

Retry
Fallback
HITL User
HITL Admin
Circuit Breaker

4.4. Pre-check Node

The pre-check node performs deterministic operations:

authentication;
input validation;
data cleaning;
language detection;
metadata loading;
rate limiting.

def pre_check(state):
    return {
        "query": clean(state["query"]),
        "status": "validated",
    }

4.5. Intent Classifier

The classifier is the central component of the architecture.

It receives minimal context and returns a structured routing decision.

class Intent(BaseModel):
    route: Literal[
        "rag",
        "action",
        "research",
        "support",
        "billing",
        "unknown",
    ]
    confidence: float
    risk: str
    required_context: list[str]
    allowed_tools: list[str]

def classify(state):
    result = llm.with_structured_output(Intent).invoke(
        {
            "query": state["query"],
            "history": state.get("history", [])[-5:],
        }
    )
    return result.model_dump()

This directly solves the unknown-context problem.

The system does not load everything first. It classifies the request and then retrieves only the required context.

4.6. Context Builder

The context builder may use:

Redis;
PostgreSQL;
vector databases;
conversation history;
summaries;
RAG;
user metadata.

The internal iteration from Figure 1 can be implemented as:

def build_context(state):
    context = {}

    for source in state["required_context"]:
        context[source] = LOADERS[source](state)

    return {"context": context}

4.7. Router

The router selects a tool, specialist agent, or subgraph.

def route(state):
    if state["risk"] == "high":
        return "hitl_admin"

    if state["confidence"] < 0.5:
        return "hitl_user"

    return state["route"]

The router may internally evaluate several tools before selecting one.

4.8. Execution Node

The execution node processes the structured plan.

Figure 1 explicitly shows iteration over tasks.

def execute(state):
    results = []

    for task in state["tasks"]:
        results.append(TOOLS[task["tool"]].invoke(task["args"]))

    return {"results": results}

For production workflows, one task per graph transition is often safer because the state can be checkpointed after each external call.

4.9. Validation Node

The validation node checks:

schema validity;
correctness;
safety;
tool results;
terminal conditions.

Figure 1 shows an internal loop over metrics.

def validate(state):
    scores = [metric(state) for metric in METRICS]

    return {
        "scores": scores,
        "passed": all(score["passed"] for score in scores),
    }

4.10. Retry, Fallback, and Circuit Breaker

A failed validation may trigger:

retry;
replanning;
fallback;
human review;
circuit breaker.

def after_validation(state):
    if state["passed"]:
        return "final"

    if state["retry_count"] >= 3:
        return "circuit_breaker"

    return "retry"

4.11. Minimal LangGraph Assembly

graph = StateGraph(AgentState)

graph.add_node("pre_check", pre_check)
graph.add_node("classify", classify)
graph.add_node("context", build_context)
graph.add_node("execute", execute)
graph.add_node("validate", validate)

graph.add_edge(START, "pre_check")
graph.add_edge("pre_check", "classify")
graph.add_edge("classify", "context")
graph.add_edge("context", "execute")
graph.add_edge("execute", "validate")

graph.add_conditional_edges(
    "validate",
    after_validation,
    {
        "final": END,
        "retry": "execute",
        "circuit_breaker": END,
    },
)

5. Main Takeaway

The most important question was not:

How do we connect an LLM to a tool?

The real question was:

How do we design an agent when the required context is unknown in advance?

The interviewer wanted to hear that a classifier should appear before full context retrieval and tool execution.

The classifier determines:

intent;
risk;
confidence;
required context;
allowed tools;
execution route.

Only after that should the system retrieve data, build a plan, call tools, validate the result, and terminate the workflow.

The internal iterations shown in Figure 1 are also important because real agentic systems repeatedly process:

context sources;
candidate tools;
execution tasks;
evaluation metrics;
retry attempts.

6. Interview Results

If you want to learn the final result of this interview, subscribe to my DEV.to and LinkedIn:

DEV.to: https://dev.to/efa

LinkedIn: https://www.linkedin.com/in/egor-f-a214b2411/

You can also message me directly, and I will reply privately.

I Solved Reef Technologies’ Recruitment Game — and Learned to Evaluate the Hiring Process Too

E F — Sun, 19 Jul 2026 13:38:53 +0000

⚖ Context note. This is my personal account of a recruitment process with Reef Technologies in June–July 2026. It combines facts from my correspondence, my own interpretation of the experience, and a technical walkthrough of code I wrote. It is not an allegation that the company or its employees committed fraud. The recruitment flow simply raised serious privacy, communication, and process questions for me.

ᯅ I solved a difficult recruitment game. The harder lesson was outside the code.

Most take-home assignments are framed as a one-way evaluation.

⌕ Can the candidate understand requirements?

⚒ Can they design a solution?

⚙ Can they write and test reliable code?

Those are fair questions. But after this experience I would add another:

⌘ Can the candidate evaluate the hiring process, its tools, and the access they are asked to give before they are hired?

I completed a gamified recruitment assignment for a Senior Python Backend Engineer role at Reef Technologies. The assignment itself was genuinely challenging and technically rewarding: three stages, sub-stages, gradually unlocked mechanics, a limited number of turns, resource logistics, production chains, and a remote API.

I finished all three stages, submitted the code, and built a reusable solver rather than a one-off script. Yet I did not progress further because I had not logged the work through Hubstaff, a desktop time-tracking tool that the company required candidates to use.

This article has two threads:

⛓ the engineering story: how I built a capability-driven Python solver that could reason about unknown game mechanics;
⚡ the candidate story: why I became cautious about an installation request that included desktop monitoring and screenshots, and what I would verify before taking a similar assignment again.

Both lessons matter.

✉ The onboarding request that made me pause

After completing an initial test, I received a congratulatory email and an invitation to the next stage. The message said that the task had to be tracked through the desktop version of Hubstaff. It also explained that the application could periodically take screenshots while I worked.

The request did not feel sufficiently clear and connected in my inbox at the moment I saw it. From my perspective, it looked like a request to install software on my personal computer that could collect work metrics and capture the screen. I treated that as a possible security issue, deleted the message, and later emptied the trash.

Only afterward, while dealing with the task and follow-up correspondence, did I connect the tracking requirement with the recruitment game itself.

⚖ The important nuance

The complete instruction email did contain the Hubstaff requirement. Not following it was my responsibility, and I do not want to rewrite the facts to make that disappear. The company later explained that Hubstaff tracking was an integral requirement because it reflects how their team tracks work time day-to-day. They chose not to move my application forward because no time was recorded there.

At the same time, I believe an installation requirement with screen monitoring deserves a more explicit, security-conscious onboarding flow.

◈ What I would expect before installing monitoring software

✉ A separate, clearly titled message: “Required software for the recruitment task.”
⌕ A direct explanation of why it is needed before employment.
⚲ A description of what data is collected: activity, screenshots, application names, URLs, or anything else.
♥ A retention and access policy: who can see the data, and for how long.
⛓ A verified source for the installer and a way to confirm that the request is authentic.
⏱ A prominent statement that missing this step blocks the next stage.
⚖ A safe alternative, if one exists: a separate device, a virtual machine, or an agreed evidence-based workflow.

I am not saying that Hubstaff is inherently unsafe, nor that the process was a scam. My point is narrower and practical: installing any screen-monitoring application on a personal machine is a meaningful privacy and security decision. A candidate is allowed to pause, verify, ask questions, and decline to execute an unclear installation request blindly.

⚡ TRUST != CLICK_FIRST_ASK_LATER

⏱ The apparent contradiction: the platform knew my progress

The task itself ran on the company’s web platform. It showed my progression through three stages and their sub-stages; after each completed task, the corresponding status indicators changed. After I submitted my solution, I was told that an engineer had checked the time I spent in their system — but that this was not the same as Hubstaff tracking.

This is where the process felt counterintuitive to me.

The platform could already establish several useful facts:

⌚ I had started the tasks;
✦ I had completed the required game stages;
⟁ tasks were completed in a visible sequence;
⌖ the final solution was submitted.

However, this is also where I can see the company’s side. Platform activity is not a reliable work-time log. It does not include reading specifications, setting up a Python environment, designing architecture, debugging algorithms, writing tests, or stepping away from the keyboard. It cannot accurately prove how long someone worked.

So the core issue was not whether their game platform had any evidence of progress. It did. The issue was that it did not satisfy their separate, explicit requirement for a time tracker.

⏲ My takeaway: a system can prove that you reached an outcome without proving how you spent every minute getting there.

Still, that distinction should be visible from the first line of the task brief — especially when the candidate is asked to run monitoring software during unpaid evaluation work.

⚒ The assignment: a logistics game, not a scripted puzzle

The technical task was much stronger than the administrative experience around it.

At a high level, the game was a turn-based logistics and production problem. A level contained:

a map and terrain;
a base with an inventory;
resource nodes;
structures already on the map;
a goal inventory that had to be delivered to a target structure;
a maximum number of turns.

The available mechanics evolved between stages. Early on, a simple solution might build a road, build a quarry, mine stone, transfer it to the base, and claim the win. That approach collapses as soon as the server introduces new resources, transport types, construction costs, recipes, or production structures.

So I chose a different target:

★ Do not solve one map. Build a solver that can interpret each stage.

The project became a small planning system with four independent layers.

                  ✉ Remote game API
                         │
                         ▼
              ◈ CapabilityRegistry
          actions · resources · structures
                         │
                         ▼
                  ⚙ GameState
       board · structures · storage · turns · goal
                    │                 │
                    ▼                 ▼
             ⚖ Local validator    ⚒ Strategy
          replay + invariants    plan + search
                    │                 │
                    └───────⌘─────────┘
                            │
                            ▼
                 valid JSON plan → server

The key idea is simple: the strategy must not depend directly on HTTP response shapes, and the server must not be the first place where an invalid plan is discovered.

❖ 1. Actions are real objects, not loose dictionaries

Every game action is a Python object. That gives it behaviour, type identity, string representation for debugging, and a clear mapping to the remote API.

class BuildAction(BaseAction):
    def __init__(self, x: int, y: int, structure_type: StructureType | str):
        self.x = x
        self.y = y
        self.type = structure_id(structure_type)

    @property
    def action_type(self) -> str:
        return "BUILD"

    def to_api_action(self) -> Action:
        return Action(
            action="BUILD",
            args={"x": self.x, "y": self.y, "type": self.type},
        )

    def apply(self, game_state: GameState) -> None:
        structure = game_state.make_structure(self.type, self.x, self.y)
        game_state.base.storage.subtract_in_place(structure.build_cost)
        game_state.add_structure(structure)

The same pattern is used for building, mining, transfers, production, and the final win claim:

BuildAction(x, y, structure_type)
ExtractAction(x, y)
TransferAction(path, resource, amount)
ProduceAction(x, y)
ClaimWinAction(x, y)

Why not just create JSON dictionaries in the strategy?

Because the solver has to answer a more important question before serialisation:

⚖ What does this action do to the world state?

If the action can be applied locally, the strategy can observe the consequences of its own choices immediately. A new road changes connectivity. A mine fills a local inventory. A transfer makes material available for construction at the base. Production consumes inputs and creates outputs.

That is the difference between printing a plausible request body and actually planning.

⛓ 2. Model resources as a first-class value object

Resources appear everywhere: construction costs, mine output, transfer amounts, recipes, and win conditions. I used a small Inventory abstraction rather than scattering dict.get(..., 0) across the codebase.

class Inventory:
    def __getitem__(self, resource: ResourceKey) -> int:
        return self._resources.get(resource_id(resource), 0)

    def add(self, resource: ResourceKey, amount: int) -> None:
        if amount > 0:
            self[resource] = self[resource] + amount

    def subtract_in_place(self, other: Inventory) -> None:
        for resource, amount in other:
            self.remove(resource, amount)

    def at_least(self, other: Inventory) -> bool:
        return all(self[resource] >= amount for resource, amount in other)

That made core intent readable:

if state.base.storage.at_least(state.goal_resources):
    yield ClaimWinAction(state.base.x, state.base.y)

No repeated loops. No silent KeyError. No accidental mutation of the goal. Just a domain-level statement: the base has enough resources to satisfy the goal.

✦ INVENTORY is small code with a large effect on clarity.

⚙ 3. Interpret the stage instead of hardcoding its names

The game exposes stage capabilities: resources, actions, structures, their interfaces, their costs, and eventually their recipes. I converted that server-defined data into a CapabilityRegistry.

@dataclass(frozen=True)
class StructureSpec:
    type: str
    build_cost: Inventory
    interfaces: frozenset[str]
    rate: int | None = None
    resource_allow: tuple[str, ...] = ()
    recipe_inputs: Inventory = field(default_factory=Inventory)
    recipe_outputs: Inventory = field(default_factory=Inventory)

    @property
    def is_extraction(self) -> bool:
        return self.has_interface(StructureInterface.Extraction)

    @property
    def is_production(self) -> bool:
        return self.has_interface(StructureInterface.Production)

Now the solver can select structures by their role:

def extractor_specs_for(self, resource: str) -> list[StructureSpec]:
    return [
        spec for spec in self.structure_specs.values()
        if spec.is_buildable
        and spec.is_storage
        and spec.is_extraction
        and (not spec.resource_allow or resource in spec.resource_allow)
    ]

That means the strategy does not say:

# fragile, level-specific thinking
build("STONE_QUARRY")

It says:

⌕ Find a buildable, storage-capable extractor
  that can mine the resource this node contains.

This matters because a game that evolves by stage is a deliberately moving target. A hardcoded first-level script is not an algorithm; it is a screenshot of an algorithm.

𝚒𝚗 𝚘𝚝𝚑𝚎𝚛 𝚠𝚘𝚛𝚍𝚜

𝚃𝚑𝚎 𝚜𝚎𝚛𝚟𝚎𝚛 𝚍𝚎𝚜𝚌𝚛𝚒𝚋𝚎𝚜 𝚠𝚑𝚊𝚝 𝚎𝚡𝚒𝚜𝚝𝚜; 𝚝𝚑𝚎 𝚜𝚘𝚕𝚟𝚎𝚛 𝚍𝚎𝚌𝚒𝚍𝚎𝚜 𝚠𝚑𝚊𝚝 𝚝𝚘 𝚍𝚘 𝚠𝚒𝚝𝚑 𝚒𝚝.

I also added an early compatibility check. If the server advertises an action that the local solver does not implement, the program stops instead of improvising an invalid plan:

solver_actions = supported_action_types()
missing_actions = sorted(registry.actions - solver_actions)

if missing_actions:
    raise CapabilityMismatchError(
        stage,
        f"Stage {stage} exposes unsupported actions: {', '.join(missing_actions)}",
    )

That is a small defensive feature, but it prevents a misleading failure mode: “the strategy is bad” when the actual problem is “the game changed and the solver does not know a new action yet.”

⚖ 4. Build a local validator before trusting the network

The server should not be your debugger.

Sending a plan to a remote service is slower than replaying it locally. It also gives weaker feedback, may consume a limited attempt, and forces you to learn game rules through trial and error. I built a validator that replays the entire plan on a copy of the initial state before the client submits anything.

def validate_plan(initial_state: GameState, plan: list[list[BaseAction]]) -> GameState:
    state = initial_state.copy()
    if len(plan) > state.max_turns:
        raise PlanValidationError(
            f"plan uses {len(plan)} turns, limit is {state.max_turns}"
        )

    claimed = False
    for turn_index, turn in enumerate(plan):
        state.executed_turns = turn_index
        state.turn_start()
        for action_index, action in enumerate(turn):
            _validate_action(state, action, turn_index, action_index)
            action.apply(state)
            if isinstance(action, ClaimWinAction):
                claimed = True

    if not claimed:
        raise PlanValidationError("plan never claims victory")
    return state

⟁ Invariants I validated

⌖ A build is inside the board and does not overwrite an existing structure.
⚒ The structure exists in the current capability registry and is buildable.
◈ The base can afford the construction cost.
⛓ A newly built structure is adjacent to the existing network.
⚡ An extractor stands on a compatible resource node.
⌕ Every transfer step is orthogonally adjacent.
⏱ Transfer endpoints are storage structures; intermediate cells are transport-only structures.
♥ The source owns the requested positive amount.
⚙ A mine or producer is activated no more than once per turn.
★ Production has all recipe inputs.
⚖ The win claim targets the correct structure and the goal inventory is actually present.

For example, transfer validation is intentionally strict:

if action.amount <= 0:
    fail("transfer amount must be positive")

path = [_as_coord(coord) for coord in action.path]
if len(path) < 3:
    fail("transfer path must contain at least source, transport, and destination")

for previous, current in zip(path, path[1:]):
    if not _adjacent(previous, current):
        fail(f"transfer path has non-adjacent step {previous}->{current}")

❖ A validator is not an attempt to clone the entire server. It is a local contract for the mistakes that would otherwise be expensive to discover remotely.

⌖ 5. Search for a build route, then use it as a transfer route

Every expansion starts with a geography problem:

“How can I connect this target cell to the network without crossing forbidden terrain, structures, or incompatible nodes?”

I used breadth-first search for pathfinding. A candidate expansion stores the resource, its extractor type, full route, construction cost, the number of roads needed, terrain penalty, and expected rate.

@dataclass(frozen=True)
class ExpansionCandidate:
    resource: str
    extractor_type: str
    path: tuple[Coord, ...]
    cost: Inventory
    road_count: int
    terrain_penalty: int
    rate: int
    kind: str = "extraction"

The route has two meanings:

BASE ── road ── road ── EXTRACTOR
 ▲                           │
 └──── transfer path ────────┘

First it tells the solver which transport cells need to be built. After construction, it is a valid path for taking materials back to the base.

The strategy builds missing transport cells in order, then builds the extractor at the final coordinate:

for coord in candidate.path[1:-1]:
    if self.game_state.get_structure_at(*coord) is None:
        yield BuildAction(coord[0], coord[1], self._transport_spec.type)

node = candidate.path[-1]
yield BuildAction(node[0], node[1], candidate.extractor_type)

If the network is complete by that point, the solver mines and transfers in the same turn. This is a small but useful optimisation when the number of turns is tight.

⚡ 6. Start with a greedy strategy; keep a bounded search for when it fails

My normal turn-generation loop is deliberately easy to explain:

① ⛏ Mine from every connected extractor.
② ⛓ Transfer those resources back to the base.
③ ⚙ Feed and activate connected production structures.
④ ⌕ Find the best affordable expansion.
⑤ ⚒ Build its transport path and target structure.
⑥ ★ Claim victory as soon as the goal is satisfied.

This is the essence of the greedy part of the strategy:

if self.game_state.base.storage.at_least(self.game_state.goal_resources):
    yield from self._claim()
    return

for extractor in self._connected_extractors():
    path = self._transfer_path((extractor.x, extractor.y))
    if path is None:
        continue
    yield ExtractAction(extractor.x, extractor.y)
    amount = extractor.storage[extractor.extracted_resource]
    if amount > 0:
        yield TransferAction(path=path, resource=extractor.extracted_resource, amount=amount)

candidate = self._best_affordable_expansion()

Greedy planning is fast, debuggable, and usually good enough. But it has a predictable weakness: a locally cheap expansion can be globally wrong when the game has only a few turns remaining.

So I added a fallback: beam search.

initial state
   │
   ├─ mine / transfer resources available this turn
   ├─ generate several affordable expansions
   ├─ simulate each possible next state
   ├─ score the states
   └─ keep the best K branches  ◈ beam width
                              │
                              ▼
                         next turn

The solver does not enumerate every possible future — that would grow too quickly. Instead, it retains a limited beam of promising states. The score considers progress toward the goal, connected income, production output, remaining turns, recipe-input shortages, construction costs, and terrain penalties.

class GeneralStrategy(BaseStrategy):
    ACTION_LOOP_LIMIT = 250
    BEAM_WIDTH = 60
    BEAM_BUILD_DEPTH = 2
    BEAM_CANDIDATE_LIMIT = 12

This makes the algorithm pragmatic rather than academically exhaustive:

∞ Simple cases stay simple. Hard cases get more search only when needed.

For production chains, I also estimate capacity. If the existing factories and connected input sources cannot produce the missing output in the remaining turns, the solver prioritises a new input source or another producer before it is too late.

♻ 7. Tests were part of the solution, not decoration

I used compact synthetic levels to test the planning logic without needing a live server. The tests cover both positive plans and the rule boundaries that should fail.

def test_validator_rejects_invalid_transfer_and_double_mine() -> None:
    initial = GameState(...)

    with pytest.raises(PlanValidationError, match="insufficient STONE"):
        validate_plan(
            initial,
            [[TransferAction(path=[(2, 0), (1, 0), (0, 0)], resource="STONE", amount=6)]],
        )

    with pytest.raises(PlanValidationError, match="already mined"):
        validate_plan(initial, [[ExtractAction(2, 0), ExtractAction(2, 0)]])

✦ The suite checked

a single road and a quarry are built in the correct order;
a multi-road corridor remains connected throughout construction;
the strategy mines before expanding when the base lacks resources;
the cheaper resource node is selected first;
a road cannot be built on a resource node;
a transfer cannot send more material than the source holds;
an extractor cannot mine twice in one turn;
a premature win claim is rejected;
an invalid plan is never submitted through the CLI.

At the time of writing, the suite passes:

........                                                                 [100%]
8 passed in 0.91s

★ Tests do not prove that a solver handles every future game mechanic. They do prove that the rules I had already learned do not silently regress while I add the next mechanic.

♥ What I learned

Technically, I am proud of this solution. The task pushed me to build a domain model, separate server capabilities from decisions, replay plans locally, validate hard constraints, and combine a transparent greedy heuristic with a bounded fallback search.

It reinforced a principle I value in backend work:

⚙ When an external system has rules, create a local model of those rules before you automate decisions against it.

The recruitment experience added a second lesson.

Before I install tracking software, give a service screen access, or commit dozens of hours to a technical task, I will now ask:

⚖ Is this tool mandatory, and is that requirement explicitly called out?
⌕ What data does it collect and who can access it?
⌚ How long is the assignment expected to take?
₿ Is the work paid, and if so, under what written conditions?
⚲ Is there a way to use an isolated device, account, or virtual machine?
✉ What part of the evaluation is blocking: the output, the process, the tracker, or all of the above?
⟁ Can the employer provide a verified installation source and privacy documentation?

Those questions are not hostility. They are ordinary digital hygiene.

𝚏𝚒𝚗𝚊𝚕 𝚗𝚘𝚝𝚎

𝚃𝚎𝚌𝚑𝚗𝚒𝚌𝚊𝚕 𝚜𝚔𝚒𝚕𝚕 𝚒𝚜 𝚗𝚘𝚝 𝚓𝚞𝚜𝚝 𝚠𝚛𝚒𝚝𝚒𝚗𝚐 𝚌𝚘𝚍𝚎.

𝙸𝚝 𝚒𝚜 𝚞𝚗𝚍𝚎𝚛𝚜𝚝𝚊𝚗𝚍𝚒𝚗𝚐 𝚛𝚎𝚚𝚞𝚒𝚛𝚎𝚖𝚎𝚗𝚝𝚜, 𝚖𝚘𝚍𝚎𝚕𝚕𝚒𝚗𝚐 𝚌𝚘𝚗𝚜𝚝𝚛𝚊𝚒𝚗𝚝𝚜, 𝚟𝚎𝚛𝚒𝚏𝚢𝚒𝚗𝚐 𝚊𝚜𝚜𝚞𝚖𝚙𝚝𝚒𝚘𝚗𝚜, 𝚊𝚗𝚍 𝚔𝚗𝚘𝚠𝚒𝚗𝚐 𝚠𝚑𝚎𝚗 𝚝𝚘 𝚙𝚊𝚞𝚜 𝚊𝚗𝚍 𝚟𝚎𝚛𝚒𝚏𝚢.

The game was difficult. Solving it was worth the effort. And the experience made me a more careful engineer — not only when I design systems, but also when I decide which systems deserve my trust.