TBC x payme Office Tour

Our office tour is live! Check out TBC x Payme Office Tour to see where your everyday-use products come to life

digging into Leetcode lately — thought I'd share this resource in case you need it

https://leetcodetherapy.com/

Trying despite disbelief

I am very good at finding reasons why something will NOT work out, and pessimistically hyper-focusing on them. In my past they were enough to immediately give up on an idea. One thing that my wife taught me is what I call trying despite disbelief.

I think the first time it happened was ~9y ago. The company I worked for made me a H1B work visa and offered $56k/year salary. I took the deal without negotiations and moved to the US. When my wife, girlfriend at the time, heard that my salary is just $56k, she was like "WTF, they low-balled you, go and ask for 20% more". I laughed because nobody gets 20% raises, but she convinced me to TRY. I went to my boss and asked for 20% raise with zero belief that I will get it. The funny thing is, when I try I appear like I know what I am doing, smiling and such, and what do you know, to my surprise I got ~15% increase.

Another time I left my backpack with a laptop in a coffee shop. I called them up and they said they don't see one. Past me would give up, because I got a pretty strong signal that it isn't there. By that time I already had a few experiences where trying helped, so I simply drove there and there it was, on the floor. I don't know how they couldn't notice it.

There were many other examples. Some still required encouragements by my wife and others, like trying for L7, and asking for more money. Another example is me accepting the L7 high-risk high-reward offer -- I'll do my best and hopefully survive. Even publishing this post is an example -- the reason not to post it is that this is possibly bullshit.

---

I am not saying that it will help everyone, but it might certainly help those competent but not confident. Quoting Wikipedia "The Dunning–Kruger effect is a hypothetical cognitive bias stating that people with low ability at a task overestimate their own ability, and that people with high ability at a task underestimate their own ability" (I encourage to read the rest of article). If you believe you belong to the second group, or sometimes you find yourself thinking "if even he/she did it, then I should be able too!", then it might help. Or if you are a woman, because the ever-present patriarchy makes you feel small.

A part of this is accepting a possibility of failure. In fact, I usually go with low expectations and just do my best. If you fail, that's OK. It isn't the end of the world.

Another thing is, you might luck out. An interviewer might not ask you topics that you are weak at (I am weak at parsers). In my Google interview I wasn't prepared for system design. I failed one; the other was quite algorithmic (=easier) and the interviewer was from Android (not working distributed systems themselves), so I got lucky. You cannot get lucky if don't even try 😉.

Like I said, I tend to hyper-focus on reasons why something will NOT work out, in a pessimistic way. While it is discouraging, it also guides me to work on the weakest parts. If you think about chances of success as a confidence interval, then working on the weakest parts maximizes the lower bound. You can see an example of this in my obsessive preparation for the behavioral interview which I never did before and which isn't very technical. This attitude also poses the question "What am I missing?" and you can see an example of this in researching my Microsoft interviewers and discovering new topics to learn. Thinking how a system might fail (failure modes, unhappy cases) is one difference between L4 and L5.

Overall I can say that this simple technique made a big difference in my life. The first step is the hardest.

I recently wrote an article on a topic that often seems simple but can become a real performance challenge: working with lists in web development.

It covers key concepts like virtual scrolling, infinite scroll, and how proper keying can make a difference — with practical examples for both React and Angular.

Would love to hear your thoughts or experiences around this too

https://medium.com/@mansurisakov.dev/working-with-lists-in-web-development-performance-patterns-and-examples-0ccdaaea34d5

Working with WebView looks easy — until you're deep in edge cases, routing issues, and native-web sync problems.

At payme, I dealt with all of that while building avia & tickets. I recently wrote a post breaking it down:
– When WebView makes sense (and when it doesn’t)
– Problems we faced in production
– Communication between native and web
– UX nuances, routing, and lifecycle quirks

Wrote it in two versions:
📎 Habr (RU): https://habr.com/ru/articles/919856/
📎 Medium (EN): https://medium.com/@mansurisakov.dev/from-browser-to-app-the-inner-workings-of-webview-10aea73dcf86

Might save someone a few hours of debugging — or help decide if WebView is even the right call.
Happy to hear your take too.

I intently follow and read posts by Diyorbek. Recently, he released a podcast on Frontend System Design, covering all the important aspects and providing clear, concise insights on each topic.

https://www.youtube.com/live/Pcxs07g-xVU

Interviewing at Bloomberg (Prep Doc)

https://drive.google.com/file/d/1UoL6q5egwXLpinWqivmSPG_YstfGLBur/view?pli=1

recently, I started taking Matt Pocock’s course “Claude Code for Real Engineers”. the idea I liked is that when working with coding agents, engineering fundamentals become even more important. It’s less about writing every line of code yourself, and more about clearly defining the task, guiding the process, and checking the result. I want to start a small series of posts about engineering concepts that I use in my work and life.

the first one is Red-Green-Refactor.

Red-Green-Refactor comes from TDD — Test-Driven Development. It is a simple cycle: first, you write a failing test (Red), then you write the minimum code to make it pass (Green), and after that you improve the code without changing its behavior (Refactor).

what I like about this idea is that it makes you think about the expected behavior before implementation. You first define what the code should do, what cases it should cover, and how you will know that it works. Only after that you start writing the solution.

i found this useful in many cases: at work, in pet projects, and also during interviews. For example, when you have a live coding session, it’s often better to start with test cases. It shows the interviewer that you care about quality and edge cases, and the session goes smoother because you already have a clear picture of the problem in your head. You are not randomly trying to solve something, you are moving step by step: define the behavior, make it work, then improve it.

i think this approach becomes even more important when working with AI coding agents.

the second concept i liked is Tracer Bullets that comes from Progmatic Programmer.

most LLMs tend to code horizontally. they build layer by layer: first models, then services, then UI, and only at the end you see if everything actually works. it can feel productive, but the problem is that feedback comes too late.

tracer bullets push you to do the opposite: build a small vertical slice that goes through the whole flow. not the final version. not the perfect architecture. just one thin path that works end to end.

for example: one screen, one API call, one database operation, one result back on the screen.

what i like about this idea is that planning becomes more grounded. you are not trying to guess everything in advance. you quickly see the real problems: missing requirements, unclear data, wrong assumptions, integration issues.

after that, it is much easier to plan the next steps.

i think this is especially useful when working with AI coding agents. instead of asking an agent to build a big feature at once, i prefer to start with a tracer bullet first.

small working flow → feedback → improve.

it keeps the agent on track, and keeps me in control of the direction.

here is do-work skill example by Matt:
https://github.com/ai-hero-dev/cohort-003-project/blob/live-run-through/.claude/skills/do-work/SKILL.md