[brainwipe]

I was asked by an SME to code on a whiteboard for an interview (in 2005? I think?). I asked if I could have a computer, they said no. I asked if I would be using a whiteboard during my day-to-day. They said no. I asked why they used whiteboards, they said they were mimicking Google's best practice. That discussion went on for a good few minutes and by the end of it I was teetering on leaving because the fit wasn't good.

I agreed to do it as long as they understood that I felt it was a terrible way of assessing someone's ability to code. I was allowed to use any programming language because they knew them all (allegedly).

The solution was a pretty obvious bit-shift. So I wrote memory registers up on the board and did it in Motorola 68000 Assembler (because I had been doing a lot of it around that time), halfway through they stopped me and I said I'd be happy to do it again if they gave me a computer.

The offered me the job. I went elsewhere.

[piyuv]

You should’ve asked them “do you also mimic google’s compensation?”

[wiejriljw]

I work for a faang subsidiary. We pay well below average salary and equity. We finally got one nice perk, a very good 401k match. A few months later it was announced that the 401k match would be scaled back "to come in line with what our parent company offers". I thought about asking "will be getting salaries or equity in line with what our parent company offers?" but that would have been useless. Management doesn't care. I'm job hunting.

[CYR1X]

Oh man I needed that in the clip for like a dozen interviews a decade ago.

[janoc]

This zinger I have to remember for the next time someone tries this whiteboard BS on me!

[blitzar]

"How many google shares do I get?"

[Rhapso]

Yeah, very bad fit. Surprised they made an offer.

Folks getting mad about whiteboard interviews is a meme at this point. It misses the point. We CANT test you effectively on your programming skillbase. So we test on a more relevant job skill, like can you have a real conversation (with a whiteboard to help) about how to solve the problem.

It isn't that your interviewer knew all the languages, but that the language didn't matter.

I didn't get this until I was giving interviews. The instructions on how to give them are pretty clear. The goal isn't to "solve the puzzle" but instead to demonstrate you can reason about it effectively, communicate your knowledge and communicate as part of problem solving.

I know many interviewers also didn't get it, and it became just "do you know the trick to my puzzle". That pattern of failure is a good reason to deprecate white board interviews, not "I don't write on a whiteboard when i program in real life".

[timr]

> We CANT test you effectively on your programming skillbase. So we test on a more relevant job skill, like can you have a real conversation (with a whiteboard to help) about how to solve the problem.

Except, that's not what happens. In basically every coding interview in my life, it's been a gauntlet: code this leetcode medium/hard problem while singing and tapdancing backwards. Screw up in any way -- or worse (and also commonly) miss the obscure trick that brings the solution to the next level of algorithmic complexity -- and your interview day is over. And it's only gotten worse over time, in that nowadays, interviewers start with the leetcode medium as the "warmup exercise". That's nuts.

It's not a one off. The people doing these interviews either don't know what they're supposed to be looking for, or they're at a big tech company and their mandate is to be a severe winnowing function.

> It isn't that your interviewer knew all the languages, but that the language didn't matter.

I've done enough programming interviews to know that using even a marginally exotic language (like, say, Ruby) will drastically reduce your success rate. You either use a language that your interviewer knows well, or you're adding a level of friction that will hurt you. Interviewers love to say that language doesn't matter, but in practice, if they can't know that you're not making up the syntax, then it dials up the skepticism level.

[jerf]

They generally do not know what they are looking for. They are generally untrained, and if they are trained, the training is probably all about using leetcode-type problems to give out interviews that are sufficiently similar that you can run stats on the results and call them "objective", which is exactly the thing we are all quite correctly complaining about. Which is perhaps anti-training.

The problem is that the business side wants to reduce it to an objective checklist, but you can't do that because of Goodhart's Law [1]. AI is throwing this problem into focus because it is basically capable of passing any objective checklist, with just a bit of human driving [2]. Interviews can not consist of "I'm going to ask a question and if you give me the objectively correct answer you get a point and if you do not give the objectively correct answer you do not". The risk of hiring someone who could give the objectively correct answers but couldn't program their way out of a wet paper bag, let alone do requirements elicitation in collaboration with other humans or architecture or risk analysis or any of the many other things that a real engineering job consists of, was already pretty high before AI.

But if interviewing is not a matter of saying the objectively correct things, a lot of people at all levels are just incapable of handling it after that. The Western philosophical mindset doesn't handle this sort of thing very well.

[1]: https://en.wikipedia.org/wiki/Goodhart%27s_law

[2]: Note this is not necessarily bad because "AI bad!", but, if all the human on the other end can offer me is that they can drive the AI, I don't need them. I can do it myself and/or hire any number of other such people. You need to bring something to the job other than the ability to drive an AI and you need to demonstrate whatever that is in the interview process. I can type what you tell me into a computer and then fail to comprehend the answer it gives is not a value-add.

[bossyTeacher]

> The Western philosophical mindset doesn't handle this sort of thing very well.

Mind elaborating on that?

[jerf]

It is a gross oversimplification but you can look at the Western mindset as being a reductionistic, "things are composed of their parts" sort of view, and the Eastern mindset as a holistic mindset where breaking things into their components also destroys the thing in the process.

The reality isn't so much "in between" as "both". There is a reason the West developed a lot of tech and the East, despite thousands of years of opportunity, didn't so much. But there is also a limit to the reductionistic viewpoint.

In this case, being told that the only way to hire a truly good developer is to make a holistic evaluation of a candidate, that you can not "reduce" it to a checklist because the very act of reducing it to a checklist invalidates the process, is something that a lot of Western sorts of people just can't process. How can something be effectively impossible to break into parts?

On the other hand, it is arguably a Western viewpoint that leads to the idea of Goodhart's law in the first place; the Eastern viewpoint tends to just say "things can't be reduced" and stop the investigation there.

This is highly stereotypical, of course, and should be considered as an extremely broad classification of types of philosophy, and not really associated directly with any individual humans who may happen to be physically located in the east or west. Further as I said I think the "correct" answer is neither one, nor the other, nor anything in between, but both, so I am not casting any shade on any country or culture per se. It is a useful, if broad, framework to understand things at a very, very high level.

[bargainbin]

When I joined my current team I found they had changed the technical test after I had interviewed but before I joined. A couple of friends also applied and got rejected because of this new test.

When I finally got in the door and joined the hiring effort I was appalled to find they’d implemented a leetcode-esque series of challenges with criteria such as “if the candidate doesn’t immediately identify and then use a stack then fail interview”. There were 7 more like this with increasingly harsh criteria.

I would not have passed.

[gedy]

> So we test on a more relevant job skill, like can you have a real conversation (with a whiteboard to help) about how to solve the problem.

Everybody says that, but reality is they don't imho. If you don't pass the pet question quiz "they don't know how to program" or are a "faker", etc.

I've seen this over and over and if you want to test a real conversation you can ask about their experience. (I realize the challenge with that is young interviewers aren't able to do that very well with more experienced people.)

[nottorp]

> can you have a real conversation (with a whiteboard to help) about how to solve the problem

And do you frame the problem like that when giving interviews? Or the candidates are led to believe working code is expected?

[Rhapso]

Do I? yes. I also teach my students that the goal of an interview is to convince the interviewer you are a good candidate, not to answer the questions correctly. Sometimes they correlate. Give the customer what they need not what they asked for.

Do I see others doing so? sadly no.

I feel like a lot of the replies to my comment didn't read to the end, I agree the implementation is bad. The whiteboard just isn't actually the problem. The interviewers are.

Unless they change mentality to "did this candidate show me the skills i am looking for" instead of "did they solve puzzle" the method doesn't matter.

[Apocryphon]

The replies are addressing the reality of the interview landscape that fails to live up to your theory of how whiteboarding interviews should be.

It's all well and good that you and other "wise interviewer" commenters on HN actually grok what the point of interviews are, but you are unicorns in the landscape.

[Rhapso]

I don't think you made it to the last paragraph either:

> I know many interviewers also didn't get it, and it became just "do you know the trick to my puzzle". That pattern of failure is a good reason to deprecate white board interviews, not "I don't write on a whiteboard when i program in real life".

[Apocryphon]

Nope, it was directed at your last paragraph.

[absolutelastone]

> The goal isn't to "solve the puzzle" but instead to demonstrate you can reason about it effectively, communicate your knowledge and communicate as part of problem solving.

...while being closely monitored in a high-stakes performance in front of an audience of strangers judging them critically.

[pockmarked19]

That’s a skill you do need at Google if you’re going to survive. At least nowadays.

[janoc]

Except that 99% of engineers aren't being hired by Google nor being paid on comparable levels.

So why is Google relevant to this in any way?

[pockmarked19]

> Except that 99% of engineers aren't being hired by Google nor being paid on comparable levels.

Sucks for you, then. Why are you on a thread about Google-style interviews?

[Dylan16807]

> Why are you on a thread about Google-style interviews?

For the same reason you wrote "Google-style". Because this thread is specifically about those interviews happening not at Google.

Oh, maybe you misunderstood their question. When they suggested Google wasn't relevant, they meant the company culture at Google itself because that's what you were talking about.

[absolutelastone]

Perhaps. I'd even say it's part of what is taught as part of a PhD.

But if someone was ready for your exact question by having the right interview practice/experience, or they just don't care about your job so there's no stakes. Then you still aren't measuring what you think you are.

[placardloop]

+1 to all this. It still surprises me how many people, even after being in the industry for years, think the goal of any interview is to “write the best code” or “get the right answer”.

What I want to know from an interview is if you can be presented an abstract problem and collaboratively work with others on it. After that, getting the “right” answer to my contrived interview question is barely even icing on the cake.

If you complain about having to have a discussion about how to solve the problem, I no longer care about actually solving the problem, because you’ve already failed the test.

[SJC_Hacker]

I think you're severely underestimating how much just about every software company has bought into the FAANG philosophy, and how many candidates they get who can answer those questions correctly.

Yes if you don't communicate clearly, you will get points deducted. But if you can't answer the question nearly perfectly, its basically an immediate fail.

[fdlaks]

Unfortunately I used to think this was the main purpose of the interview as well, but have been proven wrong time and time again.

The only thing that matters in most places is getting to the optimal solution quickly. It doesn't matter if you explain your thought process or ask clarifying questions, just get to the solution and answer the time and space complexity correctly and you pass.

Like others have said I think this is a symptom of the sheer number of people applying and needing to go through the process, there is no time for nuance or evaluating people on if you would actually like to work with them or not.

[whiplash451]

> I was asked by an SME to code on a whiteboard for an interview (in 2005? I think?). I asked if I could have a computer, they said no. I asked if I would be using a whiteboard during my day-to-day. They said no. I asked why they used whiteboards, they said they were mimicking Google's best practice.

This looks more like a culture fit test than a coding test.

[bossyTeacher]

> The offered me the job. I went elsewhere.

I am so happy that you did this. We vote with our feet and sadly, too many tech folks are unwilling to use their power or have golden handcuff tunnel vision.

[Clubber]

>I was allowed to use any programming language because they knew them all (allegedly).

After 30 years of doing this, I find that typically the people who claim to know a lot often know very little. They're insecure in their ability so much that they've tricked themselves into not learning anything.

[Exoristos]

Are there people who still aren't aware that FAANGs developed this kind of thing to bypass H1-B regulations?

[thecleaner]

Take a bow.

[user432678]

And my axe…

[tokai]

>I was allowed to use any programming language because they knew them all (allegedly). brainfuck time

[codr7]

Hehe, I have to remember to bring one of my custom Forths to the next interview.

[xmx98]

As an interviewer I’d just skip the questions and talk about your Forth haha

[codr7]

Even better :)

I have yet to come across an interviewer who has a clue about anything that interests me.

[Shorel]

2005? You were in the right.

Today? Now that's when it is tricky. How can we know you are not one of these prompt "engineers" copy paster? That's the issue being discussed.

20 years and many new technologies of difference.

[ToucanLoucan]

What is the functional difference between copying an AI answer and copying a StackOverflow answer, in terms of it being "cheating" during an interview?

I think the entire question is missing the forest for the trees. I have never asked a candidate to write code in any fashion during an interview. I talk to them. I ask them how they would solve problems, chase down bugs, or implement new features. I ask about concepts like OOP. I ask about what they've worked on previously, what they found interesting, what they found frustrating, etc.

Languages are largely teachable, it's just syntax and keywords. What I can't teach people is how to think like programmers need to: how to break down big, hard problems into smaller problems and implement solutions. If you know that, I can teach you fucking Swift, it isn't THAT complicated and there's about 5 million examples of "how do I $X" available all over the Internet.

[aleph_minus_one]

> Languages are largely teachable, it's just syntax and keywords.

This is like "learning a natural language is just 'cramming vocabulary and grammar' - voila, you've become a fluent C1 speaker". :-)

Seriously: if you argue this way, you have only seen a very biased set of programming languages, and additionally, your knowledge of these programming languages is very superficial (i.e. you have never gotten to the "interesting"/"deep" concepts that make this particular programming language special, and which are hard to replicate in most other programming languages).

[endemic]

I think the argument is that for a good chunk of business work, you don't need to use the "interesting"/"deep" concepts. Sure, you'll need time to adapt to the idioms of the language you're using, but following examples you can be just as productive as others in a relatively short time.

[Shorel]

> I think the argument is that for a good chunk of business work, you don't need to use the "interesting"/"deep" concepts.

That's what the MBA people want to believe. To lower costs, or if they see writing code as an operating expense, instead of R&D.

If this is true or not, it depends on many, many factors, and it can change over the course of the business life.

[aleph_minus_one]

> but following examples you can be just as productive as others in a relatively short time.

This is not something nice to say about the colleagues. :-)

[rmah]

But companies don't pay high salaries for the 80% mundane and easy tasks you do day to day. They pay for the 20% that is challenging and especially for that 1% of problems that occur only once every few months or years. If that 80% was 100% of the job then the company could pay 1/2 to 1/3rd the amount by outsourcing it.

[edmundsauto]

I disagree, companies pay based on the problems you can solve to make them money or help achieve organizational goals. One of those ways can be coding, but there are many others.

[dingnuts]

No, the comparison to natural languages is what is whack. If you understand the underlying concepts that programming languages pick and choose from as features, all you have to learn is what keywords map to those concepts and the language's syntax.

The comparison to natural languages would be if you could learn one language and then quickly pick up every other language of that "class" after learning how that single language works. That's not really how natural language works at all, but it does work with programming languages.

[aleph_minus_one]

> If you understand the underlying concepts that programming languages pick and choose from as features, all you have to learn is what keywords map to those concepts and the language's syntax.

If you understand the grammatical topics that a natural language picks, all you have to learn is what word transformation rules map to those concepts, and the natural language's vocabulary.

> The comparison to natural languages would be if you could learn one language and then quickly pick up every other language of that "class" after learning how that single language works.

There do exist books on this topic (though more commonly for language families). See for example

https://www.quadrilingual.com/

or the book

EuRom 5. Leggere e capire 5 lingue romanze

> That's not really how natural language works at all, but it does work with programming languages.

... it might give you some shallow knowledge in a very limited subset of programming languages.

[lcnPylGDnU4H9OF]

> If you understand the grammatical topics that a natural language picks, all you have to learn is what word transformation rules map to those concepts, and the natural language's vocabulary.

Yes, and then do that in real time while you're having a conversation with someone who's been learning the language since they were a baby. It is an unreasonable comparison.

[shermantanktop]

In C, implicit type narrowing/widening behavior stumped me as a noob working on noob problems. “Deep C Secrets” was a revelation when I finally found it.

Then again, that’s C.

[Shorel]

> Languages are largely teachable, it's just syntax and keywords.

That's only true for a subset of programming languages, and it requires you to already know how to program in at least another language of the same family. Knowing Java will not help you with Haskell, but it will help you with C#.

I have to deal with students using AI to cheat on homework and exams, and I can't allow them to not even learn the basic concepts.

They could convince you with buzzwords, get hired, and then feed all problems to the AI until it reaches a point where the codebase is too big for the context, and then all their prompt “engineering” experience is basically useless.

That is the future I am trying to prevent.

Until the AI can code a full system like SAP, or an Operating System, or a Photoshop clone, by itself, we need some people in the loop, and the more knowledgeable the people, the better.

[cbzbc]

> That's only true for a subset of programming languages

That's true, but most of the industry is running on a subset of programming languages.

[ToucanLoucan]

I'm not arguing to let people cheat with AI. I'm saying asking people to write code in interviews is useless.

[rmah]

It's not useless because some people will lie and cheat. Over the years, I've interviewed hundreds of people and a substantial minority could not write even the simplest code. Many will say they would be able to filter out such people after a conversation. But, IMO, the fact that they are still able to get hired at some places shows how wrong that often is.

[Shorel]

I am making the parallel because I feel exams and interviews share some similarities.

[shash]

> That's only true for a subset of programming languages, and it requires you to already know how to program in at least another language of the same family. Knowing Java will not help you with Haskell, but it will help you with C#.

In this context, to a large extent it holds. Yeah. It’s probably more true of mainstream languages roughly related to each other, but in an interview, you’re not testing for knowledge of syntax and keywords. You’re trying to test for ability to build and problem solve.

I share your concern about prompt “engineers” who don’t understand the underlying codebase, language or system. But I don’t know what to do about it in the context of a technical interview.