You sound like a superstar. I don't mean that condescendingly, but I meant that genuinely - assuming you're telling the truth, you're the kind of candidate (based on tech skills alone) that most companies would love to interview and hire.
But there are way more jobs and positions than there are candidates like you. And you can't have every company be full of superstars.
The argument is for the rest of us, having a hiring process that optimizes for superstars doesn't select the best of the rest - it selects a random subset of the rest.
I wouldn't call 4 interviews a superstar. It's really doable, a bit of skill + a bit of luck for the first interviews + a hiring bar set at 'junior' cuz he's young :D
I suspect that they're not calling you a superstar because you've passed four tech interviews, but because your foundations of CS aren't decaying.
I work with a lot of teams as a contractor/consultant/whatever you want to call it. I often have to bite my tongue when team members that work for my clients forget what I believe are really simple things. For example, doing lookups in a hash vs an array. That was literally the entire solution to a performance problem I solved for a client: loop through an array once and make a hash, and then do lookups from the hash. Dropped the calculation from 4 minutes to 4 seconds.
The point is, this stuff comes naturally to me. When I think about going to town and shopping at 4 stores, I curse google maps for not implementing a heuristic TSP solver. When I started playing with hashicorp consul and vault, I went and read the Raft paper just to understand what was going on.
There's a lot of people in the industry that don't think about this stuff. I probably wouldn't if it didn't just come. I've got this deeply ingrained curiosity, and some kind of innate talent to remember it all and keep drinking from the fountain.
It's hard to remember that not everyone is like me. I'm not trying to say any of this as some form of humble brag or anything. It's just really important to remember that how I think and act isn't the same as most people. That, I suspect, is why the GP called you a superstar. You likely think about things in a much deeper and more frequent way than others.
Interesting, but your case may really get at what may go wrong with the algorithm exam approach to interviewing. I would expect a developer with a good understanding of fundamentals to see the difference in using a hash vs an array, and I would hope that developer at one point implemented a hash as an exercise.
I haven't needed to implement my own hashing table or methods on a real world project, as far as I can remember, but yes, I've absolutely written code that would have performed miserably if I hadn't known to use a hash rather than an array. I just didn't custom roll the hash, I used the hashing methods available to me in that language.
I'm aware of what a hash is, and what a hashing function is, and how collisions are resolved, and strategies to handle them. But I'm also almost certain I've been screened out of jobs because I couldn't implement a hash with a good hashing function in 45 minutes at the whiteboard. I just don't walk around ready to do this.
To address the last point, there's a tradeoff, as always. There's two competing forces with a hash function: speed and distribution. We want the hash to compute as quickly as possible, but want as close to equal probability of each bucket being chosen.
Assuming you're looking for a 32-bit hash value, my lazy whiteboard hash function would probably be something like:
- for strings, xor the bytes a word at a time.
- for ints, just use the 32-bit value
- for objects, let them provide their own, and if none is provided just use their memory address (this assumes that the objects don't have equality operators... that gets more complicated. If an object implements an equality operator, it also needs to implement a hash operator.)
These rules are by no means optimal, but they'd probably do as good enough for something that's not super high performance.
It also bears keeping in mind, I learned C twenty years ago, at the tender age of 12. Self-taught from the book that came with the compiler floppy[1]. We wouldn't have Internet at home for another 2 years, so I would occasionally persuade my parents to take me to a local Internet cafe for an hour to slurp up as much as I could at 28.8kbps and scribble it down. Bit manipulation operators are pretty deep in my soul at this point.
---
So going back to the original discussion... that came pretty natural to me. "How would I implement a hash function?" The brain whirrs a little bit and says "hey, here's some things to think about". I am 100% aware that this isn't typical, and do not expect others to have the same experience.
In fact, if I were hiring someone, I would be totally satisfied with an answer of "I'm not sure how to implement a hash function off the top of my head. It takes the object/value that we're going to insert into the hash table and turns it into a number that we can use to index into the appropriate bucket. Can we look one up?"
Hell, I'd probably be satisfied with "Here's when I'd use a hash table, and here's when I'd use an array. I've never implemented a hash table but I'd love to know how it works under the hood."
For me when hiring, the two biggest things I'm looking for are the ability to decompose problems into manageable parts, and a curiosity about how everything works. Those two things together tend to make any other knowledge gaps totally manageable; I'm not omniscient, but my desire to learn as much as I can about anything I don't understand can sometimes give off that illusion :P.
Well, here's the thing - I've been on a lot of interviews, and the majority of them wouldn't be satisfied with the answers you'd be satisfied with. If interviewers were the way you've described, I don't think the whole thing would be such an issue.
Overall, yeah, interviewers want to see that hash map largely written, often at a white board. Minor errors and bits of pseudocode are ok, but it should pretty much work.
"Hashtables: hashtables are arguably the single most important data structure known to mankind. You absolutely have to know how they work. Again, it's like one chapter in one data structures book, so just go read about them. You should be able to implement one using only arrays in your favorite language, in about the space of one interview."
Of course, Steve Yegge isn't the final word on prepping for google interviews, and I only had one experience there myself, but yeah, I'd say he's pretty spot on here (in fact, the google recruiter who arranged my interviews forwarded me the Yegge blog post, though I'd already read it earlier).
This, I think, is what is called "the Curse of Knowledge". I've taught 2nd year (Assembly) and 3rd year (Intro to Operating Systems Concepts) CS courses quite successfully, but I would have a helluva time teaching a 1st year course.
Like I mentioned in the sibling thread, I've been programming C for twenty years, and learned BASIC on a Vic-20 four yearsish earlier than that (at age 8). I learned all of that from library books.
Mostly, my algorithm for learning almost anything is "look at something that is somewhat magical, and figure out how it works inside". I've been doing that for years and years. Questions like "who programs BASIC? And how?" lead to learning about assembly. "How does BASIC store my program in memory?" "How does it translate what I type into output on the screen?" Etc.
Not to ramble on... unfortunately, I don't know of such a resource, and I don't really know what material it'd cover if I wrote it.
Right. Well, my story is that I'm selft taught (started programming when I was 6 or 7) and thus have been programming as a hobby for nearly twenty years. I decided not to go study CS because I suspected the amount of new and interesting material would be low compared to the time, money and effort it'd take to graduate. Instead, I went on to learn something completely new.
So one of my problems is that I don't actually know what I'm missing out on.
But there are way more jobs and positions than there are candidates like you. And you can't have every company be full of superstars.
The argument is for the rest of us, having a hiring process that optimizes for superstars doesn't select the best of the rest - it selects a random subset of the rest.