Angular’s Minko Gechev: I Still Experience a Rush of Dopamine When I Complete a Challenging Project

We talked to Minko Gechev, an Engineer from Angular core team at Google, a man behind Codelyzer, Guess.js, and Revive.run, and an author of the bestselling book, “Switching to Angular”

In his interview with JS Nation, Minko Gechev tells us the story of how the love for astronomy led him to programming and software engineering, how he moved out from Bulgaria to Silicon Valley and landed a job with Google, how he worked on his master projects, Codelyzer, Guess.js, and Revive.run, predicts the future of machine learning, and gives advice on how to get into Google.

Hello Minko, and welcome to the interview with JS Nation! Can you share your story? How did you get into programming?

In high school, I was very interested in astrophysics and software engineering. Back then, it wasn’t an easy choice which path to take because I was very passionate about astronomy. I used to spend a lot of sleepless nights observing the stars with my telescope and do various calculations and reports.

In the same time, I was participating in school software engineering competitions where I had to develop a system and present it in front of an audience. Later, a jury of experts had to evaluate the work of all participants and pick the laureates. When I had the requirements for the system in my head, I was getting obsessed until I had it up and running. I remember spending tens of hours writing code for my projects. Later, having the functioning system, I was feeling so proud of myself! I still experience the same rush of dopamine when I complete a challenging project.

Having the opportunity to create something new from scratch, just by using my laptop and my imagination tilted the scales towards pursuing a degree in computer science.

How and when did you relocate to the US? What were your first impressions from Silicon Valley?

I’m originally from Troyan, Bulgaria where I spent my childhood. For college, I moved to Sofia, Bulgaria. There, I also took a few engineering roles before I became a freelance consultant. Few years after that, I moved to Silicon Valley where I joined the venture capital fund Learn Capital, where I was doing technical consultancy for different portfolio companies. In Learn Capital, I had the chance to meet a lot of brilliant people and learn a lot. Together with a few of them, we founded Rhyme.com, a startup focused on online learning.

Silicon Valley is full of creative people. The atmosphere is definitely unique — during a walk in the park, you can hear people discussing immutable deployments or recurrent neural networks. On every corner in SoMa in San Francisco, you can find a different startup.

Thanks to open source and conferences, even before I moved to Silicon Valley, I already knew people here. Later I started organizing Angular San Francisco, so my transition was pretty smooth.

How did you get into Google? What advice can you give any aspiring programmers who want to work for Google?

Since I moved to Sofia, I was actively working on open source projects and giving a lot of talks about JavaScript, Angular, software engineering, and computer science. Some of my projects got popular and awarded by Google and the President of Bulgaria.

That’s how I discovered that my real passion is building tools for developers. Reflecting on this, I decided to leave Rhyme.com and pursue a new career path as an engineer in the Angular team at Google.

The process of joining Google is standard — a recruiter reaches out to you, you go through a series of interviews, and finally, there’s the team matching process. The interview process is mandatory for everyone to enter the company. Although sometimes there are excellent candidates who do not pass the coding questions, the process makes sure that the people who join have some required qualification to pass the entrance bar.

If you are interested in a particular team, the way I was interested in working with Angular, things are a little bit more complicated. In such cases, I’d strongly recommend you to collaborate with the team as an external contributor — this is especially easy if they are doing open source. You can pick an issue on GitHub and start working on it, help with documentation, etc. This way, even before joining the company you can evaluate if the team you’re collaborating with is a good fit for you and vice versa.

For example, I’ve been collaborating with the Angular team at Google for about 3–4 years before I joined. I did this in different ways — writing blog posts on content related to the framework, creating open source projects, fixing issues, etc. The team was familiar with my work, so they were interested in working with me. After I scheduled my interview, I spent 2 months preparing by solving 3–5 algorithmic questions a day. It’s important to set a deadline by scheduling the interview, otherwise, naturally, you discover more and more things you can learn, so you end up postponing the process indefinitely.

Can you tell us more about your projects?

Codelyzer is similar to eslint with the difference that it can analyze Angular templates, styles, and expressions. The project helps people catch bad practices and mistakes during development by analyzing their applications. Once I built the first version of codelyzer, the Angular team was interested in using it as part of the CLI because they saw the potential to improve the development experience for their users. Back then I was not part of the team — Google being interested in using my project was a massive thing for me.

Guess.js is a tool for predictive prefetching for web applications. In essence, it looks at your Google Analytics (or another analytics source) data, builds a simple predictive model and inserts a small piece of JavaScript in your application. While the user is navigating inside of the application, Guess.js “guesses” where they may go next and prefetches resources. Addy Osmani presented Guess.js during his talk on Google I/O 2018. Currently, Gatsby.js uses the tool for predictive prefetching in their documentation.

In Rhyme.com we used Go for the backend. I like guarantees enforced by static checks, so I built a framework for static analysis of Go applications to help us enforce best practices in our codebase. Later I open sourced this project and called it Revive. It has over 50 configurable rules which can statically analyze a project. It turned out there was a need for such a linter in the community so Revive got a broad adoption.

Since your most recent projects are concentrated around predictive analytics, do you think the use of machine learning to improve user experience can eventually lead to a change in the behavior of the users themselves?

Yes, using different machine learning techniques we can improve the UX dramatically. We’re still early in this but imagine how powerful it’ll be if everyone gets personalized experience for each individual web application. This is applicable not only for web performance but also design, page layout, etc.

Of course, at the same time, we should respect users’ privacy. There’s a very delicate boundary that we should not cross in our effort to provide better services for the end users.

What’s your opinion on the variety of solutions for the frontend in the coming years? Do you think these solutions will fiercely compete with each other?

I see a variety of different approaches for building applications, development of user interface, development tooling, etc. It’s inspiring to see how open source empowers us to learn from each other and grow our products consistently.

What are you currently working at in Angular and what future you can predict for this framework?

Currently, we’re working on our new rendering engine and compiler Ivy. It will make the framework a bit more dynamic and generate source code which is easier to optimize by modern bundlers and JavaScript virtual machines. We want to keep the APIs backward compatible, which is our top priority.

In the same time, we’re making a lot of improvements in the CLI. We’re working with Bazel to allow large projects to have the same development experience with fast round-trip time as small applications.

What was your most recent talk about?

My last talk was about predictive prefetching. I explained the idea behind Guess.js and how we can use it to build faster Angular and React applications.

Why did you decide to write a book (which would later become a bestseller) on Angular? Do you plan to publish other books?

Miško Hevery is one of the engineers I’ve learned the most from. For years I’ve been following his blog, talks, open source projects, etc. Once Packt Publishing told me that I’ll have the opportunity to work with him on the book “Switching to Angular” I immediately agreed to write the content.

Writing a book is a fantastic experience, which in the same time takes a lot of time and effort. I don’t see myself working on another book in the next couple of years. Maybe at some point, I’ll write a content closer to theoretical computer science, but I don’t have a concrete plan yet.

What do you do in your free time?

I’ve been doing karate for about 20 years. A few years ago my priorities shifted a bit so I stopped competing but I still workout regularly.

Currently, I spend most of my time in San Francisco. I love exploring the different neighborhoods, they all feel entirely different and gorgeous.

I also have an interest in theoretical computer science. Over the weekends I spend some time reading articles about computational paradigms and incremental computations.

Are you excited about the upcoming JSNation conference in Amsterdam this year? What are you going to talk about?

I’m very excited about JS Nation in Amsterdam! It’s in one of my favorite cities in Europe with a fantastic lineup!

During my talk, I’ll give an overview of what we introduced as part of the CLI. I’ll also share some general practices that developers can use to improve the performance of their applications.



The interview was prepared with the assistance of Marina Vorontsova, a copywriter from Soshace.com. Soshace is a hiring platform for web developers: hire a developer or apply for a remote job.