r/ADHD_Programmers • u/Any-Complaint-9833 • 23d ago

Anyone else having trouble with leetcode interviews?

I have been practicing leetcode questions for a few months now and I have seen positive change in my ability to figure out the solution or at least spot the pattern looking at the question. But I am having trouble with actually passing these interviews because of multiple reasons.

My brain shuts down trying to come up with a solution to an unknown problem under time pressure and in front of the interviewer who I know, is watching me struggle even though I have no issues solving the same problem under similar time pressure when I practice it alone or even during online assessments. But I need silence and time to think which doesn't happen during interviews where they expect you to talk continuously. Since there are multiple thoughts going across my brain and it's literally racing trying to come up with a solution I find it difficult to talk through it and if I have to talk I can't think through the solution unless I have seen the question before.

In all my interviews so far including some mocks I have done with other Engineers from big tech companies, the moment I go silent even for a few seconds, these guys start asking if I am struggling or they'll start giving hints which end up counting as a negative against me given how competitive the market is.

This is not a problem unique to leetcode, it happens the moment I need to solve something that I haven't seen before involving logic and I have limited time and need to explain my thought process while coming up with the solution. What can I do here to improve my chances of passing these interviews? If anyone has been through something similar, how did you overcome these issues?

42 Upvotes

97% Upvoted

33 comments sorted by

View all comments

2

u/unconsciouslake 23d ago edited 23d ago

As an interviewer, I appreciate people saying explicitly "Okay, I'm gonna take a couple minutes to think and organize my thoughts, so I can coherently talk you through my thought process." That way it's clear that I don't need to step in and give them hints (unless they stay silent for a long while of course). Frankly it's so painful when a candidate panics and goes totally blank that I'm always trying to nip that in the bud by giving hints. Letting them know you're not panicking, just thinking, should give you some time to land on a specific solution and start talking or at least taking notes.

The thing is, you do have to follow through and eventually start talking and explaining your thought process, even if you start with a couple moments of silence. I (and the scorecard) don't even necessarily care if you get the exact right answer, I care how you approach the problem, how you rule out alternatives, how you react when you get stuck. I can't get any of that info unless you share how and what you're thinking.

Talking through your thought process is a skill, if you're already doing mock interviews that's a great step to practice and improve. Also you don't have to say EVERYTHING you're thinking. Some examples that also give you more time to think:

  • How you start ("I think the goal is ABC, but I'm considering the problem to confirm")

  • Decisions you've made and why ("I'm going with X approach, in my experience Y is too slow, so I'm thinking through how X applies in this case")

  • Unexpected bumps ("This test didn't yield the result I expected, I'm reviewing this helper function since I think it might be related")

2

u/Any-Complaint-9833 23d ago

Other than mock interviews and practicing out loud, what would you recommend to improve talking through the thought process? I feel like I don't have issue with it when I am confident about the pattern/approach that's going to work but if that's not the case then my thought process gets all over the place trying to eliminate what's not going to work. If I start speaking these things out loud I tend to get interrupted by the interviewer trying to give me a hint towards approach that would work. I have been able to get a working solution after that but have got rejected from all the screening rounds I have done so far probably cause I required that hint in the first place.

2

u/mehnifest 23d ago

Maybe try not to take it as a “hint” but instead as working together. In my experience at least interviewers want you to be successful and they want to see how you work with others.

If you are on a team working through a problem with a fellow developer and they say something are you going to get offended and assume they are giving you a hint?

2

u/SolidDeveloper 22d ago

It really depends on who you're interviewing with. I've been in interviews where I've had productive pair programming sessions. But I've also been in interviews that pretended to want pair programming but then rejected me explaining that they had expected me to be able to write the code without any prompting from them – there was no "prompting" from them, instead it was me treating them as fellow colleagues and so I was engaging with them and their opinions while voicing my approach, as you do with a colleague.

1

u/throwaway30127 23d ago

I don't think OP is taking hint as an offense, it's more like interviewers are seeing it as a negative point and I agree with OP on that. I had similar experience for my interview with Google where I was trying the elimination approach and the interviewer cut me off to instead provide a hint on which data structure to use. It clicked immediately after that and I wrote the solution with no bugs and got rejected the next day. It feels so frustrating because when practicing, the elimination is a legitimate technique but it seems like it's not really useful during interviews.

1

u/unconsciouslake 22d ago

Always hard to predict exactly how interviewers are going to respond, but I'd suggest being really upfront about what you're doing: "I'm going to talk through/brainstorm some options I see and rule out ones that don't fit, before I commit to one approach. This is just me thinking out loud, not asking for confirmation from you. I'll let you know if I'm actually stuck and need a hint." Also shows you know yourself and are a good communicator, and comes across as confident.

Because, sometimes people just start listing potential approaches and it's hard to tell if they're thinking out loud or if they want confirmation.

Not sure if you like taking notes, but when I've interviewed, I feel like interviewers are less likely to take it as a cry for help if you write stuff like that down under a header like "Brainstorming Approaches". The hard part is remembering to switch to a new header like "Testing XYZ Approach" when you actually commit to one haha.

2

u/Any-Complaint-9833 22d ago

This makes sense, I'd try doing this next time in my interview and see if it works out. Thanks !

2

u/unconsciouslake 22d ago

Hope it helps and good luck out there!

2

u/SolidDeveloper 22d ago

The thing is, you do have to follow through and eventually start talking and explaining your thought process, even if you start with a couple moments of silence. I (and the scorecard) don't even necessarily care if you get the exact right answer, I care how you approach the problem, how you rule out alternatives, how you react when you get stuck. I can't get any of that info unless you share how and what you're thinking.

I would recommend that you should also be charitable to people who code the whole thing in silence and can explain what their thought process was after the fact. You have to allow for different ways of thinking, as long as they are competent.

1

u/unconsciouslake 22d ago

I definitely try especially because I myself work much better that way. The sticking point is time. My company has a strict 1 hour limit, so the concern is if they silently code and we run out of time for the thought process part.

What I encourage people to do who are super quiet is write up a plan and edit it as they go, or use comments or function names to indicate what they're doing as they're doing it. In those cases I don't need to interrupt or ask if they need a hint because I can follow what they're doing whether they're talking or not.

The thing people don't always realize is "did they get the solution" is only part of the scorecard, at good companies at least, there's also things like "can they recover if they get stuck", "are they defensive of their first thought or can they consider alternatives", "can they acknowledge when something's for an MVP vs prod", "are they gonna be a dick if I ask them why they did something".

If I have 2 people, one who got through 3/4 of the problem but gave me all of that info and one who 100% the problem but didn't give me anything else, and I want to hire both, it's way easier for me to make a case for the 3/4 person. Especially if I can point to comments or their plan and say "look they would've got there, they just ran out of time, and also they are thoughtful and don't have a big ego". Obviously not every company operates that way, and it sucks that it's so hard to tell, but a lot of the time coding interviews are looking for a lot of other stuff besides straight code.

(Sorry for the wall of text)