I don't even ask softball questions. Mine are more like tee-ball questions. Too often, the tee pitches a perfect game.

http://blog.interviewing.io/you-cant-fix-diversity-in-tech-w...

The salient point is about halfway through when they put up the big chart of a couple thousand interviews and the stddev vs. mean of technical score, and say:

As you can see, roughly 25% of interviewees are consistent in their performance, but the rest are all over the place. And over a third of people with a high mean (>=3) technical performance bombed at least one interview.

Now, what this points to is a very clear failure of these standardized interviews with their allegedly "tee-ball" questions, because the results shown would be astoundingly unlikely in a world in which the interview process had any kind of consistency in identifying technical skill.

So, no. You're not doing what you think you're doing, and if you've got a high failure rate the problem is almost assuredly not with the candidates. It's with your interview process, or with you.

Also, forked repos are fairly obvious, and there's a dropdown to just show source repos, and if they are manually forking to prevent it from showing as a fork on there, that's a pretty shady indicator that you may want to follow up on...

An interview is not like the SAT. And even the SAT is not an unbiased test.

I honestly don't want to have to test if someone can handle a simple algorithm. (I'm not talking about anything crazy here, mind you.) Can they read code? Can they think about how to test?

I've seen faked code samples, and our test has a half dozen answers on github.

I want to just assume that anybody with five years of programming experience can code, but I've worked alongside enough counterexamples that I know I can't assume that.

That said, I'd really rather not have to deal with it as a candidate or as an interviewer.

If someone asked me a problem that basically reduced to a textbook case of something in the middle, difficulty wise, like reservoir sampling, and I said "oh, nifty, resevoir sampling, what do you use that for in your stack?" and they said "nothing, I just want to make sure you can code," then depending on how my experience to that point in the process had been going I might challenge them on that to some extent, a la "do you find this more useful than questions that are more representative of the work you're expecting me to do?" If the loop had been going particularly robotically, this might find stronger forms - I've walked out on a mismanaged interview before, though it was way worse than this (and way worse in a very different way - they just weren't at all prepared and the tooling they wanted me to use wasn't actually functional).

Or they might answer something more like "we use it to select test cases from our logs to ensure that we're adequately testing against real behavior with proper weights" (or whatever—it's been a while since I actually did this in a past job :) ) in which case I'd still try to have what I consider a more "real" conversation ("what primary problem are we trying to solve, and what else might be options to consider"), but in that case at least they had a good answer to the question and I'd be happy to write the code too.

But lastly, frankly, as a hiring manager I absolutely want to hire people who are willing to "not focus on the task at hand" and question things. I don't want people who just blindly do what I tell them to, I want people I can trust to disagree with me and be able to make a case for why they disagree. Being a manager doesn't mean my instincts are 100% and theirs are 0%.

Yes, because tasks representative of the work we're expecting you to do are too obvious and simple for an interview 95% of the time, and are too hard and take too long for an interview 5% of the time.

It's kind of like asking someone interviewing to be a cashier at a fast food restaurant multivariable calculus problems, because 95% of the math they're going to have to do at their job is "too obvious and simple".

If these high-priority and hard 5% were easily separable from the tedious 95%, this logic would be correct.

This seems a little too general to me. Many things are not clearly thought out, and I'd rather work with people who can recognize when that is the case and communicate well enough to correct the course. A big part of successful development in my experience is knowing when not to implement things, or having foresight to implement things in a better way. Working with people who just do what they're told is often a huge waste of time.

And those people are what we call “assholes”.

Everyone makes mistakes. If you make a habit of questioning people’s competence because they make mistakes, and didn’t ace your whiteboard coding tests beforehand, you are 100% the source of the problem in this industry.

I only take issue with this. Many things in organizations that have been through explosive growth (and sometimes others) are that way because for no reason in particular and amount to bandaids upon bandaids because nobody's ever had a chance to actually look at the process. It very well might suck. Questioning it is the first step in making it not suck.

That said, as an interviewee is probably not the right time to do so. You're an outsider, you have very little rapport or relatability compared to the people that already work there. Even if you can point to something and unambiguously prove that They're Doing It Wrong, your advice isn't in a position to be heeded.

Moving the bit about the scope of the role (jr vs sr vs lead) up to preface the rest of the comment would've toned it down a bit, but even there I disagree with the "taking a risk" part - a senior candidate shouldn't feel like it's risky to offer alternative perspectives. If I got the impression that the hiring manager thought asking questions would likely be a sign of "cannot focus on the task at hand," that's going to set off my own flags a bit.

If you're married to your interview process I'm worried you'd be even more married to your day-to-day process, and I haven't met a perfect company yet, so I consider being overly adherent to process instead of results a warning sign.

Also, as an interviewee, you stand to learn a lot more from that interaction than by rejecting it. Hell, I welcome coding challenges as an opportunity to size up the interviewer's chops!

If the challenge is conducted in a reasonable way, it should feel like any other design/pair programming session you've had at the office, and it can be quite revealing of the tendencies of your potential colleagues.

  > Also, as an interviewee, you stand to learn a lot more
  > from that interaction than by rejecting it.

   > question things that have clearly been thought out
   > ahead of time.

Call me old fashioned, but I thought that was my job as an engineer. To question things and find ways to fix/improve them.

Am I wrong?

If you're focusing on the trivia, you're probably too focused on the code and not on solving the problem -- my experience tends to be that there's at least one or two interesting edge cases you encounter if you try the naive approach, and those are generally what the interviewer wants to discuss. The reason is that discovering edge cases in requirements and solving them is what a lot of the job is, and so how you approach that matters (and to an extent, more than if your code on the board is "correct").

Another approach is to extend the problem by asking clarifying questions -- if there's something unspecified that might influence your design, ask about it and tell the interviewer why it matters. Again, this generally is more what they care about than the details of the coding.

Finally, if those skills make you an asset -- why not apply them to the question? Even tangentially by talking about how you would (if you had more time/were doing a real assignment).

Coding on the white board is more about the journey than the coding, assuming you can write vaguely correct code. (Though writing on a whiteboard is definitely a skill you have to practice.)

"That's a cool problem. I'm curious though - I didn't see that on the job description. I'm not expert on that, and I didn't bone up on that last night. (ha ha everyone laughs)

I can step through it if you want, but it would help me if I knew why you asked about this. If you're looking to understand how I solve problems, that's okay, I'll muddle my way through it and ask if I need any clarifications."

They'll tell you. Interviewers often hold similar views to the candidates, but may be asking for a different reason than you think.

After the interview was done I questioned the person why have another coding test. He said it was to test on different areas of programming. I later messaged the VP/CTO who wrote the blog post on not having live coding test. The person apologized for the experience and said that the team I interviewed for did not come under engineering org. It was a frustrating experience but at least the person responded positively.

real life example: an MIT PhD in distributed computing walks into the room, looking extremely tired from interviewing people like me. I can tell this is going to be rough unless I'm controlling the conversation and we have a good rapport.

He's wearing a Fender shirt. I have played guitar a bit. After he introduces himself and I myself I open with, "Oh nice shirt. I assume you play some guitar?" and there goes 20 minutes of the interview talking about guitars.

So long as I don't completely bomb the technical aspect I've left this person with a positive and relatable experience.

I have been on both sides of the equation.

My stories:

1) Brain teaser questions sometimes aren't as easy or as straightforward as everybody thinks--don't ask them as an interviewer unless you genuinely KNOW the question.

Digital VLSI design loops almost always have a question that makes you use a state machine--this is actually a decent question for a whiteboard as long as you don't do something stupid like use J-K flip flops in CMOS. There are a host of basic questions you can use ... but beware of traps.

I was once asked the following question: "You have a serial bitstream that represents a binary number. Keep track of the value of that number modulo 3." This is a decent question ...

Or a really hard question ... depending upon whether the number is being clocked in MSB first or LSB first.

Unfortunately, when I wrote the numbers down on the whiteboard, I chose the "hard" direction. And had to really think ... and the interviewer kept getting more and more agitated and finally complained "Look, this is easy, just do 3 states like this". To which my response was "But clock in any of the numbers in that I wrote on the board. Your machine fails at the second clock."

His machine, of course, works just fine for one direction. But that wasn't the direction I picked and documented picking by writing it on the whiteboard. And his machine didn't work with the bitstreams I chose. And 20 minutes wasn't enough for me to see what he got wrong and demonstrate it back. And he didn't understand his question well enough to flag the reverse order.

Exercise for the reader: There are two answers to the question depending upon MSB-first or LSB-first. One answer only requires 3 states. The other answer requires 6 states, but it is NOT clear that 6 states are enough without some serious thought (you can prove 6 are enough inductively if you are clever).

2) I used to always bring to electrical engineering interviews 2 printouts with the same program--one in Python and one in Perl. This meant that when I was asked "Do you know Perl?" I could force the interviewer into MY subset of Perl--and I could explain why I avoided Perl nowadays with a compare and contrast. This simply steamrolled all but one interviewer.

3) I was interviewing with an RF company who was needing VLSI digital designers. A poor slob of an analog engineer drew the short straw for handling the digital questions and was so completely out of his depth that I felt sorry for him. After about half the interview of glazing his eyes with advanced digital architecture, I threw him a bone. I made an off-handed comment about digital really not being digital and how the old audio guys used to use the 4000-series CMOS inverters as audio amplifiers. Baited and hooked. We spent the rest of the interview discussing that as an audio amp (of course, I knew the answers to that question cold--that's why I mentioned it).

4) As an interviewer, I used to run a really difficult section of the VLSI design loop which used to intimidate candidates horribly. I had very stern words with HR that my section was supposed to always be at the end (we almost lost a REALLY excellent candidate because he hit me first, did excellently but THOUGHT he bombed, and then flubbed everybody else afterward). I only had a couple of questions, but they were bottomless. If I had a PhD in front of me, I could make him explain complicated things. If I had a newbie in font of me, I would take him one step further than he was comfortable with and see how he reacted. The candidate steered the interview, but within the bounds I set.

5) My favorite interview was when an interviewer asked me my own difficult question back. It took a moment until I realized exactly what he did, and then I launched 30 minutes into the bottomless pit until I was sure that everybody had glazed eyes and then some. We all had a good laugh afterwards.