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.
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?
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.
The best interviews you’ve had are the ones where you’re doing free work on your own time?