Interviewing Candidates: Challenges with Basic Coding Skills

Candidates struggle with basic coding tasks despite knowing algorithms, highlighting the need for stronger foundational skills.

### The Challenges of Technical Interviews: A Personal Reflection
* 🤔 Conducting technical interviews often reveals that many candidates **struggle with basic coding concepts**, leading to a long and challenging **35 minutes** for both parties.
* 💬 I aimed to assist candidates by providing hints and encouraging them to **walk through their code**, but this approach resulted in **almost no one passing the interviews** I conducted.
* 🔄 Interviewers can sometimes inadvertently distract candidates by pushing them in different directions, which can **hinder their ability to follow through on their thought processes**.
* 📚 There is a notable lack of interview training, with many candidates attempting medium-level questions on platforms like LeetCode without **mastering the basics first**.
* 🛠 I believe candidates should complete at least 50 easy questions before tackling medium ones, as this **foundational knowledge is crucial for solving more complex problems effectively**.
* 🚶 "You really need to walk before you can run," as failing to master **simple concepts** can lead to awkward situations during interviews when candidates struggle with **fundamental tasks** like loops and conditionals.
* 📝 Even with relatively easy questions, candidates often stumble on simple coding tasks, highlighting the **importance of solidifying basic programming skills** before attempting advanced topics.
* 😟 It's common for interviewers to feel nervous at first, but over time, I learned that many candidates **fail within the first 10 minutes**, making it clear that they may not be ready for the interview process despite their prior preparation.

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

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

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

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

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

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.

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

How I Interviewed Candidates at Google

NeetCodeIO

Google's interview process is known for its difficulty, with unique questions that are not typically found on LeetCode.

The feedback from interviewers goes to a hiring committee, where senior staff make the final decision.

The interviewer experience can be nerve-wracking, and it's common for candidates to struggle in the first 10 minutes, making it clear who may not pass.

Candidates often struggle with basic coding tasks, making trivial errors despite having a good understanding of algorithms and data structures.

Nervousness may contribute to their mistakes, even after asking clarifying questions.

The interviewer tries to provide guidance, suggesting candidates dry run their code to identify bugs.

Mastering LeetCode Problems: A Step-by-Step Approach

Focusing on the most complicated problems, like dynamic programming, right away is not effective.

It's essential to master the basics first, such as easy questions and fundamental concepts like string reversal and graph traversals.

Building a strong foundation in control flow and conditionals is crucial before tackling more complex problems.

The interviewer struggled to help candidates effectively, leading to a low pass rate.

They offered hints and guidance, but the constant redirection caused confusion.

The lack of interview training is a common issue, with only one course providing minimal guidance.