I've seen the coding questions we ask candidates... whether or not i would pass would depend 100% on which question(s) I was asked.

Something relevant to the work I do all the time? yes, I'd probably pass.

Something about some data structure or algorithm I haven't needed to use in four years that i now have 30 minutes to implement in code? I'd likely fail.

When something comes up in my actual job where i need to solve a problem i'm not familiar with, i first do some research on the problem and learn/remember what i need to know about it and related algorithms/data structures before doing any actual coding.

i certainly do not "immediately write code as fast as possible" when presented w an unfamiliar problem.

if you must ask candidates to work on coding problems, i believe that you should give them 3 or more problems and let them pick which one to work on for the actual "coding test" part of it.

Then maybe have a conversation about the other problems to get a sense of how they would think about/approach them w/o actually making them write code.

You nailed it, man. I don't do terribly well on Leetcode interviews, on average, but, for my last job, my interviewer told me some time after I got hired that I had done the best on that interview that she had ever seen. That's because it was a real world question as part of a structured interview process, as opposed to "let's just 4 engineers to throw random problems at the candidate."

LOL, same here. It seems that my knowledge was moved (not copied) from my brain to my tongue, then it vanishes away through the phone line.

Interesting. This is my weak spot as well. Any tips for going through this cycle? What do you use to learn them? To practice?

I used to reread Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People by Aditya Bhargava and practice LeetCode.

At this point though I just stop the interview if they’re asking Big-O or data structure questions. If the company can’t come up with meaningful real world examples that actually explores my experience, I don’t want to work there.

I love using JavaScript for white boarding. It's very forgiving, it's not strongly typed, interviewers are all familiar with it, and large companies almost always allow it. Python is second. I avoid Go, Rust, Java, Scala, etc.. Too verbose.

I do the following in JS:

- General graph algorithms (shortest path, backtracking based)

- Traversals for graphs / trees (depth first, breadth first, iteratively, recursively)

- Heaps (min, max)

- Tries

- Matrix manipulation / traversal. This is a very error prone for a lot of folks even though it looks simple when they need to write it by hand, and I always need to putz around with 5-10 problems.

I have enough exposure to common interview questions that the above is generally enough.

Any focus on Dynamic Programming stuff? I myself prefer Python(as it very closely resembles pseudocode)

I prefer python as well. It has some built in caching that makes DP problems trivial at times.

Sounds like my physics degree.