8 ms·

I actually like to ask people in interviews to model a car and car factory because I want to see right away if they go deep into the nonsense of extending every

by bdg 4y ago

I actually like to ask people in interviews to model a car and car factory because I want to see right away if they go deep into the nonsense of extending everything, or if they can use composition, or get away with something focused on maintainable code that meets requirements. I've seen it all. Prius extends Car extends vehicle extends motor extends ... Right within the first five minutes of the interview. But I also think these old "a bike extends a " tutorials were the most frustrating thing in the world and made no sense to me when I was trying to learn OOP in the first place. From my memory, I recall all the examples I could find were absolutely nonsense but blogs were full of posts with lots of non-real-world about connecting web requests things to a DB code and lots of "yeah it's just like a person is-a mammal which is-an animal which...". It wasn't until I wrote some c++ and looked at how it worked in the heap and stack before I started to understand it better. Then later I learnt about SOLID and discovered that you almost never really want to use extension in practice (at least in the problems I worked on), except for things like interfaces in places you expect (and plan to have, and even better if you already do have) a reason for variations in sub-types that have the same contract, or need to cross system boundaries. I almost always want to use composition. I will use extensions but this should be really specifically be selected for a few key points.

quietbritishjim 4y ago
The problem with that is you might feel pressured to talk about Prius extends Car extends Vehicle etc. even if you wouldn't do that in real code because it seems the question is meant to probe the concept of inheritence so it's natural to answer that way. It takes a brave interview candidate to say "the best solution depends on the exact nature of the problem - and your problem doesn't make any sense so there's no valid solution".
- BoorishBears 4y ago
  I feel like you picked up on the wrong problem in their example... > Prius extends Car extends vehicle extends motor extends The problem isn't that it's too in-depth, or too overbuilt, that answer is as close to objectively wrong as you get on a pretty open ended question and I'd imagine only an extremely junior developer would come up with that. For example, you could maybe argue that a model of car extends a specific car. I'd expect an experienced developer to favor composition over inheritance at that stage, but that's open to debate. But if a Vehicle extends a motor, does a motor extend a piston? Does a wheel extend a lug nut? At that point you're moving away from "arguably correct" to just plain failing to answer the question. It shows they don't know the difference between composition and inheritance. > It takes a brave interview candidate to say "the best solution depends on the exact nature of the problem - and your problem doesn't make any sense so there's no valid solution". You're free to ask questions, we're supposed to be trying to collaborate. I don't think it's "brave" to instead say "your problem doesn't make sense". Shows more hubris than anything. How is it any different than a systems design question?
- bdg 4y ago
  > It takes a brave interview candidate to say "the best solution depends on the exact nature of the problem - and your problem doesn't make any sense so there's no valid solution". I got that a few times and it's a good sign I have a senior candidate. The real-world use case is simple when you imagine that I want to get a JSON payload describing different car configurations, possibly for a "car configurator" on a sales website, or perhaps for a videogame where there are different cars with different attributes at random. Once I go from "make a car" to "give me some json" everyone started to see it's as a less fictitious problem.
ncmncm 4y ago
Yes. This is why "default virtual" is such a dumb idea. Virtual functions are about implementation: a derived type that overrides a virtual function does so specifically in order to deliver a specialized implementation. The degree to which your class's virtuals match its public interface is an exact measure of how bad that interface is, as an OO abstraction. If your class was doing enough work to earn its keep, it would be presenting an interface in terms the client wants to see. Those are implemented for variant internal representations by composing calls to one or more private virtual interfaces. The above is true about OO subsystems. But not all uses of virtual functions are about OO. Virtual functions are a mechanism. Anywhere the mechanism is useful, it is OK to use it, OO or no OO. Java offers no other organizational facilities than OO mechanisms, so there you have little choice but to use them everywhere. In problems not suited to OO solutions, use of virtual calls may have nothing to do with OO, and none of the OO rules need apply: if it works, it works. Any language that offers only one kind of abstraction is a very poor and limited language. Calling it "pure" should not fool anybody. The world is complicated and demands many kinds of tools. Any one will only match certain aspects of certain problems.
734129837261 4y ago
In job interviews, people don't write the code they would write normally, they write the code that they think the interviewer wants to see. And that brings me to a topic that's entirely different but also very relevant: job interviews bring interviewer-biases with them. If you run into an old-school interviewer who would do exactly that "Prius extends Car extends Vehicle, etc." nonsense, but you don't know it, they would rate you negatively. If you run into someone who is just in love with functional programming, you'll lose any OO implementation. If you run into someone who doesn't like it when you ask questions, you'll lose. If you run into someone who doesn't like you asking questions they don't know the answer to, you lose. And if you get sent a 3-hour long Hackerrank or Leetcode algorithmic test, everybody loses. Tech job interviews are just horribly biased and the game is won if you read your audience correctly. And even then, if the other person is a racist, or just doesn't like your face, or had a bad day, or feels threatened, or disapproves of how you write "Javascript" instead of "JavaScript", you still lose.
- BoorishBears 4y ago
  Every example you listed would be dodging an enormous bullet. The exact example the grandparent used was essentially a wrong answer, so our "old-school interviewer" (that sounds kind of ageist doesn't it?) marking us down for not using it is a bad thing. An interviewer who loves functional programming and doesn't communicate any preference then marks you down for not reading their mind is someone to avoid. An interviewer who punishes you for asking questions is a huge red flag and you'll be dodging a huge bullet. I'm a self-taught dev so I definitely have some thoughts on how tech interviewing goes, but an interview runs both ways. I'd much rather miss out on a job because the other person was racist or they hate when people ask questions, than to end up working with them.
  - yCombLinks 4y ago
    Not every person in the interview process is anywhere near you in the org though, sometimes great jobs are behind a shitty interview
    - 4y ago
praptak 4y ago
I think it's a bad question, just like every single request to "model real world things X,Y,Z for no reason" and the article explains this: You can’t add code to ducks. You can’t refactor ducks. Ducks don’t implement protocols. If I got asked this question I'd probably spend the whole interview inquiring about the purpose of the modeling. It's for a simulation? What info do you want to get from the simulation? It's for an ERP app? I don't have problems with simple tasks which are not real-world but abstract something from the real-world use cases. The problem with "model me a car" is that it abstracts nothing. Also for the most real-life purposes of modeling a car factory you wouldn't even have a "Car" in your object hierarchy.
system16 4y ago
"Car/Animal extends..." slowed my ability to comprehend OOP significantly when I was learning to code. It just did not make any sense to me and I felt like an idiot for not being able to equate these "real-world" examples to the code I was trying to write. I just could not make the connection. It wasn't until I started trying to make a simple video game that these concepts made sense: an "Enemy" class could have properties of health and speed that a "Boss" or "Minion" could inherit from, etc.
- redisman 4y ago
  Even in games composition is much better and what pretty much every engine forces you to use these days. It’s a lot more flexible too as you can compose a new boss out of ten different components rather than having to refactor a crazy tree of nonsense
IshKebab 4y ago
So you literally say "can you model a car and a car factory?" because that's a pretty meaningless question so I'm not surprised they think "what is he talking about? ohhh he's referring to the classic car inherits vehicle thing and wants to see if I understand inheritance. ok I'll show him some inheritance!"

by bdg 4y ago

quietbritishjim 4y ago

The problem with that is you might feel pressured to talk about Prius extends Car extends Vehicle etc. even if you wouldn't do that in real code because it seems the question is meant to probe the concept of inheritence so it's natural to answer that way. It takes a brave interview candidate to say "the best solution depends on the exact nature of the problem - and your problem doesn't make any sense so there's no valid solution".

BoorishBears 4y ago
I feel like you picked up on the wrong problem in their example... > Prius extends Car extends vehicle extends motor extends The problem isn't that it's too in-depth, or too overbuilt, that answer is as close to objectively wrong as you get on a pretty open ended question and I'd imagine only an extremely junior developer would come up with that. For example, you could maybe argue that a model of car extends a specific car. I'd expect an experienced developer to favor composition over inheritance at that stage, but that's open to debate. But if a Vehicle extends a motor, does a motor extend a piston? Does a wheel extend a lug nut? At that point you're moving away from "arguably correct" to just plain failing to answer the question. It shows they don't know the difference between composition and inheritance. > It takes a brave interview candidate to say "the best solution depends on the exact nature of the problem - and your problem doesn't make any sense so there's no valid solution". You're free to ask questions, we're supposed to be trying to collaborate. I don't think it's "brave" to instead say "your problem doesn't make sense". Shows more hubris than anything. How is it any different than a systems design question?
bdg 4y ago
> It takes a brave interview candidate to say "the best solution depends on the exact nature of the problem - and your problem doesn't make any sense so there's no valid solution". I got that a few times and it's a good sign I have a senior candidate. The real-world use case is simple when you imagine that I want to get a JSON payload describing different car configurations, possibly for a "car configurator" on a sales website, or perhaps for a videogame where there are different cars with different attributes at random. Once I go from "make a car" to "give me some json" everyone started to see it's as a less fictitious problem.

ncmncm 4y ago

Yes. This is why "default virtual" is such a dumb idea. Virtual functions are about implementation: a derived type that overrides a virtual function does so specifically in order to deliver a specialized implementation. The degree to which your class's virtuals match its public interface is an exact measure of how bad that interface is, as an OO abstraction. If your class was doing enough work to earn its keep, it would be presenting an interface in terms the client wants to see. Those are implemented for variant internal representations by composing calls to one or more private virtual interfaces. The above is true about OO subsystems. But not all uses of virtual functions are about OO. Virtual functions are a mechanism. Anywhere the mechanism is useful, it is OK to use it, OO or no OO. Java offers no other organizational facilities than OO mechanisms, so there you have little choice but to use them everywhere. In problems not suited to OO solutions, use of virtual calls may have nothing to do with OO, and none of the OO rules need apply: if it works, it works. Any language that offers only one kind of abstraction is a very poor and limited language. Calling it "pure" should not fool anybody. The world is complicated and demands many kinds of tools. Any one will only match certain aspects of certain problems.

734129837261 4y ago

In job interviews, people don't write the code they would write normally, they write the code that they think the interviewer wants to see. And that brings me to a topic that's entirely different but also very relevant: job interviews bring interviewer-biases with them. If you run into an old-school interviewer who would do exactly that "Prius extends Car extends Vehicle, etc." nonsense, but you don't know it, they would rate you negatively. If you run into someone who is just in love with functional programming, you'll lose any OO implementation. If you run into someone who doesn't like it when you ask questions, you'll lose. If you run into someone who doesn't like you asking questions they don't know the answer to, you lose. And if you get sent a 3-hour long Hackerrank or Leetcode algorithmic test, everybody loses. Tech job interviews are just horribly biased and the game is won if you read your audience correctly. And even then, if the other person is a racist, or just doesn't like your face, or had a bad day, or feels threatened, or disapproves of how you write "Javascript" instead of "JavaScript", you still lose.

BoorishBears 4y ago
Every example you listed would be dodging an enormous bullet. The exact example the grandparent used was essentially a wrong answer, so our "old-school interviewer" (that sounds kind of ageist doesn't it?) marking us down for not using it is a bad thing. An interviewer who loves functional programming and doesn't communicate any preference then marks you down for not reading their mind is someone to avoid. An interviewer who punishes you for asking questions is a huge red flag and you'll be dodging a huge bullet. I'm a self-taught dev so I definitely have some thoughts on how tech interviewing goes, but an interview runs both ways. I'd much rather miss out on a job because the other person was racist or they hate when people ask questions, than to end up working with them.
- yCombLinks 4y ago
  Not every person in the interview process is anywhere near you in the org though, sometimes great jobs are behind a shitty interview
  - 4y ago

praptak 4y ago

I think it's a bad question, just like every single request to "model real world things X,Y,Z for no reason" and the article explains this: You can’t add code to ducks. You can’t refactor ducks. Ducks don’t implement protocols. If I got asked this question I'd probably spend the whole interview inquiring about the purpose of the modeling. It's for a simulation? What info do you want to get from the simulation? It's for an ERP app? I don't have problems with simple tasks which are not real-world but abstract something from the real-world use cases. The problem with "model me a car" is that it abstracts nothing. Also for the most real-life purposes of modeling a car factory you wouldn't even have a "Car" in your object hierarchy.

system16 4y ago

"Car/Animal extends..." slowed my ability to comprehend OOP significantly when I was learning to code. It just did not make any sense to me and I felt like an idiot for not being able to equate these "real-world" examples to the code I was trying to write. I just could not make the connection. It wasn't until I started trying to make a simple video game that these concepts made sense: an "Enemy" class could have properties of health and speed that a "Boss" or "Minion" could inherit from, etc.

redisman 4y ago
Even in games composition is much better and what pretty much every engine forces you to use these days. It’s a lot more flexible too as you can compose a new boss out of ten different components rather than having to refactor a crazy tree of nonsense

IshKebab 4y ago

So you literally say "can you model a car and a car factory?" because that's a pretty meaningless question so I'm not surprised they think "what is he talking about? ohhh he's referring to the classic car inherits vehicle thing and wants to see if I understand inheritance. ok I'll show him some inheritance!"