This week we had Ava Katushka, a coach at Verbetcetera .
Verbetcetera is a bootcamp for those looking to prepare for interviews in the Big Five - Google, Amazon, Facebook, Apple and Microsoft. Verbetcetera mentors are distributed in 5 countries, already work in target companies, they know everything about the specifics of work and requirements for candidates in different markets.
Despite the cold reception in the comments to the announcement, there were a lot of questions for Ava during the broadcast. We publish her answers, transcript and recording of the interview (with presentation slides).
My name is Ava Coil. I studied at the Moscow Institute of Physics and Technology, at the Faculty of Computer Science, which is called the FIVT. My third course was quite difficult, I had a lot of stress, exams, health problems, family problems.
I remember walking into a bookstore and seeing the book What to Dream About. I wondered; I remembered that I once dreamed about something, but did not remember what. I opened this book, and right there, at Biblio-Globus, I began to do the exercises from this book. And it turned out that I fulfilled the expectations of everyone around - my family, teachers, anyone except my own. I was very angry then. I wondered what I actually want myself. Later I sat in Gorky Park and thought about it. I realized that I want to travel, I want to make friends - I had a problem with that - and I want to write my own website from scratch. And for me, as if by magic, that year everything began to come true.
It turns out that there is a way to travel where you get paid for it: an internship. So I got to Google in New York, where I had an internship. Somewhere in the middle of the internship, I was asked if I wanted to stay fulltime. I thought - why not try, although I did not think that they would take me. But they took me, and I moved to Munich. I have been working as a software engineer for three years and have quite varied experience as a software engineer. At first, I worked and trained as SRI (site reliability engineer) - I did a lot of interesting things, there was a sister team. But soon it seemed to me that I wanted to write more code. I moved to the SVI team, where we wrote a travel site within the company itself, for googlers. And in the end, I also learned that there is such a specialty - UXE, UX engineer. I started to learn a little UX and moved there,trying to combine my two interests in drawing and programming. I turned out pretty average, but this is also experience in the field.
Now I don't work at Google, I kind of decided to take the time to find out what I like, to try all kinds of hypotheses. In particular, I wanted to try working for myself. I began to remember what I liked in life, and it turned out that I really liked the process of preparing for the interview. When I applied to different companies, I interacted with people from these companies, solved problems. It was a very bright period in my life. Then I talked with a friend and found out that not everyone has this period - bright, people are stressed at interviews, and then - "thank God, this is over, I am finally working." It seemed to me that I could probably share something positive, turn this process of job search and interviewing into something pleasant, something that is good to remember with pleasure.
At first I wanted to advise myself, but I found advice in a book on business: if you want to do something, first find people who are already doing something good, and you can learn a lot from them. Then I found the Verbetcetera company, where the guys were already doing what I wanted to do. There was already a circle of mentors; The software-engineering direction was quite fresh, that is, it only started in 2020.But since 2018 there has been a mentoring of PMs, which proceeded quite well. And the values ββof this company turned out to be very close to me: all the mentors have gone the way, they themselves work in the field. These were guys close to me in spirit, all were (and are) from FAANG (Facebook, Apple, Amazon, Netflix, Google). A very cool team gathered, it was interesting to join and try yourself as a mentor.
I would like to tell you about technology interviews, answer questions. I will talk about a certain structure in an interview, stop, look at the questions, answer and move on. I would like to talk about coding interviews: what questions are asked, what myths are associated with it, what the job search process looks like from the point of view of the company and the candidate; what is a system design interview, what does it affect and what myths and popular misconceptions are there.
Coding interviews - what are they?
It is often asked what questions are asked in such interviews. Let's say one of these questions can be like this: "an encrypted string arrives at the input, decode it." The line could be like this: 3 [A] 2 [BC]. Decoded as AAABCBC. That is, what is inside the square bracket is repeated as many times as the number before the bracket. And during the interview you need to write a program that does the decoding.
This question was actually asked in interviews with Bloomberg, Amazon, Apple, Cisco, Google, Microsoft; seems like a pretty straightforward question even if you are not related to programming. But it can have a double bottom - for example, there can be several levels of nesting. Let's say the following line: [[[A [[C]]].
In this case, you can first decipher the inner layer: AACC, and then repeat it three times - that is, decipher the outer layer (AACCAACCAACC). The written program should handle any level of nesting. If you're good at programming, this shouldn't be a problem.
What topics are asked in interviews?
Examples of popular topics are arrays, strings (as we have already covered), graph tasks. Sometimes they are heavily disguised: for example, to make a schedule of courses, given that each course has a preliminary course (prerequisite). There are recursion problems: for example, there is a popular price problem. The prices are given per share for a certain number of days, and you need to come up with a buy-sell algorithm for maximum income. Sometimes there are problems from mathematics or geometry, but there are not very many of them; no special knowledge in these subjects is needed, the most basic ones are needed, but they are also good at being able to solve them. In general, it is very good to have a foundation in computer science, to feel comfortable so that solving problems in interviews does not pose problems.
Why are these questions asked in interviews if the workflow is very different from them? Yes, many people say - the developer does not need this, why these black and red trees. This is the standard criticism of interviews, the work is really different, the work will not be like an interview. But there are many reasons why such questions are asked. They want to test you in a limited amount of time, to see how you cope with unfamiliar, incomprehensible tasks. Such a skill is often needed at work.
Although computer science in its purest form does not apply to work, basic knowledge is still quite useful when you work in software engineering. In fact, these tasks are a proxy for further work. Instead of asking if you are a good developer, they give you tasks and see how you behave with them. And good answers to questions correlate with being a good developer.
Which companies ask these questions in interviews?
Quite a lot, and not only FAANG (but they too). I have a list: Microsoft, Bloomberg, Uber, Adobe, Oracle, ByteDance, eBay, LinkedIn, Yahoo, VMWare, Salesforce, Cisco - in fact, I haven't inserted many of them yet. That is, such questions are quite popular. Moreover, for example, in Google, both junior, middle and senior developers receive the same questions, there are no differences.
There is a popular myth: is it important to participate in algorithmic competitions.This worried me greatly: I did not participate in them either at school or at the institute. People often say that if you did not participate, then your time has passed - you will always show yourself badly in interviews. But this is not the case. Despite the fact that, of course, participation in competitions will help and support you, interviews are different from them. The questions are similar, you also need to solve a problem in a limited time, but you present its solution not to the system that must pass the tests, but to the person. The person looks and tries to assess the solution of the problem, whether he wants to work with you. It is important not only that you find a solution, but also how you find it, how you thought, how many options you considered, whether you can convey them to the person. This is a very important aspect.
The person who interviews you is an engineer, he also does not solve such problems regularly; most likely the last time he did this was during his own interview. And he must find the answer to the question: does he want to work with you, will it be good to work with you. Don't be afraid of him. He doesn't want to put you under super stress conditions; instead, he wants to give you a positive interview experience.
A generic coding interview framework
How to structure your time, your response in order to respond well? To begin with, always ask clarifying questions, give examples, communicate with your interviewer. How do you understand what an example; it is very important.
Otherwise, you may completely misunderstand the problem and start solving the wrong problem that is required of you (this is a large number of red flags at once).
Often people are afraid to come up with the solutions they come up with; they think - why offer it, it is not optimal, but they want the optimal from me. Do not do it this way. Start with a non-optimal solution, tell the interviewer about it: he will understand that you have already reached some level of understanding. Then think further. Perhaps this will help you in some way in the process. There is no minus here: on the contrary, it is good that you immediately saw the solution.
It's important to write good, structured code - you want to show yourself as a programmer who writes readable code. At the end of the interview, it will be important to test, for this you can use the examples that were invented at the beginning. This is how you can catch errors in your code. Then - it is necessary to summarize pretty cool. "I started like this, I came up with such and such a solution, they have such and such advantages and disadvantages, this is the kind of testing, this is how everything works with examples." Here's an example of an interview approach.
Q: what level of English is desired?
It is advisable to speak freely in order to freely understand the interviewer and express your thoughts. Optional super-advanced, intermediate should be enough.
Q: what changes have been made to Google's typing compared to what is described in the Cracking Coding Interview?
Here you need to understand what exactly to compare with what. But I think the main thoughts from Cracking Coding Interview are still relevant today. Not that much has changed.
Q: where can I improve my technical English?
You don't even need technical English to pass an interview; you just need English, you need to be able to express your thoughts. You can train in interviews, with friends, special companies, if you want to learn how to speak in an interview.
Q: to what extent do tasks with leetcode reflect the current specifics of tasks that are asked in Google? Are the tasks from the last year, the year before last relevant?
Firstly, it is important for you that you have not seen the problem that you come across in the interview before. If the task is familiar, and you know in advance how to do it, then this will not help you. On the contrary, it will harm: it will be noticeable. You need to have an unfamiliar problem, but you need to solve many similar problems. Leetcode works well for this; if you solve problems on different topics, cover popular computer science topics - at some point you will be ready.
Q: what languages ββcan be used to solve a technical interview problem? I'm currently solving problems with leetcode in JavaScript, but I've heard that I need Python or C ++.
Any of these languages ββ- JavaScript, Python, or C ++ - will do, it doesn't matter. If you write in JavaScript, know it well, deeply, this is your language - then go for an interview with JavaScript.
Q: do you have an approach to correctly estimate the time for each task in an auto code interview when there are several tasks and a time limit?
I didn't quite understand this question. Well, yes, you need to solve many problems, if there is a time limit, you need to measure your strength with them.
Q: The tasks I faced in the Amazon and Google interviews required far from basic computer science.
Well, I call it basic. It seems to me.
Q: if junior and senior candidates are asked the same questions, how do they determine which grade to take a developer to?
This is not determined by the results of the coding interview, but by the results of the system design and behavioral interview.
Q: how is Google in general?
I like it. I had quite a valuable experience, I would not exchange it for something else. Pretty cool company, many offices in different cities. Probably, there are few such companies where you can work in Europe, America and Asia. There are many possibilities.
Next, I'll talk about preparing for an interview: how to prepare, how companies hire developers, how long it takes
At Google and many similar companies, the process looks like this. First you need to get noticed, go through the recruiter. Then comes the initial screening, where you are given 1-3 coding interviews - the very same questions that we discussed earlier.
If you passed this, then you go to onsite. There will be a large set of interviews, usually 2 to 4 coding, plus system design and behavioral. If you perform well on the onsite, then you get an offer. Google includes your salary, relocation bonus - moving payment. Often the offer will include the company's shares; I received an offer that included them - but not immediately, but after a year of work.
The first step is to make sure that you are noticed. I personally advise you to try to find someone from the company, to talk with people who are in the company. This will give you a little understanding of the company's internal culture. In addition, if you like each other, then the person who is in the company will be able to recommend you - statistics show that recommendations increase the chance of passing the first stage ("being noticed") by 8 times in relation to applications through the site. Well, for some, applications through the site work.
I advise you never to dwell on a particular company. You can never guarantee that you will get into a particular company. But, if you have a goal - to gain international experience, work in a large company, move somewhere, then this is definitely possible, and perhaps not in one company.
For the resume writing process, there are various small tips on how it should look and what facts to contain.
- brevity: fit in 1 page
- results orientation: describe your accomplishments - "achieved X by doing Y with Z"
- Data Orientation: Describe the scale of your projects - utilization, profit, etc.
- links: provide links to showcase your projects
- rating: ask someone to rate your resume before submitting
- fewer specialized terms: you need to be understood
But it is probably very important to say that it is rather difficult to do it alone. At least, it was difficult for me: you need to describe yourself, describe your achievements, make it in good language, understandable to another person. It's good to do this with a friend, a colleague; you can come to our mentor at Verbetcetera - try to make your resume so that it is easy to read and makes a good impression.
Further preparation usually consists of solving problems - for example, in the same leetcode - on different topics, in the language of your choice. It can be JavaScript, Typescript, C ++, Java, Python, and so on. Many languages. It's also great to have practice in pairs - doing practical interviews to train the process, this is called a mock interview. You can practice with friends, there are also special services; we also provide such a service - you can come and practice with a mentor. Also, you are trying to increase your chances of getting an offer by submitting to many companies. Go through the interview, and in the end you get somewhere (where you want, I hope); of course, for this scheme to work, it is important to have a good computer science foundation.
I interviewed several people who recently went to Google, and it turned out like this: one or two weeks is not enough for anyone. Nobody told me that they prepared for the interview in two weeks and passed. It often takes 2-3 months, and the person is engaged in 8 hours a day. And this still requires a foundation - from the institute, from special courses, so that such tasks are not completely new. Someone wrote on leetcode that the whole process took a year (though this person was working at the same time).
Q: what salaries are offered?
You can look at Glassdoor to see what salaries are offered by which company (on average).
Q: Do you have any mentors on the .NET stack?
It is as if we do not prepare in a specific language, we have mentoring on algorithms and system design. The specific language does not matter to us, we do not tighten the language.
Let's analyze the last interview - system design interview. What kind of interview is this, what mistakes and myths are there, and how to prepare for it.
This interview determines your grade in the company. It asks difficult open-ended questions. For example, "how would you write Google Docs (or Instagram, or Facebook Messenger)." Naturally, there are different expectations for a system design interview: if you are a junior, almost nothing is expected of you. But, if you are senior, you have to prove yourself great.
I have met such an opinion that it is useless to prepare for this interview: either you already have knowledge and experience, or you do not. Of course, knowledge of system design does not appear on its own with the accumulation of experience (although experience helps), but I would recommend everyone to prepare for this interview - including junior.
Structuring the experience helps a lot. You begin to see outside your small piece of code, see the components, see the whole process, how the product looks like, what servers, load balancers, caches it consists of, where bottlenecks and vulnerabilities in this product can be, how it can be extended, what do if it grows. Preparation for a system design interview helps to grow as a developer; it significantly affects the offer and position. If you are essentially a senior or a good middle man, but you are not preparing, then you will probably be taken to the junior position, and you will have to go through the promotion process inside the company - peer review confirmation and everything else in order to come to the position that you already have. possibly borrowed from another company. Therefore, it makes a lot of sense to prepare in order to save yourself time and get a great offer right away. Of course,offers for senior and junior positions are very different - in Google it is tens of thousands of euros.
Preparing for a system design interview is much more difficult than preparing for a coding one. There is no test system that will tell you what was right and what was wrong. It's important to have someone (usually some senior developer) to give you feedback on how adequately you answer questions. It's great to have a structured knowledge base and practice a lot in pairs. You can come to the system design mock interview, which we do at Verbetcetera. We are also thinking of doing a system design course someday.
The general framework for how to behave in a system design interview is very similar to that for a coding interview. There is no need to rush at the beginning, you need to ask clarifying questions, try to understand what the task is. You never need to immediately start solving or give some answer that you remember from some site; Perhaps you and the interviewer have completely different tasks in your head - it is important to agree on this initially, to pay a lot of attention to communication and understanding. The second step after agreeing on the task is to draw a high-level design for the task, and agree on that too. After that, you need to discuss what problems may arise in this design, what is most interesting in it, and plunge into the most important and interesting problem. At the end of the interview, you need to go through it again, summarize your decision and offer some ideas about howwhat else can be done and improved. And all this needs to be done in 45 minutes (even less, because there are all sorts of technical hiccups) - it is very difficult to do it on the go, you need to prepare.
Q: Are there profiles of all mentors somewhere?
We are not doing this openly yet. For now, I can say that our mentors have worked (are working) in FAANG and are not very interested in talking openly about themselves. It may be a little confusing, but such a question of anonymity.
Q: in what areas does the mentor evaluate? Only programming skills, or else English and self-presentation skills?
You are judged by your programming skills, your ability to solve problems; English should be sufficient for communication (no super-level needed). Self-presentation probably influences too, but not so much. Probably, how much you are an adequate person influences more? If you come to a behavioral interview and say that you hate clients, you probably won't be given an offer, despite your self-presentation skills.
Q: if senior has failed system design, is he offered a middle / junior position?
Yes, usually they just downgrade. This is a common situation: senior simply does not prepare for system design, fails him, and he is offered a starting position. But, of course, if a person really has a level, then he can grow faster than usual within the company. It will be a little offensive, of course, that they did not take on senior right away after the interview.
Q: Do you have these mock interviews on design in Belarus (I didnβt catch the name, where and how they are held, can I have a more precise link?) In English or Russian? In general, what countries do you have mentors?
All mock interviews are in English, because in reality they will be in English. Mentors are distributed; I am in Russia, most of them are in Europe, in England. Quite a scattered company from different parts of the world. The link will probably be in the video description.
Q: will it be possible to download the presentation?
I don't think so, but you can watch it in the video.
Q: mock interview online or offline for Muscovites?
We have not thought about the offline option yet, while everything is online.
So, today we discussed the coding interview - what questions are asked, popular mistakes and myths, how to prepare, how long it takes (so that you are realistic about the process and don't think that it takes everyone only 2 weeks). And system design - why prepare for it, and how it will help you.
I also wanted to make an announcement. We want to recruit a course: if one of the guys wants to understand the algorithms that are needed for a tech interview, we have been recruiting groups since March. The groups are small, 3-5 people or less (almost one-to-one), to work with mentors from FAANG. Over the course of three months, we will go through all the basics you need to prepare for a technical interview. So that if you feel that you are sagging on this topic, you finally have a good foundation, and you feel confident. This is especially suitable for people who cannot allocate full time to prepare for interviews who are actively working - this course format may work.
And if you have an interview soon - come to us for a mock interview. By algorithms, by system design; when we do it, there will be a course on system design. I will be very glad if you come.
Q: will there be more kits, for example, in May?
Maybe. While the plans are for March, the courses will run for three months; if the results are good, if we and you like it, then maybe there will be another set.
Get ready, invest in yourself and your knowledge. You are all great, you will succeed.