About
I started with competitive programming, and it shaped how I think about software more than any course did. You write a solution, you submit it once, and a judge you can’t argue with tells you whether you thought of everything. After a few hundred rounds of that, looking for the case that breaks your own work stops being a step and becomes a reflex.
That reflex is what made me useful in QA. I joined Doin in February 2026 as an SQA Engineer on a platform that distributes trade signals to broker integrations in near real time — a domain where a silent failure is worse than a loud one, and where “it seemed to work” is not a result anyone will accept.
But I kept writing code, because the interesting problems kept turning out to be engineering problems. The regression suite needed to be a real framework, not a pile of scripts. A slow third-party call was blocking the request path, so I built and deployed a Django service to move it off. HR was tracking monthly submissions by hand, so I built the app they now use for it. Each of those started as something I noticed while testing and ended as something I shipped.
That’s the version of engineer I’m becoming: someone who builds the system and can prove it works. In fintech those two things are not separate jobs, and I’d rather be the person who does both than the person who hands off at the boundary.
Right now I’m going deep on Django, Docker and AWS, and moving more of my testing work into code. Outside of that I’m still solving problems on Codeforces, mostly because I like it.
How I work
- Read the failure case first.
- The happy path is the part everyone tests.
- Make it observable before making it fast.
- A system you can’t see into can’t be improved, only guessed at.
- Prefer boring infrastructure.
- Postgres and a queue solve more problems than most architectures.
- A flaky test is worse than no test.
- Trust in a result is the whole product.