When I interview (experienced) devs, I often ask way too generic questions. Something along the lines of “can you explain what a hash is?”, without stating what kind of hash and in what context
The primary goal isn’t really to explain it in detail, but to see if they get confused and ask for clarification. Way too many people just start assuming something, when a task is not defined properly. I need coworkers that push back on bullshit, and not blindly implement whatever runs along their desk, no matter how little sense it makes
If I don’t hear at least one “it depends” during an interview, I don’t have high hopes
I had this with one of my guys. He spent a week working on something and the validation at the end wasn’t jiving.
He started showing me the complex solution and end results and so I said show me how you started and walk me through it.
It was step 1 the origin location of data was out of position.
I said if you start at this origin the rest of the numbers and data will work out.
He replied that the origin wasn’t shown measured from somewhere, so how would we know location.
So I pointed out that the data to origin wasn’t directly spelled out but if you take this measure and subtract this one that is your data origin start.
He said OMG I worked on this for a week trying to get the formulas working. I feel so stupid because you solved it in 1 minute.
I replied its not a question of smart or stupid (because my guy is way beyond me for formulae and programming) its just slowing down and following a process. And if you are confused, ask more questions, rather than just continuing.
Your candidates aren’t mind readers though. If you want people to ask clarifying questions, you have to ask them things other than comp sci trivia questions.
I thinks that’s the whole point, they can’t read minds so they need to ask questions to gain information. So you can makean better response.
When I’ve done support and customer says “This isn’t working I need this bug reported”
The first question I ask is “Why do you need to do that?”
Because just fixing what they asked solves their current issue, but not the underlying pain they have in their process.
100s of techs would just solve the bug, but they you never find out the deeper issue or lack of features that push the customer to using the other thing.
It could be on a different subject, but it has to be a trick question. If they were prompted to ask more, that would undercut the whole point of the test, since OP wants employees that always ask or question.
I don’t think asking someone a trick question in an interview is a good way to gauge if they’ll push back and ask questions on the job. Also, I think that behavior is more related to the employer creating an environment where employees feel safe doing that, and isn’t really something you can draw out of a candidate during an interview, of all times.
Well, there’s reason to think it is. Or at least, is for original, insightful questions; anybody can come up with “can I have more time off?”. We live in a society that rewards reliably doing and saying whatever you’re told to, and critical thinking (which isn’t just skepticism!) is super rare when tested for. A lot of college kids with good grades got there because they learned to mindlessly repeat whatever stuff back when tested.
Why that’s rewarded so much, and if there’s a way to encourage and teach actual independent though, are great questions, but that’s not really relevant here.
Also, I think that behavior is more related to the employer creating an environment where employees feel safe doing that
It’s also a big factor. Since that reply, it’s come up that OP isn’t actually management, but just does interviews. So, maybe they’re looking more for a good colleague than a good employee.
If memory serves, Google used to use these kind of questions, but they stopped because that isn’t actually what they wanted or needed in their workers. A code monkey doesn’t need to question anything, in the end.
Fair point, but depending on the interviewee, you might get very different answers and/or follow up questions.
Even if they assume something, it might be just for the sake of the example. If they’re competent, they’ll follow up with another example and so on, depending on how exactly you pose the problem.
If you present it as an abstract question, one possibility is that you get an abstract answer. If you present it like a ticket with no description, you might get prompted to clarify.
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.
So, to start off, I’m someone who does not typically perform well during interviews because of anxiety (but through some miracle has had no issues with employment), so take this response with whatever bias that brings.
I believe this is bad too. You’re still essentially asking a gotcha question, expecting one phrase in your answer and failing the candidate if you don’t hear that phrase. And, in fact, I disagree with the premise. I think the question is defined quite well in the context of programming, given that someone answers with the possibility that there are many ways to hash something and many uses of hashing.
Its not a gotcha question though, is ambiguous to see if you ask for more information or just make assumptions.
We are losing a large account at work because a team provided a solution to a customer based on their initial issues without asking for more info on what the root issue was.
Had they just asked “why are you needing to do this particular thing?” The while solution would have been different.
The hash question is just something from the top of my head. I normally fit it to the situation.
I absolutely take nervousness into account, as I can relate to it.
The thing is, I need to know if the person can push back in some way. it’s a hard thing to do in interviews, but also the first point for me to check how a person reacts
I’ve been bitten too many times, with dev coworkers who don’t give at least a little resistance when vague or stupid tasks show up. Only to notice hours or days later, when something was done completely the wrong way
Every task starts out as a vague idea that, at some point, needs to be narrowed down to something specific and actionable.
If you’re at a sufficiently large organization and you get lucky, that happens before it makes it to a developer. For the rest of us, it’s an important skill to be able to take a task, ask clarifying questions, and narrow it down to something actionable.
Related sidenote: I don’t think I have any form of tism, but something activates when people ask computer science terms where my terrible memory goes “oh yeah I remember the dictionary definition perfectly, punctuations included, let’s recite!”
Also I love the hash exampple. If they start talking about checksums and whatnot, you know their hobby lmao.
The only definition of hash that I know is an identifier for an object created from that object’s data. Everything else stems from that central idea. What other types of hash are there?
Yeah, it’s basically that, but it has different uses - two main things I can think of right away are 1) verifying data when downloading large files and 2) cryptography (e.g. when storing credentials). Oh, and hash tables too.
@SkaveRat
in college I had a prof tell us to get into teams, then give us lego sets to assemble.
they were in the original boxes but the directions had been removed. I was the only one to go up front and ask for the directions and she gave them to me.
Apparently that was the whole point to the excersize. “ask for the resources you need"
When I interview (experienced) devs, I often ask way too generic questions. Something along the lines of “can you explain what a hash is?”, without stating what kind of hash and in what context
The primary goal isn’t really to explain it in detail, but to see if they get confused and ask for clarification. Way too many people just start assuming something, when a task is not defined properly. I need coworkers that push back on bullshit, and not blindly implement whatever runs along their desk, no matter how little sense it makes
If I don’t hear at least one “it depends” during an interview, I don’t have high hopes
I had this with one of my guys. He spent a week working on something and the validation at the end wasn’t jiving.
He started showing me the complex solution and end results and so I said show me how you started and walk me through it.
It was step 1 the origin location of data was out of position.
I said if you start at this origin the rest of the numbers and data will work out.
He replied that the origin wasn’t shown measured from somewhere, so how would we know location.
So I pointed out that the data to origin wasn’t directly spelled out but if you take this measure and subtract this one that is your data origin start.
He said OMG I worked on this for a week trying to get the formulas working. I feel so stupid because you solved it in 1 minute.
I replied its not a question of smart or stupid (because my guy is way beyond me for formulae and programming) its just slowing down and following a process. And if you are confused, ask more questions, rather than just continuing.
Hash? Sure I can hook you up.
Are you sure you’re management material?
(This is a complement)
Two’s complement?
Man, I hope not
Your candidates aren’t mind readers though. If you want people to ask clarifying questions, you have to ask them things other than comp sci trivia questions.
I thinks that’s the whole point, they can’t read minds so they need to ask questions to gain information. So you can makean better response.
When I’ve done support and customer says “This isn’t working I need this bug reported”
The first question I ask is “Why do you need to do that?”
Because just fixing what they asked solves their current issue, but not the underlying pain they have in their process.
100s of techs would just solve the bug, but they you never find out the deeper issue or lack of features that push the customer to using the other thing.
It could be on a different subject, but it has to be a trick question. If they were prompted to ask more, that would undercut the whole point of the test, since OP wants employees that always ask or question.
I don’t think asking someone a trick question in an interview is a good way to gauge if they’ll push back and ask questions on the job. Also, I think that behavior is more related to the employer creating an environment where employees feel safe doing that, and isn’t really something you can draw out of a candidate during an interview, of all times.
Its not a trick question, its an ambiguous one. Ambiguity should prompt people to ask clarifying questions. Assumptions are often wrong.
Part of ambiguity also lies in the English language. In a general conversation 35% is information and 65% is disambiguation.
Well, there’s reason to think it is. Or at least, is for original, insightful questions; anybody can come up with “can I have more time off?”. We live in a society that rewards reliably doing and saying whatever you’re told to, and critical thinking (which isn’t just skepticism!) is super rare when tested for. A lot of college kids with good grades got there because they learned to mindlessly repeat whatever stuff back when tested.
Why that’s rewarded so much, and if there’s a way to encourage and teach actual independent though, are great questions, but that’s not really relevant here.
It’s also a big factor. Since that reply, it’s come up that OP isn’t actually management, but just does interviews. So, maybe they’re looking more for a good colleague than a good employee.
If memory serves, Google used to use these kind of questions, but they stopped because that isn’t actually what they wanted or needed in their workers. A code monkey doesn’t need to question anything, in the end.
Fair point, but depending on the interviewee, you might get very different answers and/or follow up questions.
Even if they assume something, it might be just for the sake of the example. If they’re competent, they’ll follow up with another example and so on, depending on how exactly you pose the problem.
If you present it as an abstract question, one possibility is that you get an abstract answer. If you present it like a ticket with no description, you might get prompted to clarify.
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.
You actually get them all the time, because the programmer is more deeply knowledgeable about the features they wrote and can identify gaps better.
Boss: “Can we move the widget to the left side of the page?”
Programmer: “Sure but that means when the sidebar opens it will obscure the widget, making it hard to see both at the same time. Do we want that?”
Boss: “Hmm I didn’t consider that. Let me ask the UX team what they think.”
“Can we move the widget to the left side of the page” is not in the same category as “what is a hash” though?
I don’t think the “what is a hash” question was a great example, but paired with the rest of the comment and context, I understood their point
So, to start off, I’m someone who does not typically perform well during interviews because of anxiety (but through some miracle has had no issues with employment), so take this response with whatever bias that brings.
I believe this is bad too. You’re still essentially asking a gotcha question, expecting one phrase in your answer and failing the candidate if you don’t hear that phrase. And, in fact, I disagree with the premise. I think the question is defined quite well in the context of programming, given that someone answers with the possibility that there are many ways to hash something and many uses of hashing.
Its not a gotcha question though, is ambiguous to see if you ask for more information or just make assumptions.
We are losing a large account at work because a team provided a solution to a customer based on their initial issues without asking for more info on what the root issue was.
Had they just asked “why are you needing to do this particular thing?” The while solution would have been different.
The hash question is just something from the top of my head. I normally fit it to the situation.
I absolutely take nervousness into account, as I can relate to it.
The thing is, I need to know if the person can push back in some way. it’s a hard thing to do in interviews, but also the first point for me to check how a person reacts
I’ve been bitten too many times, with dev coworkers who don’t give at least a little resistance when vague or stupid tasks show up. Only to notice hours or days later, when something was done completely the wrong way
Sounds like you need to fire the person handing out vague and undefined tasks to everyone 😂
Every task starts out as a vague idea that, at some point, needs to be narrowed down to something specific and actionable.
If you’re at a sufficiently large organization and you get lucky, that happens before it makes it to a developer. For the rest of us, it’s an important skill to be able to take a task, ask clarifying questions, and narrow it down to something actionable.
Listen up every client ever, I’m sorry but I’ll have to let you go.
Well, he did say ”push back on bullshit” soo congrats? 🤭
Related sidenote: I don’t think I have any form of tism, but something activates when people ask computer science terms where my terrible memory goes “oh yeah I remember the dictionary definition perfectly, punctuations included, let’s recite!”
Also I love the hash exampple. If they start talking about checksums and whatnot, you know their hobby lmao.
The only definition of hash that I know is an identifier for an object created from that object’s data. Everything else stems from that central idea. What other types of hash are there?
I smoked some on the way in here to make interviewing more tolerable
I had a can of it and made some Reuben sandwiches.
Yeah, it’s basically that, but it has different uses - two main things I can think of right away are 1) verifying data when downloading large files and 2) cryptography (e.g. when storing credentials). Oh, and hash tables too.
Well, but the question wasn’t “what is a hash used for”, but rather “what is a hash”
The kind you smoke.
If you want something to blindly implement a vague task by making a ton of assumptions, just use AI.
@SkaveRat
in college I had a prof tell us to get into teams, then give us lego sets to assemble.
they were in the original boxes but the directions had been removed. I was the only one to go up front and ask for the directions and she gave them to me.
Apparently that was the whole point to the excersize. “ask for the resources you need"
@kamen