8 ms·

He - acknowledges and understands the problems and - could certainly fix them if paid a Google-sized salary But he won't dance to the tune of the "Cracking t

He - acknowledges and understands the problems and - could certainly fix them if paid a Google-sized salary But he won't dance to the tune of the "Cracking the Coding Interview" juggernaut so to heck with him. Better to spend time memorizing the Floyd Cycle Detection algorithm than produce useful code. ( OK, I may be a bit bitter )

treis 6y ago
I mean he says he doesn't really know what a b-tree is. That's a pretty basic data structure and kind of table stakes for being a software engineer. Even then, Google gave him a good look with 7 interviews. Just speculating here, but they probably would have given him a chance if he wasn't "often a dick" and "often difficult".
- merb 6y ago
  the only interaction with b-tree's i had was: CREATE INDEX index ON table (column); so I doubt the knowledge of b-tree's are that important for 90% of the users/people/developers. heck I know how to write a multipart parser/formatter, which I doubt that many people do. especially people who know how a b-tree works. well most people which do know how a b-tree works, do not know when to use it.
- growse 6y ago
  > That's a pretty basic data structure and kind of table stakes for being a software engineer. It really isn't. You don't need to know what a b-tree is to do most modern software engineering. > Even then, Google gave him a good look with 7 interviews. Just speculating here, but they probably would have given him a chance if he wasn't "often a dick" and "often difficult". I think you're right on this one.
  - chii 6y ago
    > It really isn't. You don't need to know what a b-tree is to do most modern software engineering. if you're hiring a car driver, then yes, the driver doesn't need to know the innards of how an engine would work. But if you're hiring a car mechanic, surely you expect them to understand the innards of the engine.
    - growse 6y ago
      This is not a good analogy. Most cars work in roughly the same way. Most software does not. Software engineering is a diverse enough topic that you can have two "software engineers" who, aside from very broad general concepts like control flow and modularity, have very little overlap in their areas of expertise. Developing microcontroller firmware requires a very different set of skills and knowledge to building an ML model in R. Most pieces of software require zero knowledge of the inner workings of, different implementations of, or even existence of a b-tree structure in order to be able to successfully create, understand and maintain them. Let's not gatekeep by telling people they're not real software engineers unless they understand and can recite an arbitrary set of mostly useless topics.
      - kls 6y ago
        It's actually not a good analogy because most mechanics nowadays specialize. You don't have an engine guy do an automatic transmission rebuild and you don't have your local car dealer do a coil-over 4 link suspension upgrade on your Jeep. This is exactly analogous to software in that you don't need to know deep algorithms to build CRUD web apps. They are a different part of the machine and closer to the business domain. Looking for deep CS over skills like requirement gathering, collaboration, information theory gives false signals on competency for the task at hand. The reality is front end, backend, embedded, desktop etc. etc. all have different requirements on the skill sets they need to be successful. People gain the skills they need via the process of working, then we have this ritual of interviewing where we act like all these things that never get used in their trade are so so important to know. The direct analogy is I am hiring an engine guy,he will never touch a transmission. The guy knows fuel maps, timing and compression ratios like the back of his hand, but I keep insisting that he tell me how the sun gear of the transmission engages the planetaries and in what sequence because he has to know this to be any good as an engine guy and come to the conclusion in my head that if he does not know transmissions it is a signal that he is not fit to be an engine guy.
        treis 6y ago
        >The guy knows fuel maps, timing and compression ratios like the back of his hand, but I keep insisting that he tell me how the sun gear of the transmission engages the planetaries and in what sequence because he has to know this to be any good as an engine guy and come to the conclusion in my head that if he does not know transmissions it is a signal that he is not fit to be an engine guy. Sure, but that's not what happened. The real story, in contrast to the tweet, is that he didn't really know what a b-tree was. And if you're hiring an engine mechanic and they tell you they don't really know what a transmission is, well, that's a pretty big red flag.
- rurban 6y ago
  You don't need to know what a b- tree is, just a binary tree. The question was about a simple binary tree, which is really trivial, even you have no idea of b-tree's and you never inverted a binary tree yet. The dick part might be true, esp. after getting 7 interviews.

treis 6y ago

I mean he says he doesn't really know what a b-tree is. That's a pretty basic data structure and kind of table stakes for being a software engineer. Even then, Google gave him a good look with 7 interviews. Just speculating here, but they probably would have given him a chance if he wasn't "often a dick" and "often difficult".

merb 6y ago
the only interaction with b-tree's i had was: CREATE INDEX index ON table (column); so I doubt the knowledge of b-tree's are that important for 90% of the users/people/developers. heck I know how to write a multipart parser/formatter, which I doubt that many people do. especially people who know how a b-tree works. well most people which do know how a b-tree works, do not know when to use it.
growse 6y ago
> That's a pretty basic data structure and kind of table stakes for being a software engineer. It really isn't. You don't need to know what a b-tree is to do most modern software engineering. > Even then, Google gave him a good look with 7 interviews. Just speculating here, but they probably would have given him a chance if he wasn't "often a dick" and "often difficult". I think you're right on this one.
- chii 6y ago
  > It really isn't. You don't need to know what a b-tree is to do most modern software engineering. if you're hiring a car driver, then yes, the driver doesn't need to know the innards of how an engine would work. But if you're hiring a car mechanic, surely you expect them to understand the innards of the engine.
  - growse 6y ago
    This is not a good analogy. Most cars work in roughly the same way. Most software does not. Software engineering is a diverse enough topic that you can have two "software engineers" who, aside from very broad general concepts like control flow and modularity, have very little overlap in their areas of expertise. Developing microcontroller firmware requires a very different set of skills and knowledge to building an ML model in R. Most pieces of software require zero knowledge of the inner workings of, different implementations of, or even existence of a b-tree structure in order to be able to successfully create, understand and maintain them. Let's not gatekeep by telling people they're not real software engineers unless they understand and can recite an arbitrary set of mostly useless topics.
    - kls 6y ago
      It's actually not a good analogy because most mechanics nowadays specialize. You don't have an engine guy do an automatic transmission rebuild and you don't have your local car dealer do a coil-over 4 link suspension upgrade on your Jeep. This is exactly analogous to software in that you don't need to know deep algorithms to build CRUD web apps. They are a different part of the machine and closer to the business domain. Looking for deep CS over skills like requirement gathering, collaboration, information theory gives false signals on competency for the task at hand. The reality is front end, backend, embedded, desktop etc. etc. all have different requirements on the skill sets they need to be successful. People gain the skills they need via the process of working, then we have this ritual of interviewing where we act like all these things that never get used in their trade are so so important to know. The direct analogy is I am hiring an engine guy,he will never touch a transmission. The guy knows fuel maps, timing and compression ratios like the back of his hand, but I keep insisting that he tell me how the sun gear of the transmission engages the planetaries and in what sequence because he has to know this to be any good as an engine guy and come to the conclusion in my head that if he does not know transmissions it is a signal that he is not fit to be an engine guy.
      - treis 6y ago
        >The guy knows fuel maps, timing and compression ratios like the back of his hand, but I keep insisting that he tell me how the sun gear of the transmission engages the planetaries and in what sequence because he has to know this to be any good as an engine guy and come to the conclusion in my head that if he does not know transmissions it is a signal that he is not fit to be an engine guy. Sure, but that's not what happened. The real story, in contrast to the tweet, is that he didn't really know what a b-tree was. And if you're hiring an engine mechanic and they tell you they don't really know what a transmission is, well, that's a pretty big red flag.
rurban 6y ago
You don't need to know what a b- tree is, just a binary tree. The question was about a simple binary tree, which is really trivial, even you have no idea of b-tree's and you never inverted a binary tree yet. The dick part might be true, esp. after getting 7 interviews.