Avoiding Leetcode Anxiety

I think the reason that leetcode is so popular is because of so many software engineers underlying anxiety, sense of being unprepared, imposter syndrome. And when that’s already present, we look for solutions that flow into our emotional story. If I already believe I’m underprepared and that the goals I have are hard to achieve, I’m more likely to believe I need to solve 500 leetcode problems.

I help software engineers resolve your underlying interview anxiety and stress around things like interviewing and preparing. If this is you, come talk to us :)

tinyurl.com/happyhackers

2. The interview is not about the code. I want to see them in action and see how personable they are (a grump/huckster will ruin a team). I usually have very little time with them so the test has to be simple (something someone who is semi competent can do in 10 mins). That they are studying outside shows they are at least willing to do the work (and a bonus and helps shortcut many things). Learning to do things is usually part of the job. I do not expect them to do it outside of work. But it shows passion if they do (which is not a bad thing but is sometimes needed to grind out more glue code). I am usually more interested in what they used to work on and can they describe what they did. I do not even really care what the thing is. I want them to explain it to me. Explaining what is going on is part of the job many times. As in 'hey so and so wants a powerpoint presentation of what you have been working on for the past 3 months'. Some are good at it many are terrible at it. I am not looking for slick presenters but people who understand what is going on and show that they can do it. Interviews are about time management too. So you have usually 40-70 mins to decide if someone is worth it. You have to divvy up that time into chunks. That is on the interviewer. I usually spend the first few mins just trying to calm the person down. Then the next few with a semi simple test and explanation. The rest of the time is them showing off and hopefully asking questions about the job (not all do). Them not interviewing me shows something too.

3. The whole class was voluntary. I could have snapped the whip and made them do it. But that was not the point of the class. It was to be a group thing where we learned from each other. It was up front that you can do this on the clock or off. It was up to them. It was very free form. I do not think it was too much to ask them to watch some training videos for a framework they were going to soon be using? My 'meaning' that I attached was many do not want to put in the work but still reap the reward. Honestly it kind of shocked me the numbers. It was not like a couple of people dropped out. It was 95% of them. All of the other people helping with these similar classes had the similar results. My 'bar' for them was to watch 1 video per week over 12 weeks (for 9 videos) and some (optional) simple code test. Is that hubris? I was not expecting much at all.

'Not many people really want to study at work' Well then that will be a problem for many. If both 'do not want to study outside of work' and 'do not want to study at work' are both true you will find your skills rusty and long term unable to do the job. I have watched it happen over and over. At some point the tech stack will change. You will need to learn it. I can honestly say I have not gone many days in my career learning something. Reading docs, reading tutorials, watching vids, classes, prototypes, whatever.

Further, how does a naive person know which pattern applies to a problem? Without that knowledge, how can I vet a learning resource and know I’m not wasting my time?