Unfortunately it doesn't work like that. At multiple interviews I was asked to do code challenges or solve FizzBuzz exercises. I replied something along the lines of "I built a commercial product all by myself. Here is the website so you can play with it. Here are some code samples.".

And the answer I got always left me speechless: "Well, I don't really know what code you used or if you actually wrote it. So we're just going to fizzbuzz you to make sure you're good. We do this with everybody".

This didn't happen just once. It was actually the vast majority. The no-whiteboard approach seems to work only with early-stage startups. Once a company starts settling, say hello to mindless bureaucracy.

It's not mindless to make sure a candidate can actually produce some code. You'd be surprised how often people are hopelessly fucking incompetent at actual coding.

I'm used to getting these alpha dog; VP-of-whatever from big investment banks (I work in finance), with a laundry list of stuff they have done. Sure ok, good for you, now write up a skeleton class for a linked list in any language of your choice... what's that, you're stuck? You can't remember the keywords for defining a new class in the language you've labeled yourself as an EXPERT in? really?

When you hire a lawyer, do you test him with imaginary laws? If not, why are you doing it with engineers?

Engineers solve problems. That's it. They use tools, they try things and they provide solutions. Asking an engineer to solve an imaginary problem on the spot is idiotic. You may have glided through school memorizing stuff and barfing them during exams. But engineers didn't. They understood how things work and why.

So when you ask an engineer to write a skeleton class for a linked list, his answer will always be "Why? What problem are you trying to solve?". They don't have it memorized. They build it as they go along, based on the specified requirements.

Unlike you, most engineers are friendly people. And not as aggressive. All they want to do is build something or help you do it. You on the other hand seem to have some envy problems. The "AHA! Not so smart now, mr VP of whatever..." attitude is exactly what's wrong with the tech industry.

Leave it to a bureaucrat to fuck things up.

1. I am an engineer (of the electrical variety)

2. I don't believe in memorizing stuff, I believe in understanding stuff... which is why I'm an engineer.

You say: "his answer will always be "Why? What problem are you trying to solve?"

Indeed, I WANT people to ask this question. Then I'd like them to suggest why a linked list is or isn't a good candidate for that problem. I will ask them to suggest an alternative method of solving my problem. A good interview is a conversation, but if the candidate has literally no questions to ask, and nothing to provide, and can't even solve the most basic problems that could be memorized, then why would I want him? If a candidate can't come up with a half-decent approach to a problem as simple as FizzBuzz or making a simple data structure container like a linked list; a problem which dwarfs in comparison with what I do on a daily basis at my job, he has no business sitting next to me.

You also say: "Asking an engineer to solve an imaginary problem on the spot is idiotic. "

Well, that just happens to be my job! My boss comes down, asks me "could you solve this problem for me?" and my answer is "I don't know, but I'll try!" and off you go. so my entire job is about solving unknown problems. Isn't yours? I'm not setting up WordPress sites or chaining together SAP modules (not that there's anything wrong with that, I used to do something like that for several years...), we actually solve problems that don't have known solutions, and the amount of data we work with also poses some unique problems. So our interview process is a miniature, and yes, imaginary, version of what you might be tasked with on any given day.

Finally, to clarify, this it the stance I take with people who claim to be "experienced experts". If I'm interviewing an intern or a junior developer, my approach will obviously be very different.

But you're not giving your candidates problems, are you? You're giving them specific scenarios with strict algorithmic constraints. In any engineering job the boss asks us to build a system or a tool. He never says solve this very specific task using these very specific rules. You have a lot of freedom when it comes to the actual implementation.

Why aren't you replicating this in your interviews? Why do you insist on code tests? Why aren't you insisting on the result? That's what your boss wants. I'm pretty sure he doesn't care about your ability to solve stupid trivia and academic tests.

This is why I'm saying you're a bureaucrat. You read somewhere about fizzbuzz and code tests and you stopped there. Didn't think for yourself. Just gobbled up what some other guys decided was good.

Want great conversations and to be amazed by experts? Give them real life problems to solve. You will look incompetent too if I start interviewing you with stupid "How do you do X?" questions.

You've already made up your mind about who and what I am based on 3 paragraphs of text (which I wrote in a somewhat sarcastic and aggressive tone, I know, to make it a bit more funny to read, and to invoke some response).

But I'm going to level with you: if my expert can't handle a simple problem with training wheels, like FizzBuzz, it is a very strong indicator that attempting to give him a bigger problem to solve (but not code) is a waste of time.

Your expert baker example is spot on. I know a chef who asks new cooks to cook a scrambled egg. If they can't do that right (and many can't), it points to real problems with their basics. If they feel cooking a scrambled egg is somehow below them, that's not good either.

> When you hire a lawyer, do you test him with imaginary laws?

To be a practicing lawyer, you are already tested extensively on hypothetical -- imaginary -- legal problems. If programmers had similar professional requirements, then general competency testing as part of an interview process would probably be less popular because that would be essentially outsourced to the credentialing association.

Does having more than two jobs in the past count as extensive testing? If two other companies like yours decided I'm skilled and paid me for it, why do you assume I'm not? Who must perform these tests to determine competency?

Did you get laid off at your last job? How did you perform? I can ask you, will you give me an unbiased answer? I can call you reference, that person you hand-picked to be the least likely person to give you a bad review. Is that guaranteed to be an unbiased answer? No.

The only unbiased answer is you, showing me, right here, right now what you can and cannot do.

Are you talking about memorizing what a linked list is, or someone else's code? I don't understand what is imaginary about such a ubiquitous construct.

I think the GP considered it an "imaginary problem" in that if you really needed a linked list for something, you would probably just make use of an existing library rather than write it yourself.

I understand that avoiding whiteboard interviews isn't always possible. I'd just suggest OP (and anyone else) try and see if they can.

All the interviews I have had with major tech companies involved white board exercises except for one. The one that didn't involve a white board focused on discussing prior accomplishments in context of the job to see if there is alignment.

I think white boards are great if you use the information you gather from them in the proper way. Engineers solve problems, teams create global companies and change the world. I look at white board sessions to see how you can approach a problem, are you big picture or in the weed detail oriented. When I ask the question what do you focus on? Whether you solve the entire problem or not is not the deciding factor in my opinion.

Also, I think with the volume or applicants companies are looking for ways for people to prove they as contributed to their resume achievements and were not a back seat passenger the rest of the team carried along.