4 ms·

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 (bas

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.

user5994461 10y ago
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
- tonyarkles 10y ago
  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.
  - clarry 10y ago
    Do you have any online resource that could tell me what these foundations of CS are?
    - tonyarkles 10y ago
      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.
      - clarry 10y ago
        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.
  - geebee 10y ago
    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.

user5994461 10y ago

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

tonyarkles 10y ago
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.
- clarry 10y ago
  Do you have any online resource that could tell me what these foundations of CS are?
  - tonyarkles 10y ago
    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.
    - clarry 10y ago
      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.
- geebee 10y ago
  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.