this person doesn't know how to write a loop, and so it's going to be a long 35 minutes.

was how I mainly interviewed people. I didn't even necessarily expect them to give the perfect answer. I was willing to give people hints. I was willing to, like, tell people, Hey, can you just walk through this code, check if there's any bugs, and stuff like that. I was very much like helping people, and almost nobody passed the interviews that I gave. I think my interview tried to help so much during the interview, and that was an issue. Every time that I was in line of thought, he pushed me to another direction. I couldn't follow up. Yeah, I think that's fair. I think I've had a similar interview. The interviewer talks too much, and I think that can kind of get annoying and distracting. I don't think I did that, though. I didn't really talk a lot during the interview. I would just mostly be silent, and if there was a long silence or if the person asked me a question, I would try to help them out. But yeah, you'd be surprised how little interview training there is. You go through one course where they tell

good at leak code problems is not to go down like really big rabbit holes. Focus on like the most complicated stuff right away, like dynamic programming. Why not just get really, really good at backtracking before you do dynamic programming? Why focus on harder stuff when you can't do easy stuff anyway? You shouldn't, in my opinion, do any leak code medium questions unless you're already good at leak code. You should not do any medium questions until you've done at least 50 easy questions because with that, you'll learn like reverse a string. You'll learn the basic linked list stuff. You'll learn even the basic graph traversals. You'll learn stuff like flood fill. You should not be doing like super hard graph traversal problems, something like this, before you've done the trivial ones. You'd be surprised how many people make that mistake. That's why I made this site and maybe even this site n could iio. I could make it even better. Maybe I should add more easy problems. I don't know. Maybe it could be more guided that

walk through it, maybe you'll figure it out. They would just make like off-by-one errors in the for loop. I was just surprised by that and things of that nature. They would mess up if statements. That's why I think you should focus more on the basics. Get really, really good at the basics. Get really, really good with if statements, for loops, conditionals, control flow, just basic things like that. Because you really need to walk before you can run. Because if you don't do that, you're going to look kind of dumb when you're like trying to do a depth-first search or like a graph traversal or something complicated, but you don't know how to do really trivial things. It's just going to look really, really weird. And it doesn't take that long to do that. I think that's the same problem people run into with like LeetCode questions. Obviously, the classic mistake is people will start coding before they even know the approach that they're going to take. Even if you can't solve a LeetCode problem, the way to get

if you've interviewed at Google or if you know about the interview process. People say like Google's interview process is one of the hardest. I don't know if that's true or not, but I asked actually relatively easy problems. I chose problems from like Google's question bank. Most of the questions are not on LeetCode. I think that's the most unique thing about Google's interview process. They don't ask textbook questions. Most likely the question you'll be asked is something you haven't seen before. And so I chose, in my opinion, a relatively easy problem. Interviewers will interview a candidate, and then they'll give feedback for the candidate. The packet of feedback will go to something called a hiring committee, where a bunch of like seniors and managers will look at the feedback and then give a yes or no. And somebody from the hiring committee actually like gave me a comment saying, Hey, the question you asked was too easy. You got to ask harder questions in the future. So I know my question wasn't too hard. Now that said, I don't even think the person passed the

you okay like do this for an interview, and then you like Shadow an interview, you watch somebody, another Google employee interview somebody, and then after that, you just start interviewing people. So if you ever get an interviewer that's really bad, don't feel bad because it's probably not your fault. The interviewer might just suck, they might just be new. I think when I started interviewing people, I was more nervous interviewing somebody than I was getting interviewed, at least the first few times that I did. I felt so nervous, I didn't want to like mess anything up. After a while, I learned that most people fail anyway within the first 10 minutes. If somebody's like struggling really hard to write a for Loop, it was kind of obvious that they weren't going to pass. And so I would be listening to them, seeing their code, and it just felt so bad 'cause you sympathize with somebody 'cause you've obviously been in the same position, but it's like the interview is like 45 minutes long, we're 10 minutes in.

interview in that case, and I don't think I gave them a positive rating. I think I gave them leaning no higher. Yeah, I asked, in my opinion, relatively easy questions. Even then, people would get so tripped up by the question, and it was so weird because it wasn't like they were completely dumb. It wasn't like they didn't know how to code because they were talking at the beginning of the problem. They would ask a couple clarifying questions. They would say, Okay, maybe we can do a depth-first search or something like that. They knew what algorithms were. They clearly had done preparation for algorithms and data structures, but when it came time to writing basic code, like for loops, if statements, and things like that, they would make the most trivial errors. In fairness, maybe they were nervous. I can understand that. Like, if you're nervous, you might make a mistake you wouldn't. But I would even tell them, Okay, maybe there's a bug in the for loop over here. Just dry run through it. Just

How I Interviewed Candidates at Google

Scripts