All you need is a magnetized needle and a steady hand.
Years ago I interviewed at Rackspace. They did a data structures and algorithms type interview. One of the main questions they had was about designing a data structure for a distributed hash table, using C or equivalent, to be used as a cache and specifically addressing cache invalidation. After outlining the basic approach I stopped and said that I have used a system like that in several projects at my current and former jobs and I would use something like Redis, memcache, or even Postgres in one instance, and do a push to cache on write system rather than a cache server pulling values from the source of truth if it suspected it had stale data. They did not like that answer. I asked why and they said it’s because I’m not designing a data structure from scratch. I asked them if the job I am applying for involved creating cache servers from scratch and they said “of course not. We use Redis.” (It might have been memcache, I honestly don’t remember which datadore they liked). Needless to say, this wasn’t a fit for either of us. While I am perfectly capable of creating toy versions of these kinds of services, I still stand by using existing battle tested software over rolling your own.
If you worry about forgetting how to code, then code. You already don’t know how to code 99% of the system you are using to post this comment (Verilog, CPU microcode, GPU equivalents, probably MMU programming, CPU-specific assembly, and so on). You can get ahead of the competition by learning some of that tech. Or not. But technically all you need is a magnetized needle and a steady hand.
Heh, I remember an interview once and they wanted me to figure out if a word contained double letters (i.e. there's 2 L's in letters).
I was like well I'd probably just make a Set in Java and insert letters until it has a duplicate.
They didn't like that. So I was like well I guess I can make a double for-loop and check that way and they liked that ... It is weird how people like you to re-invent the wheel as opposed to just import one.
Not that I'm a fan of this kind of interview, but these answers illustrate different kinds of skill/intelligence.
One is domain knowledge which is less important in the age Google search and StackOverflow (and even less so in the age of LLMs but I guess interview techniques haven't caught up yet).
The second is the ability to understand a nested for loop, and if a coder can't do that by the point they reach an interview, it can probably never be taught.
It could be argued that being able to think up using a set in this instance is also an important skill, and I agree. But nested for loops are foundational skills, if the interviewee has problems there it's a good thing to know about early.
It could also be argued that they should just say directly "solve this using loops" if that's what they want, and well, yeah.
A Bloom filter would be a way more fun solution. But I think the quiet part of this is that people conducting interviews just like to feel clever in knowing some puzzle and its answer. Make them feel good about their puzzle and they like you that much more as a candidate.
My favorite way to interview people is to ask them about their work and personal projects and about what parts of those were tricky, why, and how they solved those challenges. This gets candidates to talk much more openly about what experience they have and we can discuss real world practical problems down to having them show pseudo code (or showing off their GitHub repos of specific projects) that can very efficiently tell you how they think. It’s the equivalent of “tell me about bridges you have designed” vs “here are popsicle sticks, design a toy bridge” approach.
Just lmao, their interviews were delusional, you aren’t alone in your experience. Especially considering what they actually mostly did was janitor MySQL databases and Drupal.
The company itself also turned into a circle of hell so probably for the best.
It was weird because their remote interview was very good and done well. It was a pair coding exercise but one that wasn’t terrible at all. And they flew me out to SF and paid for 3 days of time there which honestly was very nice. But the in person interview was a mess. Different teams I suppose.
Years ago I interviewed at Rackspace. They did a data structures and algorithms type interview. One of the main questions they had was about designing a data structure for a distributed hash table, using C or equivalent, to be used as a cache and specifically addressing cache invalidation. After outlining the basic approach I stopped and said that I have used a system like that in several projects at my current and former jobs and I would use something like Redis, memcache, or even Postgres in one instance, and do a push to cache on write system rather than a cache server pulling values from the source of truth if it suspected it had stale data. They did not like that answer. I asked why and they said it’s because I’m not designing a data structure from scratch. I asked them if the job I am applying for involved creating cache servers from scratch and they said “of course not. We use Redis.” (It might have been memcache, I honestly don’t remember which datadore they liked). Needless to say, this wasn’t a fit for either of us. While I am perfectly capable of creating toy versions of these kinds of services, I still stand by using existing battle tested software over rolling your own.
If you worry about forgetting how to code, then code. You already don’t know how to code 99% of the system you are using to post this comment (Verilog, CPU microcode, GPU equivalents, probably MMU programming, CPU-specific assembly, and so on). You can get ahead of the competition by learning some of that tech. Or not. But technically all you need is a magnetized needle and a steady hand.