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 int

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?