Potapova Anna

Backend • Middle • Novosibirsk, Russia • UTC+07:00 • In office, Partially remote, Fully remote • Relocation • Work permits: Russia • Available in 2 weeks

ML Engineer

4+ years exp

Python

Java

C++

SQL

Scalability & Performance: 5/10

System Architecture: 5/10

API Design: 4/10

Invite to interview

Download CVCV

Overview

Technical skills

Timeline

Roles

Overview

A backend-focused engineer with strong hands-on experience implementing distributed-consensus components and a second skillset in Java-based multiplayer game code; the Raft roles, transport layer and custom storage provide the strongest proof. The clearest proven skill is building a Raft implementation with concurrent replication and HTTP-based RPC, evidenced by core role implementations (leader/follower/candidate), transport sender/receiver and storage (LockStorage). The public code does not show production-grade API governance, authentication, metrics/observability rigs, or integration with durable databases and migration histories.

Phone

Technical skills

Languages

Python

Java

C++

SQL

AI/ML

YOLO

CatBoost

Dagster

LightGBM

DVC

RAG

Claude

LLM

LangChain

LangGraph

PyTorch

Scikit-learn

ChatGPT

VLM

Stable Diffusion

DevOps

Docker

Git

Kubernetes

Databases

Qdrant

PostgreSQL

ElasticSearch

MongoDB

Other

FastAPI

Requests

PyTorch C++

MLFlow

Grafana

Uvicorn

CLIP

Label Studio

Rest API

Claude Code

Poetry

ComfyUI

Computer Vision

NLP

Reinforcement Learning

Digital Twin

Timeline

Software Engineer / ML Engineer • Middle

True Engineering • Full-Time

Jul 2024 to Present 2 Years 3 Months Novosibirsk Partially remote

Worked on ML and CV tasks across STT and speech interfaces in R&D, then moved to the ML team. Led and delivered multiple parallel ML projects in production, including object detection and document/image processing pipelines. Participated in presales estimates and architecture planning as part of partial team-lead responsibilities, and implemented agent-related work using agent frameworks. Built reusable internal ML components and contributed to model deployment workflows.

YOLO

Qdrant

Dagster

CatBoost

LightGBM

DVC

RAG

Seminar Lecturer • Middle

Novosibirsk State University • Part-Time

Sep 2025 to Jul 2026 10 Months Novosibirsk In office

Taught the course on developing a software-hardware complex and supported student teams through the semester. Coordinated multiple teams, acting as both a PM and an ML-domain contributor. Guided project work including an RAG-based bot integrated into the university admissions workflow.

Novosibirsk State University

Bachelor's Degree • Computer Science and Systems Engineering

2025 Novosibirsk, Novosibirsk Oblast

Engineer-Programmer • Middle

Institute of Automation and Electromeasurements of the Siberian Branch of the Russian Academy of Sciences • Full-Time

Nov 2023 to Jul 2024 8 Months Novosibirsk In office

Designed a modular system architecture for measuring and testing detector characteristics before sales. Implemented a FastAPI-based server for storing test results and configured deployment tooling using Docker and Python environment tooling. Coordinated a small development team and drove implementation of the system’s extensible test-set approach.

FastAPI

Docker

Middle Backend Developer Confidence: Medium Distributed Systems

API Design

4/10

How well APIs are designed

Practical HTTP API endpoints and client/server RPC for Raft are implemented (FastAPI + HTTP sender/receiver) with basic error handling and status codes, but there is no explicit versioning strategy, idempotency key handling, or formal API contract beyond ad-hoc headers (TTL/Version).

Evidence

BuDum-Tss/PyRaft/pyraft/transport/receiver.py: FastAPI receiver endpoints (append_records, request_vote, set_value) BuDum-Tss/PyRaft/pyraft/transport/sender.py: HttpSender methods append_records/request_vote/set_value with timeouts and response handling BuDum-Tss/PyRaft/lock.py:_compare_and_swap - HTTP-based compare-and-swap using TTL header and Version response

Data Layer & Database

4/10

Working with databases

Custom in-memory SyncStorage and a LockStorage show awareness of versioning, TTL and compare-and-swap semantics; there is no evidence of schema migrations, durable DB integrations, or careful isolation-level management.

Evidence

BuDum-Tss/PyRaft/lock.py:LockStorage implements get_value/get_version/update with TTL timers and version bookkeeping BuDum-Tss/PyRaft/pyraft/core/roles/leader.py:set_value appends records to the Raft log and consults sync_storage for value/version BuDum-Tss/PyRaft/pyraft/transport/sender.py:set_value returns Version header and HTTP status mapping

Scalability & Performance

5/10

Handling load and speed

Concurrency and scalability considerations are present - leader uses ThreadPoolExecutor to push log entries in parallel and roles use thread/events - but there are no load-testing artifacts, cache strategies, or sophisticated backpressure/rate-limiting patterns.

Evidence

BuDum-Tss/PyRaft/pyraft/core/roles/leader.py:send_changes and use of ThreadPoolExecutor for parallel replication BuDum-Tss/PyRaft/pyraft/core/roles/candidate.py:_request_votes uses ThreadPoolExecutor to parallelize RPCs BuDum-Tss/PyRaft/pyraft/transport/sender.py:uses requests with explicit timeouts and logs connection failures

System Architecture

5/10

Overall system structure

Reasonable modular decomposition for a Raft implementation (core roles, transport, node, storage, api) and a separate Java module for a multiplayer game show purposeful boundaries; the architecture is medium-complex and pragmatic rather than opaquely microservice-y.

Evidence

BuDum-Tss/PyRaft/pyraft/core/*: clear separation of Role, Candidate/Follower/Leader implementations BuDum-Tss/PyRaft/pyraft/transport/*: transport layer separated into sender/receiver Foxtezy/DeadInByte/src/main/java/ru/nsu/fit/dib/projectdib/newMultiplayer/*: multiplayer context (EntitySpawner, ServerState, ClientState) separated from game UI/logic

Security & Auth

2/10

Protecting data and access

Minimal security controls - the code uses owner fields and TTL for CAS semantics but lacks authentication, authorization, and hardened input validation for network endpoints.

Evidence

BuDum-Tss/PyRaft/lock.py:_compare_and_swap includes owner field but no auth BuDum-Tss/PyRaft/pyraft/transport/receiver.py:FastAPI endpoints accept requests but no authentication middleware is evident

Reliability & Observability

4/10

Stability and monitoring

Observability and reliability basics exist - structured logging, timeouts and heartbeat/heartbeat-wait logic across Raft roles are implemented; retries/backoff, metrics, distributed tracing and jittered retries are not present.

Evidence

BuDum-Tss/PyRaft/pyraft/log.py:set_logging and pervasive logging in role implementations BuDum-Tss/PyRaft/pyraft/core/roles/leader.py and follower.py:heartbeat/event handling and waiting logic BuDum-Tss/PyRaft/pyraft/transport/sender.py:explicit timeouts and ConnectionError handling

Verified artifacts

PabloBullies/Mockitty• ★ 3 Bibliophilia/bibliophilia• ★ 2 PabloBullies/StudyConnectMaster• PR

Expertise

Python• Middle

Java• Middle

Industries

Gaming• Middle

Technologies

Python• since 2022 • Middle

Java• since 2023 • Middle

FastAPI• since 2023

Uvicorn

Requests

Recommendations

Lead development of cluster coordination and consensus components (Raft-based features, leader election, replication) - implement and harden set_value/CAS flows.
Build reliable networked services and real-time multiplayer backends - design the server-side networking (connection handling, authentication, rate limiting) for game/multiplayer use cases.
Extend the current system with production-grade observability and security - add metrics, structured traces, auth, and retry/backoff policies for RPCs.

Repositories

The developer's experience in this domain has been verified based on AI analysis of the following repositories:

DeadInByte PyRaft