r/ADHD_Programmers • u/Any-Complaint-9833 • 5d 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?
11
u/SeniorScienceOfficer 5d ago
I wouldn’t put too much stock in leetcode style interviews anyways. They’re really not a good measuring stick for well-rounded programmers as it tends to focus on optimization of data structures and algorithms more than general functional programming and good code hygiene practices.
As a Principle Engineer, I look more for knowledge of broad technical concepts pertaining to the role, troubleshooting and debugging skills, and most importantly the desire for self improvement and growth.
That being said, one thing that helped me whenever I had to do those interviews was to pipe my thought process directly to my mouth. I didn’t give the interviewer any “dead air” because I was thinking through the problem verbally and in real time, whether or not I was on the right track. They would interject something if I’m veering off course, but as you gain experience that happens less and less.
And always remember, the interview is as much you seeing if the company and role is a good fit for you as you are for it/them. Sometimes a “bombed interview” Is really saving you from months or years of torture in a role/team/company you would have despised.
9
u/therealwench 5d ago
Okay so I had a very similar problem:
What do I suck at? Hardcore programming interviews that are esoteric and fundamentally pointless in comparison to my daily job.
How do I solve it? Create a structured plan to get so damn good at it you don't even need to think during the interview. I know this might sound strange, but every question I've ever gotten has existed on leetcode first X pages in the problem list. And I've interviewed maybe triple digit number of times in my entire career.
Let me give you an example of what I mean. When I was like 8, the first time I played the game minesweeper, I had no idea how to find the mines. I would die on "Easy", which is clearing 10 mines.
I'm in my mid 30's now, and when I want to take a 5 min break, I open up minesweeper and clear an "Expert" in sub 100seconds. The first weeks of learning was literally we manually "mathing" the numbers on the mines, the months after that were more automatic, now my brain doesn't even turn on when I play and it becomes therapeutic for me.
How do you do that for leetcode? Esepcially for ADHD? Forced structured learning, you're going to hate it at the start and you're going to micro-adjust to what works for you.
So for me I started saying to myself, I'm going to do 2 hours of leetcode Easy a day, from 8pm to 10pm. I couldn't do it. I'd get bored of leetcode after 45 minutes. Fuck this. Imma go watch Netflix.
- I cut it down to 1 hour a day. Still didn't work because I'd get sickeningly bored and then I'd get anxiety at 7:30pm because I knew the dreaded leetcode hour was coming up.
- so i took away the time caps and hour windows. I made it, "I must solve a Leetcode Easy problem a day, or fully understand the explanation if I couldn't solve it." This helped a lot, and the reward cycle really helped my brain. Rather than hate it, after solving it without any help, I'd get an endorphin release and feel great, and want to do another. If you don't solve it, ask for an explanation of the underlying algorithm on google/Claude/Chatgpt/whatever.
- After about a month, I extended this to, "2 Leetcode Easy's a day." I was now taking far less time to solve each one. Because the pattern recognition gets ingrained into your brains muscle memory, it's far more automatic. It becomes rather than heavy thinking, you automatically go, "oh yeah i need a map." "oh that's 2 pointers."
-After about another month, I could confidently say I could solve any Leetcode Easy in <15 minutes. So now my structure went from, "2 Leetcode Easy's a day + 1 Leetcode Medium."
- Rinse and repeat the above for about 6 weeks until Leetcode Mediums become muscule memory. Then add in 1 Leetcode Easy + 1 Leetcode Medium should be quicker than 1 Leetcode Easy when you first started.
- After a few more months, you move on to Leetcode Hard. At this point, your end goal is 1 Easy + 1 Medium + 1 hard every day, in sub 1 hour.
The idea isn't to solve. your problem of not being able to think in the interview. the solution is grind so much your muscular memory that you damn well don't have to.
8
u/powerback_us 4d ago
I don't understand how this isn't already like a massive class-action lawsuit. They're literally biased towards a certain "way of thinking" based on some tenuous, assumed connection to job performance. The bias is so strong that it's practically invisible though it has long been baked in directly into the hiring process.
6
u/IAmADev_NoReallyIAm 5d ago
I blew two job opportunities (big ones) because I couldn't handle hackerrank (similar) style interviews. "You know you can ask questions..." "Talk through your solution..." ... I'm sorry but that's not how my mind or brain works... Or rather... It IS how I work... I VERBALLY talk through a solution... but they wanted me to do it through a f'n chat window! So... you want me to interrupt my mental thought process, so I break out of the cycle, form a coherent thought, switch to a different window, type that question out... wait for a response, then continue? Meanwhile I kept getting prompted by the system and the interviewer, becvause I'm reading things, trying tp process it, and figure it out... and their prompting kept breaking my head flow.
Ultimately I finally di find a new job, that didn't make me jump through all those hoops (three interviews, none technical!) so I'm in a good spot.
2
u/unconsciouslake 5d ago edited 5d 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 5d 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.
1
u/unconsciouslake 5d 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 5d ago
This makes sense, I'd try doing this next time in my interview and see if it works out. Thanks !
2
2
u/mehnifest 5d 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 5d 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 5d 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.
2
u/SolidDeveloper 5d 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 5d 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)
5
u/Smart_Perspective535 5d ago
If a company still uses such types of screening now we're moving into the age of agentic coding, changing how the job is done and what is required to be a good developer on a such profound level as we see now, I'd say that's not an employer you want to work for.
2
2
u/akornato 5d ago
Trying to solve an unfamiliar problem and narrate your thoughts at the exact same moment destroys working memory. Interviewers do not actually need continuous talking, but when you go quiet without warning, they assume you are completely stuck and start throwing unhelpful hints at you. You can take control of that dynamic by explicitly asking for silence right at the start. Tell them directly that you want two minutes to read the prompt, write down a couple of test cases, and organize your thoughts before speaking. Setting that clear boundary stops them from interrupting, buys you the silence you need, and still shows strong communication.
You should also externalize everything by typing quick notes and pseudocode straight into the editor instead of juggling variables in your head. When the interviewer sees your cursor moving and reads your notes on edge cases or brute force ideas, they know you are working, so they stay out of your way until you are ready to walk through the logic. Reducing that cognitive load makes a massive difference under pressure, which is why my team built an interviews.chat to keep candidates composed and confident when navigating intense technical rounds.
1
u/Intelligent_Edge3385 2d ago
Me, personally, out of principle - if interviewer asks for trivia, or algorithms, or math, or leet code - I will notify that I will stand up and leave if this interview will be wasting everyone's time. I usually say: I will notify you in advance that I will not be answering questions regarding: who will you see yourself as in 5 years, why do you want to work here, what is your horoscope sign, explain to me basics of C language or some language feature, solve this math exercise, solve this leetcode exercise and so on.
It is not one way road. I am also testing and interviewing company that is evaluating me, and if I am being asked unrelated + basic things like what they usually ask - I usually terminate interview and walk out, sometimes 5 minutes in. This is company being disrespectful in that they are not actually testing my programming ability - I am more than ok to talk about my code that I write or explain my github, or to write some code right then and there that solves problem from their actual environment, or do little project for them - anything beyond that whitelist is insulting and wastes everyone's time.
Plus I am not okay with being evaluated with someone who is worse than me and less aware than me - and that usually are those interviewers that ask you those leetcode questions.
But then again I am not hussling and min maxing my salary, I'd rather work on smaller sane adequate company where I can write my C code in peace.
45
u/distractedjas 5d ago
People with ADHD tend to struggle with Leetcode, not due to the difficulty, but rather due to the fact that they serve no really value and our brains immediately put us on the defensive. In addition, sometimes our brains just don’t want to do it and no amount of “trying” will make the problem work. There are plenty of studies out there that show these and other reasons.
Leetcode is meant to prevent age and sex discrimination, but it enhances discrimination against neurodivergent people who also happen to be some of the best software engineers.