and that's what makes it ridiculous. In my whole career I have not been forced to vocalize hard problems on a whiteboard in one hour, getting judged for how good of a dog and pony show I put on with "evaluating and discarding ideas" on the fly, out loud, in an interrogation setup. This is so artificial. Not even close to how real teams work. My best ideas start to really form after thinking about a hard problem for days, including in off hours, background mode. Often I have to talk to many people, including non-programmers, to cover all angles of a hard problem.

These "hard interview problems" that must be solved through some artificially staged contemplation really are useful for two reasons:

* it's sadly the only way to quickly try to get a random reading of a person in a semi-standardized way while minimizing time commitment, kind of like fast food is the quickest way to fill oneself, and

* people who pass these at least demonstrate that they can drill/memorize or otherwise prepare for a challenging activity, which takes time and discipline, which in general are desirable characteristics

that's it, pretending like this in any way models real work or has any other benefits is not right.

> This is so artificial.

Right. It's an interview - artificial by definition, not meant to be perfect; in fact perfection in hiring (or in anything) is unachievable - we aim for the "good enough".

> Often I have to talk to many people, including non-programmers, to cover all angles of a hard problem.

Here we are - me and my colleague - there to answer questions, reflect on your thoughts, etc. Talk to us, that's exactly what I expect. Not just to give solutions, but to clarify the problem (for you and for us). Make us understand how you're looking at it - we'll also share our perspective and see if we can come up with something together.

Is this really something that you don't see happening, in practice?

That's why I think that interview challenges should be "easy". E.g. something like "Make a number guessing game."

1. It's easy enough so you can talk and explain while solving it.

2. It can show your ability to split problems into smaller subproblems.

3. It maybe filters people that just memorize a bunch of solutions, since it's open how exactly you solve it.

Depends what you're testing for. If I'm testing for problem-solving skills, I will pick increasingly harder problems, until you can't solve them. I will judge you on how well you performed on the one you couldn't solve.

The problem is that you can't just solve the hard problems (e.g. those from hackerrack) like that by just thinking about it for some time (it would probably need hours or days of research).

You just have to learn and remember some obscure algorithm to solve them. That just filter for "unexperienced" people that have enough time to actually learn a lot of algorithms by heart.

I.e. that would be fresh graduates. But then you could just look at their uni grades, if you want people who are good at learning.

> The problem is that you can't just solve the hard problems

Which is why I said I don't expect them to solve the problem, I'm interested to see:

- the general thought process - whether the candidate is inclined to jump at the solution or clarify the problem (neither approach is "disqualifying", btw! but for a senior position I do kinda' expect the candidate to recognize when a specification is incomplete, and I will provide increasingly ambiguous problems/questions to see when he stops making assumptions) - that the candidate is capable to identify some "leads"/ subproblems that need to be solved first/ to reduce the problem to a different one/ etc.

> But then you could just look at their uni grades, if you want people who are good at learning.

If only it was so simple... some people are good at learning, they just don't have good grades (e.g. they have to work to support themselves and don't care much about some grades); while others are good at getting generally good grades without actually being good learners (extreme example: cheaters).

And the candidate has no way of knowing what you expect, he's just been given a problem to solve.

One time I was rejected for not identifying and discarding some particularly stupid attempt at doing something (it involved assuming that it was safe to trust input coming to the server over HTTP), but I have explained to people not to do that so many times that I really don't consider doing things that way in the first place.

That's why he can ask if he doesn't know what we expect. Silence is the worst option - we're there to form an impression on you (an accurate one, hopefully) - if you just sit there silently, it won't help us.

(I actually ask the candidate to talk us through his thinking process if I see him sitting there; I start asking questions if he still refuses. I realize that it's an artificial setting, where many people feel pressure to "perform well" rather than just be themselves; unfortunately, I have found no better solution to hiring, that would make the interview unnecessary in all situations)

Please be comfortable and be yourself...but we'll have you vocalize your thought process even though this is something you never do while working, you have no experience doing and it makes it tougher to think while you're talking.

If someone was a great coder but a mute, your process would weed them out.

But why do you assume such extreme inflexibility? I actually interviewed a blind person, and believe me, I didn't write/draw stuff and expect him to be able to read it.

Process is about the rule, not the exception. If you don't have killer credentials, and don't do well on the "whiteboard interview", what will happen is that we assume you might not handle pressure well/ are timid, and we'll give you a fairly consistent "homework" (e.g. "fix this Firefox bug, or at the very least analyze the root cause/ how it should be fixed. Send us a log of what you did to narrow down on the issue and on the solution"). If you don't have time to do that (which is possible)... yes, we may not hire you - but, please propose a better alternative if you have one, for I have not found it. I'd actually be very grateful if you can help me find a way to improve this process.

There is a whole class of people you will miss - those who can solve problems, but can't vocalize effectively while solving them.

And its frustrating to be one of those people in interviews like that.

And there are plenty of solutions to evaluating a candidate. One, let them take 5-10 minutes of silence to solve if they need it, and discuss AFTER that. You say you want to see a "thinking process" or the candidate evaluating & throwing out ideas, but all of that is possible after a 5-10 minute silence period too.

Its frustrating because I suspect either that you are really just uncomfortable with silence, or have a certain idea of how people SHOULD approach the problem, and your interview process penalizes everyone who doesn't approach it that way. Its a recipe to selecting a certain type of person only and wasting everyone else's time.

> There is a whole class of people you will miss

I'm acutely aware that there's a degree of arbitrariness in hiring. That's why I was quite honest in saying that I'd appreciate suggestions for better process.

> One, let them take 5-10 minutes of silence to solve if they need it, and discuss AFTER that.

I do that; as you mentioned, people are diverse - some are bothered/ inhibited by silence. If they are silent, I say something like "I can leave you think about it for a few minutes in silence, but it's best if you can just talk to us about how you'd approach the problem, even about the approaches that you know are not good enough; and you can ask clarifying questions if you need to".

Thing is... if you kept silent for more than 30s without writing anything on paper, and I felt the need to intervene, it's either a problem that I consider "easy" and you should've figured out already - or it's one that is probably "hard" and you stand little chance of figuring out by yourself during the interview/under pressure (I've had a few people ask for silence, but can't remember a single one of them that found a good solution in due time). At that point, the only solution is to fall back to the "homework", because while you may be a good programmer, you're not giving me the information to assess that during the whiteboard/in-person interview.

[edit] I should also note that this is valid for algorithmic questions; and not all jobs require that sort of questions to be asked - for some, I might ask some basic stuff to figure out that you know the basic algorithms, but I won't go into hard stuff if I'm asked to hire a junior frontend dev.