Live data from Hacker News

Microsoft Job Interview Questions

asserttrue.blogspot.com

11–20 of 36 posts

Re: Microsoft Job Interview Questions

#11
post #5

Three things: First, those are questions for a variety of different positions all mixed together. Product manager candidates get asked different questions than engineering candidates. Second, yes, Microsoft tracks the effectiveness of interviewers based on the outcome of the interview loops and the performance of the people who get hired. Third, all of the questions listed, no matter how trivial they seem, are dispos…

"Third, all of the questions listed, no matter how trivial they seem, are dispositive. I've interviewed engineering candidates with PhD's from top tier universities who couldn't reverse a linked list when asked, or who couldn't even explain basic concepts in their putative focus areas. You have to ask the seemingly stupid stuff -- it's a continual surprise." While there are certainly idiots with PhDs, if you've got a…

"Gets-things-done" people prepare for technical interviews, such that they don't flub simple questions. The danger for the employer is that lots of Computer Science PhDs end up not writing much code during their research, and may not be a good fit at many tech employers.

"Interview for Smart and Gets Things Done" is an accurate explanatory abstraction over what good interviewers do, but it's not prescriptive enough to tell people what questions to ask and how to judge the results.

Re: Microsoft Job Interview Questions

#12
post #8

I've been asked some of those questions at other top-tier tech companies (that the author isn't criticizing). Conducting good interviews is hard. Watching someone attack a problem or write some whiteboard code is a not-bad system. Pick a problem that's too small or familiar and you're not filtering enough. Pick problems that are too hard or long and nobody will succeed. It's a balancing act.

I don't know about you, but writing code standing up at a whiteboard while others watch just doesn't feel very natural to me. Why not give them a PC and a small development task and leave them alone for a bit and then talk over their solution once it is complete?

It's a good idea, and I think it would make an excellent supplement to current interview practices. There would be some difficult logistical issues: Unfamiliar dev environment, etc. It wouldn't replace whiteboard coding, since you lose the ability to test for culture fit, give hints, examine thought process, ask about small decisions, get a gut check and other aspects of whiteboard coding that have nothing to do with the specific question asked.

Some companies ask for a small code sample "that you're proud of" in advance of onsite interviews, I think that's another good practice.

Re: Microsoft Job Interview Questions

#13

Three things: First, those are questions for a variety of different positions all mixed together. Product manager candidates get asked different questions than engineering candidates. Second, yes, Microsoft tracks the effectiveness of interviewers based on the outcome of the interview loops and the performance of the people who get hired. Third, all of the questions listed, no matter how trivial they seem, are dispos…

I don't know how it works in the US, but in the UK a PhD is usually awarded based purely on research - there is relatively little cutting edge research that I am aware of that hinges on manipulating linked lists. :-)

Re: Microsoft Job Interview Questions

#14
post #5

Earlier quoted context omitted.

"Third, all of the questions listed, no matter how trivial they seem, are dispositive. I've interviewed engineering candidates with PhD's from top tier universities who couldn't reverse a linked list when asked, or who couldn't even explain basic concepts in their putative focus areas. You have to ask the seemingly stupid stuff -- it's a continual surprise." While there are certainly idiots with PhDs, if you've got a…

"Gets-things-done" people prepare for technical interviews, such that they don't flub simple questions. The danger for the employer is that lots of Computer Science PhDs end up not writing much code during their research, and may not be a good fit at many tech employers. "Interview for Smart and Gets Things Done" is an accurate explanatory abstraction over what good interviewers do, but it's not prescriptive enough t…

"'Gets-things-done' people prepare for technical interviews, such that they don't flub simple questions."

So, let's be clear: you're admitting that you're screening for a trait that you assume is correlated with the trait that you actually want. I don't grant the assumption, but it should at least be explicitly stated.

"The danger for the employer is that lots of Computer Science PhDs end up not writing much code during their research, and may not be a good fit at many tech employers."

How many computer science PhDs have you hired, let alone interviewed? I'd wager that it's not enough for you to be able to make this judgment with any confidence. And even if you're right, how does asking questions about linked-list reversal address the question of the tendency of a person to do practical work? Aside from tech interviews, I've never once in my life had to write a linked-list reversing routine.

Look, I'm not saying "don't ask coding questions" -- I'm saying that we need to start being reasonable. Don't assume that a candidate is a no-hire simply because that they haven't pre-memorized the algorithms for the questions that you're asking. It's ridiculous that we're screening people based on the number of silly tricks that they can memorize from interview question websites.

Re: Microsoft Job Interview Questions

#15
post #5

Three things: First, those are questions for a variety of different positions all mixed together. Product manager candidates get asked different questions than engineering candidates. Second, yes, Microsoft tracks the effectiveness of interviewers based on the outcome of the interview loops and the performance of the people who get hired. Third, all of the questions listed, no matter how trivial they seem, are dispos…

"Third, all of the questions listed, no matter how trivial they seem, are dispositive. I've interviewed engineering candidates with PhD's from top tier universities who couldn't reverse a linked list when asked, or who couldn't even explain basic concepts in their putative focus areas. You have to ask the seemingly stupid stuff -- it's a continual surprise." While there are certainly idiots with PhDs, if you've got a…

Reversing a linked list is not an Alan-Turing-level problem.

I've used the reverse-a-list problem (and others of a broadly similar kind) in interviews. It shouldn't matter at all if a candidate hasn't read or written any list-manipulation code in years; that gives them the chance to sit and scribble some diagrams for me and work out how to do it. I don't mind much if they don't end up with a beautifully neat solution. I want to know things like: Did they check for edge cases? Did they blunder around trying things until they got code they couldn't prove was wrong, or did they work out something that ought to work and then implement it, or what? Did they ask themselves questions like "what facts ought always to be true at this point in the code?"? If they produce an inelegant or inefficient solution and I say "So what happens if you do X?" or "Could you do anything about Y?", do they panic and freeze or do they get thinking about the question? These are not a matter of having crammed their heads with algorithm esoterica. They're a matter of being reasonably comfortable with code, and being a problem-solver rather than a copy-and-paste artist.

I'm quite sure there are plenty of software developer jobs that can in fact be done by someone who's fundamentally not very comfortable thinking about code, and/or who has little interest in problem-solving or little aptitude for it. It happens that those aren't the jobs I've interviewed people for, but they're real enough and collectively they probably account for a majority of the value added to society by software development. But when you're interviewing for a job that does call for independent thinking and fluent code reading and writing, that sort of question -- if used correctly -- is very valuable.

Of course, an interviewer who thinks the point is to say "Write me some code that reverses a linked list" and then vote yes if the candidate does it on the spot and no otherwise, is going to reject some good candidates and accept some bad ones. But an interviewer who thinks that way is going to get lousy results regardless.

Re: Microsoft Job Interview Questions

#16
My problem with the coding questions (other than the fact that everyone has seen them) is that they're too shallow. So the questions are binary. If you can't do them, interview over, sure. But if you can do them they don't say that much. They're almost short enough to count as trivia.

I prefer asking for a program that will take about an hour, but will also get a range of correct answers and mistakes. The ideal question has maximum dispersion, like a good hash function. You can observe a variety of strengths and weaknesses, and the horrible candidates will cry, the mediocre candidates will cringe, the good candidates will nod, and the strong candidates will laugh.

Re: Microsoft Job Interview Questions

#17
post #5

Three things: First, those are questions for a variety of different positions all mixed together. Product manager candidates get asked different questions than engineering candidates. Second, yes, Microsoft tracks the effectiveness of interviewers based on the outcome of the interview loops and the performance of the people who get hired. Third, all of the questions listed, no matter how trivial they seem, are dispos…

"Third, all of the questions listed, no matter how trivial they seem, are dispositive. I've interviewed engineering candidates with PhD's from top tier universities who couldn't reverse a linked list when asked, or who couldn't even explain basic concepts in their putative focus areas. You have to ask the seemingly stupid stuff -- it's a continual surprise." While there are certainly idiots with PhDs, if you've got a…

I could not agree more. The thing I finally realized is, it doesn't matter. Someone who will struggle reversing a linked list will struggle on any coding problem, no matter how simple. The one I ask is: given a string, return a hash where the keys are each letter in the string, and the values are how often it appears: "hello" becomes

    {"h"=>1, "e"=>1, "l"=>2", "o"=>1"}
This question has stumped almost everyone I have asked it to. Either they just sat there and wouldn't code it, or they made insane mistakes like getting the syntax of writing a function wrong, or they couldn't write a loop that worked.

I let them do it on a laptop, I let them look at any API documentation they want, and I offer them help when they're stuck. It doesn't matter. Would they also flail trying to reverse a linked list? Sure, definitely. But why bother? This is the simplest thing that will cause non-programmers to flail, so why make it hard?

Plus the added benefit: a manager might claim "when will they ever need to reverse a linked list?" but nobody's going to say that writing a loop is unreasonable.

Re: Microsoft Job Interview Questions

#18
post #7

Write code that returns the length of a string without using any built-in functions. It took me a while to realize that they're probably not counting infix operators that behave like functions except for the syntax. Accomplishing this task in Lisp or Haskell would be nearly impossible.

Then don't write it in Lisp or Haskell. If they don't specify a language, use one that makes sense.

Re: Microsoft Job Interview Questions

#19
post #14

Earlier quoted context omitted.

"Gets-things-done" people prepare for technical interviews, such that they don't flub simple questions. The danger for the employer is that lots of Computer Science PhDs end up not writing much code during their research, and may not be a good fit at many tech employers. "Interview for Smart and Gets Things Done" is an accurate explanatory abstraction over what good interviewers do, but it's not prescriptive enough t…

"'Gets-things-done' people prepare for technical interviews, such that they don't flub simple questions." So, let's be clear: you're admitting that you're screening for a trait that you assume is correlated with the trait that you actually want. I don't grant the assumption, but it should at least be explicitly stated. "The danger for the employer is that lots of Computer Science PhDs end up not writing much code dur…

I think by and large we agree: It's wrong to expect memorized answers or to ask questions that are so narrow that they only test whether a candidate spent time studying. I'd even go so far as to say that algorithmic questions are probably not good indicators for skill at many kinds of work we would call "programming"---i.e. Programming skill is more heterogeneous than many interviewers admit. We shouldn't expect a jQuery wiz to nail low-level data structure questions, and we shouldn't expect a bit-twiddling video codec developer to really grok method chaining in 30 minutes.

The trouble with "Be reasonable" is that's it's the advice equivalent of a tautology. Of course we should be reasonable when interviewing. But I don't think there's widespread agreement about how to operationalize that. I'd be curious for more detail about how you would do it---you seem to have strong, well-informed feelings on this issue.

To my knowledge, there's basically no publicly-available research on tech interview factors and how they correlate with on-the-job performance. The good big employers do this research internally and keep it to themselves. The rest of us are stuck with assumptions, intuitions, logic and argument. So unfortunately I don't think we'll be able to get the debate into the realm of interpreting real data anytime soon.

Re: Microsoft Job Interview Questions

#20
post #16

My problem with the coding questions (other than the fact that everyone has seen them) is that they're too shallow. So the questions are binary. If you can't do them, interview over, sure. But if you can do them they don't say that much. They're almost short enough to count as trivia. I prefer asking for a program that will take about an hour, but will also get a range of correct answers and mistakes. The ideal quest…

Could you give some concrete examples of the sorts of programs you mean?
Post reply on HN