How I Went Through a Tech Interview and What Changed Over the Years
Yesterday I was invited to a tech interview at a major company for a Lead Frontend Engineer position. The last time I went to an interview was three and a half years ago, and since then it's been nothing but work and constantly learning something new.
If you read my blog, you can see that I've shifted heavily toward vibe coding and agentic coding. I've practically stopped writing code by hand — just reviews and recommendations to the agent. Architecture descriptions, skills, and an almost complete focus on the product, rather than on how to write custom hooks or describe data types in TypeScript.
It became possible for me to build products not just in JavaScript. I started actively using Python for backend, GitHub Actions for deploying to AWS, spinning up my own LLMs instead of using the OpenAI API, and setting up RAG systems.
Over the past six months I launched Videamind.com, UptimeHarbor.com, RePeaks.com, AreteBrain.com, ArsVarius.com, and prepared PeerMeet.me for launch. These are all fairly complex projects with non-trivial architecture — although, as always, I might be embellishing my talent a bit.
Imagine my surprise when the tech interview turned out to be exactly the same as the ones four — or even six to eight — years ago. And that made me think: what's the point?
Nobody cares how well you play Factorio, just like nobody cares about your skills configuring Claude Code or Cursor.
It's not that I didn't prepare for this interview. I spent a whole week of my free time using Claude Code and ArsContexta in Obsidian to create notes on fundamental knowledge and a standard interview plan. I even read through some of it. But all of that was just collecting knowledge.
In practice, on the last day, I decided to ask ChatGPT to quiz me on the most basic questions about JS, React, and TypeScript — and suddenly realized that reading and "possessing" some knowledge is not at all the same as answering a question, even in your own words.
I believe ChatGPT turned out to be extremely useful in this context, and I regret not adopting this practice a long time ago. So I recommend doing it more often — and not just for passing interviews, but simply for refreshing knowledge that we think we possess. On the surface, it might be the Mandela effect, and could become the cause of more serious misconceptions in practice.
I'll say it straight: overall, they rated me at a Middle level.
The most important conclusion I drew for myself: when I thought that being a lead is about architecture, about managing a team, tasks, and the product, I missed the fact that first and foremost, a lead should suggest technical solutions and mentor others — and I still have plenty to learn myself.
And yes, I have to admit: vibe coding leads to degradation. You can't offload everything onto the machine and let your own brain go slack.
You don't need to train for interviews — that's like memorizing openings in chess. What you need is practice, even if it's just with AI. Use it not only for writing solutions for you, but for maintaining knowledge and training. Make it not just a coding assistant, but a mentor — and perhaps that will bring no less value than simply having it do your work.
All in all, the detox from vibe coding has begun — I wrote this post in my own words, also for the first time in a long while. I'd be grateful if someone invites me to a mock interview sometime, for practice and to see whether I've actually learned from this experience.