I mean I’d probably go super generic and say something like “it’s a deterministic function which turns a block of data into a usually smaller block of data, usually for comparing equality to the original block of data” which covers most of the uses?
If you ask a generic question, you’re gonna get a broad answer, and if you want to draw clarifying questions, you need to ask a more complex question and provide insufficient information to answer it. Even then, making that question something you can easily look up online, and you either know or you don’t, doesn’t achieve as much as making the question something that you objectively won’t know, and have to learn on the spot, as that shows your ability to learn new things including things you can look up on the Internet.
The point is that in a real software engineering process, specs and requirements are rarely defined precisely from the start, and the programmer should be able to identify the gaps and clarify them. A generic answer doesn’t help as much as a clarifying question.
A common but amateur mistake is to just make assumptions about how something should work and then forge ahead. As a programmer in a company, you are building things for somebody else (your boss, your client), so you need to ask them first.
Sure but as I said, that’s a knowledge question and not an engineering problem to solve. They’re very different and unless you work in software consulting, you’re not gonna get a problem that looks remotely like that from a client.
I mean I’d probably go super generic and say something like “it’s a deterministic function which turns a block of data into a usually smaller block of data, usually for comparing equality to the original block of data” which covers most of the uses?
If you ask a generic question, you’re gonna get a broad answer, and if you want to draw clarifying questions, you need to ask a more complex question and provide insufficient information to answer it. Even then, making that question something you can easily look up online, and you either know or you don’t, doesn’t achieve as much as making the question something that you objectively won’t know, and have to learn on the spot, as that shows your ability to learn new things including things you can look up on the Internet.
The point is that in a real software engineering process, specs and requirements are rarely defined precisely from the start, and the programmer should be able to identify the gaps and clarify them. A generic answer doesn’t help as much as a clarifying question.
A common but amateur mistake is to just make assumptions about how something should work and then forge ahead. As a programmer in a company, you are building things for somebody else (your boss, your client), so you need to ask them first.
Sure but as I said, that’s a knowledge question and not an engineering problem to solve. They’re very different and unless you work in software consulting, you’re not gonna get a problem that looks remotely like that from a client.