Payme — Backend Engineer

The interview opened in Russian, then moved fully into English for the live coding. I introduced myself and talked through two projects: a dashboard for small-to-medium organisations that scans uploaded files and URLs for malware, and a Telegram bot that pulls videos from social media by URL and trims them, which I was extending with AI-generated subtitles from the audio. The coding was done in a shared editor with no ability to run or debug anything. The interviewer described it as "not just live coding, it's live thinking", and said to treat it like writing on paper. Task 1 was a card expiry parser. The input could arrive month-first or year-first and might contain noise, since the premise was that it came from a camera scan. I parsed it by converting the first part to a number and checking whether it was less than 13 to decide whether it was the year. That handled the common cases but broke down under questioning: they pushed on 1111, then 0100, and I had to work out that 00 can only ever be a year, because there is no month zero. I filtered non-digits by ASCII range — I asked for the values of 0 and 9 and was told 48 and 57 rather than being allowed to look it up. They then asked me to rewrite the parsing with array methods instead of manual splitting. Task 2 was a time-difference formatter: two millisecond values in, a zero-padded minutes-and-seconds string out. This is where it went wrong for me. I built an over-complicated solution with while loops accumulating seconds from both arguments, then padded the output with string length checks. The interviewer walked me back through it question by question — "why are you adding this here", "why do you need the sum", "what does the task actually ask you to return" — until it became clear that I had misread the requirement. I had been summing the two arguments when the task was the distance between them. Most of the code I had written did nothing. I said so directly, and the interviewer's response was that they knew interviews can feel rushed and that it was fine. I also admitted mid-interview that I was anxious and struggling to think clearly, and they told me it was okay and to take my time. Time ran out before the third task. They said feedback would come from HR within the week. The outcome was a rejection.

Practical things worth knowing before interviewing here: - You cannot run your code. No debugger, no console, no output. Every trace has to happen in your head, out loud. Practise this specifically — it is a different skill from normal LeetCode. - No Google and no ChatGPT. This is stated explicitly at the start. You can ask the interviewer instead, and they will answer factual questions such as ASCII values. - Edge cases are the actual test. The first task looked trivial and turned into twenty minutes of 1111, 0100 and 0001. Do not say "handle it however you like" — they will keep pushing until your rule is precise. - They ask "why" repeatedly. Not to trap you, but to find out whether you understand your own code. If the honest answer is "because I was rushing", saying so is better than inventing a reason. - Re-read the problem statement before you write anything. My whole second task went sideways because I solved for the sum of two values instead of the distance between them. Ten seconds of re-reading would have saved forty minutes. - This was a mid-level backend Node.js interview, but neither task was backend-specific: no databases, no API design, no system design. Both were plain JavaScript problems about parsing, edge cases and reasoning about your own logic. - Expect roughly 1.5 hours, and expect to be tired by the end.