In some ways they can be wholly different, but I don’t think this is a good example of it.
Any programmer who cannot implement “take two numbers, return the larger one” is clearly not very competent. Even though you’re never going to literally need to implement Math.max yourself at work, you are going to need basically the same types of skills. Probably 95% of the work I do day-to-day is stuff you’d learn in your first year at uni, and this just shows that you’ve got that ability.
In practice, the best interviews I’ve had usually set a slightly more complicated task as a do-in-your-own-time problem and then go through what you did in the actual interview. Problems like “read a list of names in the form , each name on a separate line, from a text file. Sort the names by last name, then by other names. Output to another text file. Include unit tests.” They wouldn’t then expect you to re-implement the sorting algorithm itself, but more want to look at the quality of code, extensibility, etc.
More basic questions like the one in the OP, or fizzbuzz, are decent as well, and a big step up from lame questions like “what does SOLID stand for? What does the Liskov substitution principle mean to you?” Even if they’re not quite as valuable as a miniature project.
I think you can probably make the question a lot more interesting by asking them to implement max without using any branching syntax. I’m not saying that is necessarily a good interview question, but it is certainly more interesting. That might also be where some of the more esoteric answers are coming from.
For me, a good interview is a dialogue where the company representative shows me as much about the company as I do about me as a candidate. Take-home tasks are okay, I guess, but I suspect they might balk at me requesting they handle a mock HR issue, or whatever, for me!
In practice, the best interviews I’ve had usually set a slightly more complicated task as a do-in-your-own-time problem and then go through what you did in the actual interview.
The best interviews you’ve had are the ones where you’re doing free work on your own time?
“Work” is a debatable term. It’s not work that provides any direct value to the company, if that’s what you mean. But yes, it involves more effort on my part.
But yes. Not only does this method let me show that I’m good at what I do (far better than nonsense theory questions do), I have also found that companies that use this approach tend to come across as a better fit in other ways during the interview process.
This is why I think school and interviews are like a whole different universe from the one where actual work gets done.
In some ways they can be wholly different, but I don’t think this is a good example of it.
Any programmer who cannot implement “take two numbers, return the larger one” is clearly not very competent. Even though you’re never going to literally need to implement Math.max yourself at work, you are going to need basically the same types of skills. Probably 95% of the work I do day-to-day is stuff you’d learn in your first year at uni, and this just shows that you’ve got that ability.
In practice, the best interviews I’ve had usually set a slightly more complicated task as a do-in-your-own-time problem and then go through what you did in the actual interview. Problems like “read a list of names in the form , each name on a separate line, from a text file. Sort the names by last name, then by other names. Output to another text file. Include unit tests.” They wouldn’t then expect you to re-implement the sorting algorithm itself, but more want to look at the quality of code, extensibility, etc.
More basic questions like the one in the OP, or fizzbuzz, are decent as well, and a big step up from lame questions like “what does SOLID stand for? What does the Liskov substitution principle mean to you?” Even if they’re not quite as valuable as a miniature project.
I think you can probably make the question a lot more interesting by asking them to implement max without using any branching syntax. I’m not saying that is necessarily a good interview question, but it is certainly more interesting. That might also be where some of the more esoteric answers are coming from.
For me, a good interview is a dialogue where the company representative shows me as much about the company as I do about me as a candidate. Take-home tasks are okay, I guess, but I suspect they might balk at me requesting they handle a mock HR issue, or whatever, for me!
The best interviews you’ve had are the ones where you’re doing free work on your own time?
“Work” is a debatable term. It’s not work that provides any direct value to the company, if that’s what you mean. But yes, it involves more effort on my part.
But yes. Not only does this method let me show that I’m good at what I do (far better than nonsense theory questions do), I have also found that companies that use this approach tend to come across as a better fit in other ways during the interview process.