It just amazes me that employers ask complicated CS-type questions for ordinary programming jobs. I've been out of the game for 20 years, and only did a few interviews anyway (as the interviewer), so what would I know! But FWIW, here's the kind of question I'd ask.
"I'm going to write a few lines of code on the whiteboard, tell me what you think of them." The code would be something like this:
If f(a,b) then
X=6
Elseif flag1 then
X=8
Endif
My bet is, people would fall into one of three camps.
(1) The Bemused :-)
These people would have no idea what to say. That would be fine for a new developer, I'd just prod them in the right direction. For example, "what do you think about inline constants?" But if an experienced developer had nothing to say about that code, that would be a big red flag for me.
(2) The Defiant!
These folk would say, "Gee that looks like very old code, I'm really more interested in functional languages, do you guys do any Haskell?" This would also be a big red flag. First, he's saying that he has no interest in my priorities as the interviewer, he'll just ignore my questions and substitute his own. Second, he shows that he's not really interested in code as such. It's like a guy who says he likes cars, you take him around the corner and show him your one-off Porsche EVO hybrid, and he says "Wow, an infinity pool! What did that cost?" Fail.
(3) What I'd Expect
Here's what I'd expect from an experienced developer, off the top of his/her head:
"Ok, I see in-line constants, and short variable and function names. Those are often undesirable, I can talk about that more if you like.
But the more interesting thing, is that X is only set if one of the two conditions is true. If neither condition is true, X does not get set to anything.
That might be a bug: the programmer meant to initialise X before the first test, but forgot. Or perhaps X is initialised much higher up. But if that was the case, I'd like to refactor the code to bring that initialisation closer to the code on the whiteboard; and/or rename X to something less likely to be used by mistake in the middle; or at least, add a comment saying "X initialised above". Or you could just add an else branch to the code on the whiteboard, to ensure that X gets set even when both conditions are false.
Another slight possibility is that when the first condition is false, the second condition is necessarily true, and the developer has written in the second condition as a form of comment. But in that case, I'd rather make it more explicit, by changing "Elseif flag1 then", to "Else /* flag1 must be true */"; or even asserting that, just to be sure.
Also, if the code in question is really complex, or just messy from years of maintenance, there might still be cases where X does not get set at all. In that case you could initialise it to an impossible value, say NULL, right at the start, then assert not null at the end. Or you could even re-write the code in truth table style, which I can talk about more if you'd like."
Me: "The truth table approach sounds good. How would you do that? What kind of data structures would you use?"
And so on.
Does everyone really use CS-type questions these days? Does anyone take the different approach displayed above?
My first thought is, "This looks like a snippet of code completely made up or taken out of context and then anonymized by renaming variables. I have no idea what it's supposed to do, I have no idea why I'm looking at it, and I have no fucking idea what the interviewer wants form me, and I don't play guess-the-rules type of games." If this were real code, I'd have context. Not just a snippet. I'd see the things I don't see in the snippet, and I'd know why I'm looking at it and what I'm looking for. In real work, there is always a motivation for everything you do. In this case, there is none. You might as well show a sequence of bits. "What do you think of these bits?"
So by your prejudice, you'd probably categorize me in the first camp. Congrats, you probably turned down someone who's been coding for 20 years. Then again, if this really is the kind of line of business code you regularly deal with, maybe it's for the (my) best.
This is a pattern I see all the time. Interviewers come up with their games with their arbitrary rules and a bunch of prejudice about how a good or bad candidate should react. They think they came up with something clever, they always do. They have no idea.
I get the impression that good people get regularly turned down because they didn't guess the rules of the game right, or they don't even play because they got an offer at some place that doesn't play these silly games. Then there is so much complaining about talent shortage, and complaining about terrible interview practices, and complaining about having to deal with a stack of 1000 job applications.
> Interviewers come up with their games with their arbitrary rules and a bunch of prejudice about how a good or bad candidate should react.
Agreed that a lot of interviewing issues that I've seen boil down to a misunderstanding of the rules/expectations of an interview, which can be problematic on both sides. Some examples:
* I've had candidates do poorly on a warm-up question because they expect it will be difficult. Ideally, they would say the easy answer they know, but I've had candidates stay quiet while thinking of a hard solution that doesn't exist, then get frustrated when they find that the easy answer is what I was looking for. On my end, this problem is especially tricky because I don't necessarily want to say that something is a warm-up question.
* I've had candidates who have had trouble because they viewed problems as either too concrete or too open-ended. In some cases, I hope that candidates will notice ambiguities in the problem and ask clarifying questions, or come up with creative alternate solutions. In other cases, I know that a particular high-level structure makes a good, consistent problem, and I want them to follow that structure.
* I've had candidates who have written code that's either too hacky/messy/unpolished or too professional such that it slows them down.
My best advice to interviewers is to be straightforward about expectations and open-minded about what assumptions the candidate might have coming in. For example, these days, I try to explain the code quality balance I'm looking for, something like "I'm looking for reasonably production-quality code that might pass code review, but it's still an interview setting, so it's fine to leave off things like docs and unit tests".
I think my best advice to interviewees is to keep a conversation going and be open about your thought process and your assumptions. If you're interpreting the problem wrong, a reasonable interviewer should be able to notice and correct that. The main failure mode I've seen here is people being hesitant to communicate their thought process or ask clarifying questions, which means the interviewer isn't able to know when the candidate is doing poorly because they've misunderstood the problem.
The last two places I interviewed with, there was none of this puzzling or challenges or problem solving. No warm up questions. No games, no rules. We just had introductions and then chatter about what I've done, the tools I've used, how I prefer to work, that kind of stuff. The second place didn't even ask to see any code even though I'd prepared to show them some and had my laptop open on the table. I presume both places trusted I know how to code and solve problems, since both offered a position and even tried to outbid each other.
I really liked this type of interview. It's not so much an evaluation of coding skill as it is a way to get to know the candidate.
With offers lined up, I turned down interview invites from other shops that were publicly complaining about talent shortage and simultaneously had a needlessly complicated & time consuming interview pipeline. I think companies are overthinking it.
First, if you truly believe that the code I showed is "a snippet of code completely made up or taken out of context and then anonymized by renaming variables", I can only say that I don't believe you've ever worked on large codebases. There are millions of lines of code, in hundreds of thousands of application, in dozens of different languages, all over the world, precisely like the snipped I showed. If you've been coding for 20 years, as you say you have, and haven't seen snippets like that on a thousand occasions, you must have worked in very strange environments. If you really want me to, I'll spend 5 minutes and give you multiple links to exactly similar snippets in various large open source projects.
Second, I'm mystified by your comments regarding my trivially simple code question. that "Interviewers come up with their games with their arbitrary rules and a bunch of prejudice about how a good or bad candidate should react".
Wut? Let's make the question even simpler:
X := Y / Z
Would you not expect an applicant to say, "What if Z is zero?" ? Would you actually expect the candidate to say - quoting you:
"This looks like a snippet of code completely made up or taken out of context and then anonymized by renaming variables. I have no idea what it's supposed to do, I have no idea why I'm looking at it, and I have no fucking idea what you want from me, and I don't play guess-the-rules type of games."
Are you seriously telling me that you'd hire a candidate who said that? Over one who said, "What if Z is zero?" ?
Once again you posted a snippet without context or meaning. Once again it's like "what do you think of these bits?" Except that you didn't even ask a question. You just posted something that is presumably code.
So it's hard to engage meaningfully. Give me motivation. Tell me what I'm doing or why I'm looking at this code in the first place. Show me the context and maybe I will see whether I should care about Z possibly being zero or not. Tell me what the language is or how it handles divide by zero (does it have exceptions?) and I might figure out that we don't give a fuck about divide by zero because it's handled elsewhere or not at all relevant to this snippet. I regularly write divisions without zero check because I know the divisor is a positive compile time constant. Here, I just see a snippet out of context; again my thought is "what the hell does this guy want from me?" Show me real code with real context and a real purpose so we can talk real talk.
What's wrong with my x /= z;? Nothing, it's doing the perspective divide just right. And you don't go about checking for divide by zero because I've already clipped my primitives. There's nothing wrong with the names either.
Sure the snippet you posted could be a snippet from some real codebase but without context it is nothing. What do you think of 100101010100000100010001000110? Sorry, wrong answer! Next guy please. That's also real binary from a real file and it's easy to figure out what it says but hard to say what I want from you. Try it!
> I can only say that I don't believe you've ever worked on large codebases.
I don't suppose the operating systems and web browsers I've worked on are the largest of them all but damn. You can keep your religion though.
In a parallel universe, a candidate who is worried about a divisor of zero has his head stuck in the tiny details and is unable to do big-picture thinking. Personally I've gone my entire career without seeing a divide-by-zero bug. It's the last thing on my mind. If it's possible for Z to be zero, it will be caught in CI before we deploy/cut a release.
In your first snippet, would you expect a candidate to tell you that `f` might be undefined?
> In your first snippet, would you expect a candidate to tell you that `f` might be undefined?
No. Because I'd expect the candidate to focus on subtle issues, and not waste time on bleeding obvious ones!
Of course f() might be undefined. Blind Freddy knows that. But Blind Freddy can't necessarily see the other (much more subtle) problems in those 4 lines of code.
I want to know, is this candidate more than Blind Freddy? Does he inhabit what some of us call "the real world", where things like division by zero are things to be consciously managed by proper coding practices?
As someone who has worked on several legacy JS codebases, I can tell you with certainty that in some kinds of projects you'll find in the "real world", `f` being undefined is infinitely more likely than a divisor being zero. Maybe Freddy isn't blind. Maybe he just has a different background than you.
Quite possibly. I've worked mainly in languages where undefined functions kill the compile, and division by zero is a runtime error. Perhaps JavaScript just facilitates sloppy coding practices? Many other languages don't. Perhaps you're the one with the skewed perspective!
I posted a detailed exposition of my own approach to interviewing. I expected nothing more than some intelligent comments thereon.
In response, someone says I'm "prejudiced", and why would he "give a fuck" about my concerns; another says my concerns exist "in a parallel universe"; and another says my views are "religious"!
Equeeze me if I don't take well to copping random insults in what is meant to be an intelligent discussion forum. Particularly from people who've contributed zero to the discussion so far - like you! I suggest you get out of the basement and get some exercise. Maybe ask your mum for a bike?
Asking someone to evaluate code that doesn't mean or do anything seems like a very poor idea. 90% of the important questions are whether you're doing the right thing in the first place, not whether you're using the Hot Trick of the Day.
Huh? (1) It's exactly the kind of code that you'll commonly see in a working line of business application. (2) The entire point of my comment is that I dislike hot tricks of the day as interview questions. What "hot trick of the day" do you see in my post?
> Does anyone take the different approach displayed above?
I do. I find getting people to reason about code is a great method of finding who can program. Given we read a lot more code that we write, it's a critical skill. Often people seem to get hung up on the stylistic issues though and don't recognize obvious bugs.
More importantly, it's code _they_ didn't write, so it removes the natural inclination to be defensive about it.
One time an interviewee told me the problem was that the code was in Java. I told them that the majority of the code we write was in Java (as per the job description). They told me that our best option was to rewrite everything in Ruby.
I hope you're more communicative about what you're asking in person than that one liner you introduced the code with here.
I'd fail your interview just because I don't think about whiteboard code the way I think about production code. Yeah, the variable names and magic numbers are bad practice--but it's on a whiteboard. I'm not going to waste time writing long descriptive names out by hand on a whiteboard or in pseudocode. It would never occur to me, because of the context, that you're asking me to respond like I'm reviewing production code unless you specifically said that.
> I don't think about whiteboard code the way I think about production code.
Isn't that the whole point of an interviewer writing code on the whiteboard? To see how the applicant would view that code if hired to work in the offered position? Why would an interviewer want the applicant to view that code in any other way? Is an interviewer likely to think, "I'll treat the interviewee's comments as if he was just writing the code as a hobby throwaway, nothing to do with the offered position"?
> the variable names and magic numbers are bad practice / but it's on a whiteboard. I'm not going to waste time writing long descriptive names out by hand on a whiteboard
Great! But in my post the interviewer wrote the code on the whiteboard. The interviewer did not ask the interviewee to write any code on the whiteboard. Where did you get the idea that the interviewee was to write on the whiteboard? Software development requires attention to detail, yes?
"I'm going to write a few lines of code on the whiteboard, tell me what you think of them." The code would be something like this:
My bet is, people would fall into one of three camps.(1) The Bemused :-)
These people would have no idea what to say. That would be fine for a new developer, I'd just prod them in the right direction. For example, "what do you think about inline constants?" But if an experienced developer had nothing to say about that code, that would be a big red flag for me.
(2) The Defiant!
These folk would say, "Gee that looks like very old code, I'm really more interested in functional languages, do you guys do any Haskell?" This would also be a big red flag. First, he's saying that he has no interest in my priorities as the interviewer, he'll just ignore my questions and substitute his own. Second, he shows that he's not really interested in code as such. It's like a guy who says he likes cars, you take him around the corner and show him your one-off Porsche EVO hybrid, and he says "Wow, an infinity pool! What did that cost?" Fail.
(3) What I'd Expect
Here's what I'd expect from an experienced developer, off the top of his/her head:
"Ok, I see in-line constants, and short variable and function names. Those are often undesirable, I can talk about that more if you like.
But the more interesting thing, is that X is only set if one of the two conditions is true. If neither condition is true, X does not get set to anything.
That might be a bug: the programmer meant to initialise X before the first test, but forgot. Or perhaps X is initialised much higher up. But if that was the case, I'd like to refactor the code to bring that initialisation closer to the code on the whiteboard; and/or rename X to something less likely to be used by mistake in the middle; or at least, add a comment saying "X initialised above". Or you could just add an else branch to the code on the whiteboard, to ensure that X gets set even when both conditions are false.
Another slight possibility is that when the first condition is false, the second condition is necessarily true, and the developer has written in the second condition as a form of comment. But in that case, I'd rather make it more explicit, by changing "Elseif flag1 then", to "Else /* flag1 must be true */"; or even asserting that, just to be sure.
Also, if the code in question is really complex, or just messy from years of maintenance, there might still be cases where X does not get set at all. In that case you could initialise it to an impossible value, say NULL, right at the start, then assert not null at the end. Or you could even re-write the code in truth table style, which I can talk about more if you'd like."
Me: "The truth table approach sounds good. How would you do that? What kind of data structures would you use?"
And so on.
Does everyone really use CS-type questions these days? Does anyone take the different approach displayed above?