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
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.
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.
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.
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.
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.
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.
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.
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"
If you hand out a problem and only accept one solution out of multiple valid ones, you’re part of the problem.
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
Hash? Sure I can hook you up.
Are you sure you’re management material?
(This is a complement)
Man, I hope not
Two’s complement?
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.
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.
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.
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.”
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.
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.
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? 🤭
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.
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