Anyone else thinks that Whiteboard interview is just covered ageism? | Hacker News Reader

Anyone else thinks that Whiteboard interview is just covered ageism?

95 pointszerogvt140 comments

It's the second time in a few months I'm being turned down with the pretext of a failed whiteboard interview. Things like improper syntax and not getting the damned recursive solution fast enough. Given that I am 42 yrs old and been at this line of work for 14 yrs now I think it's safe to assume that I neither have the time nor the appetite to constantly exercise on solving mind puzzles in whiteboard. I am good at what I do -and I do it at a top level company- but it has nothing to do with coding on a whiteboard. I'm sure that anyone who is a few years _out_ of the university and _into_ a real job finds it both hard and surreal to go through these hoops to land a job. Whiteboarding simply tests for skills that are not needed nor exercised once you're out of uni.
Thinking all that it then dawned on me. Maybe this abomination is just a way to take out older candidates and favor young ones. A form of ageism that is legally safe for the company.
Dunno - what's your thoughts?

By whiteboarding here I mean testing the form of questions one can find in places like hackerank and the like. Obviously, drawing a large system design or using a whiteboard as an aid to describe/analyze other aspects of a system is not the topic I'm touching on here.

PS 1: I'm done with that sh1tshow myself. I sincerely hope I'm never that desperate to put myself through that again.

PS 2: For what is worth here's a repo with all companies that do not use whiteboarding: https://github.com/poteto/hiring-without-whiteboards

View on HN

I'm even older than you and have no problem with using a whiteboard during interviews. That said, interviewers who get hung up about precise syntax are poor interviewers and need coaching. Or are just looking for an excuse to ding someone. More to the point, I don't see how asking to put answers to technical questions on a whiteboard favors younger people over older people.

A lot of programming involves design and structure. Whiteboard interviews are biased towards algorithms involving problems that are typically trivial solved with library functions like sort.

A whiteboard interviewer typically finds some type of "library" problem, gives it a little twist and throws it at a senior programmer who's been doing design and structure for years. The candidate out of school, meanwhile, recently took an algorithms course.

So for the older candidate to keep up with the younger one the older one actually has to go and study stuff UNRELATED to work.

I find it strange that you can be older than the Parent poster but not realize this fact.

Depends a lot on the places you're interviewing at. The places that are bad at interviewing have the exact problems you're describing. Better places test for more real-world skills. The best places tailor the questions to the expected seniority of the candidate.

If the GP has had some amount of luck and/or skill with picking the places they interview at, they might not have experienced this too much.

I think when he says 'white board interview', he means 'algorithms and data structures screen, which may or may not be on a whiteboard'.

So, for instance, you could give a data science applicant a dataset and pandas and tell them to make you a report 'about sales projections' then see what they come back with.

Or you could ask them to sort a list of strings in log(n) time and n space using a recursive solution.

The first test would probably benifit an experieced applicant because hopefully they will have a better understanding of what buisness actually needs. The second test would benifit a recent graduate, because they will have done algorithms 101 more recently and remember a canned solution.

Of course, experienced applicants will revise this sort of problem and play on hacker rank for a couple months before a job hunt, so it will also benifit candidates who are actively job hunting, rather than applying for a specific oppertunity

Same here, but that's only because I practiced. WB coding is a skill like any other, barring a physical issue which prevents you from writing on the WB.

I do sympathize though. The older I get, the slower I tend to think and the more silly mistakes I make. WBC is not a good way to show off my skills. Frankly I think WBC in general is biased towards the type of rote learners who grind through leetcode problems and know how to regurgitate canned answers, but that is dependent on your interviewer.

It is strongly advised that if you get a question you've already practiced then you should tell your interviewers. At least that's the supposed code of conduct. So, what you're suggesting is that the code of conduct is just words and this is all just a set of moves that we have to go through.

What code of conduct? Who advises that? Expecting that to be followed seems like it would just disadvantage honest hard studiers and honest people who actually do figure out the solution on the spot, while rewarding dishonest talented performers who also happen to be hard studiers—so unless that's what you're trying to select for....

It's in the bible for the WB religion http://www.crackingthecodinginterview.com/

See - I've even gone through that. I'm that diligent.

Hahaha, touché. I either missed or forgot that bit. Guess I fail the test :-)

I think "WB coding is a skill like any other" is exactly the point. It's a skill that does not really apply to the day-to-day work of most programmers though, so using WB coding as a criterion favors those who have the time to hone it, or are recent grads (the exams in many CS courses get quite close to white board programming). It's unclear that it's a direct proxy for age, but it's easy to see that many more senior programmers would have neither the time no recent academic experience to have that particular skill well-practiced.

I was going to say something similar. If whiteboard coding is a skill distinct from any you'd use after hiring, how useful is it as a filter? To a certain extent it's a sucker filter, selecting for people who are willing to invest time in learning a skill they know is just for show. Older workers tend to resist such things, because they've seen where it leads in other more important circumstances. That itself is valuable knowledge, and whiteboard interviewing selects against it.

I agree. What would age have to do with recalling syntactic idiosyncrasies, or being able to theorize about problems with a dry-erase marker and a whiteboard (or a pen and pencil, or a keyboard and a computer)?

Reading between the lines, you seem upset about having to answer questions about technical problems you perceive to be irrelevant, and that these technical problems are more likely to be solved successfully by those who have recently practiced them (e.g. graduates).

I too agree that, while abstract technical interview questions have little bearing on most day-to-day work, they do some things quite well:

1 - Define a well-bounded problem of sufficient difficulty 2 - Give the interviewee a good baseline for objective success 3 - Exercise a person's mind to think about complicated problems

While they are contrived and not entirely representative of daily work, they are not without value.

There is some value to it, yes. But what I've experienced so far is that whiteboard > individual project + culture + experience + whatever else. Thus my hunch that they are not there to show something more on top of other things but rather be the most decisive factor of all.

> individual project + culture + experience + whatever else

That gives you the interview and determines what level you get if you get hired, so it still matters more than the white-board. White-boarding is still necessary to check that you are top x% in terms or some mishmash of skill and intelligence. Having tech leads who are less talented than our juniors would be bad, so testing that they are better in every way is important.

I think most of the dislike comes from the tendency of typical whiteboard questions to favor someone who happens to have seen a very similar problem recently, the same way someone who comes up with the correct answer to a brain teaser very quickly is usually someone who's seen it before. Many rely on that, in fact, since otherwise they'd be asking people to come up with a publishable (once published, perhaps) finding, under pressure, on the spot, in maybe an hour.

This might be fine if the "very similar problem" is something you'd likely have encountered in your work, but often they questions are drawn from a pool that most people in this line of work see rarely if at all, and if they do it's likely to be some very small subset of the questions, so dedicated study of the remainder of the pool still puts one at a large advantage, regardless how useful it is in doing your actual work.

They're measures of "how bad you want it" (how much of your time you spent memorizing stuff you don't actually use to prep for the interviews) and/or how recently you took an algorithms course. And maybe those are things worth measuring, I dunno. Maybe the absence of strong enough signals on either of those is important enough that it makes sense to use them to reject people who are otherwise very capable of doing the actual work.

> Many rely on that, in fact, since otherwise they'd be asking people to come up with a publishable (once published, perhaps) finding, under pressure, on the spot, in maybe an hour.

In much of science the hard part is asking the right question rather than coming up with the solution, so figuring out these algorithms is not equivalent to making publishable research.

Fair criticisms. I tend to prefer asking/being asked system design questions, which in nature allow for a wide range of experiences to excel at.

What they aren't the best at, although more realistic, is coming up with an objective measurement of quality. Algorithms , at the cost of realism, do measure things quite nicely.

Added a note (*) that answers your question.

"It's the second time in a few months I'm being turned down with the pretext of a failed whiteboard interview. Things like improper syntax and not getting the damned recursive solution fast enough."

Is it a pretext, or did you actually fail the interview? I want to work for West-coast-pay company at some point, and it seems that the idea there is for me to spend 6 months learning stuff I will never use, so I can compete with the kids who spent 4 years learning mostly stuff they will never use.

That is, if I fail it, it's not because I am older, it's because I don't know stuff fresh grads know.

IT is full of grinding pretty meaningless stuff (especially at lower levels), as much as we romanticize it.

>That is, if I fail it, it's not because I am older, it's because I don't know stuff fresh grads know.

I believe this is exactly the point that the parent poster is making. You don't know the stuff fresh grads know because you're older (obviously this isn't an absolute, but likely). Therefor, structuring the interview around stuff that only fresh graduates are likely to be up-to-date with would be discriminating against older people.

If you fail, it is at least related to you being older, if the focus of the interview was designed around hiring fresh graduates.

> Therefor, structuring the interview around stuff that only fresh graduates are likely to be up-to-date with would be discriminating against older people.

It's only discrimination insofar as the skills being tested for are irrelevant to the job at hand. I've had jobs where algo skills were borderline irrelevant, and jobs where they were crucially important.

Also, even where it is discriminatory, it's not necessarily deliberately so. It can easily be just poor interviewing skills — an interview process designed by people who genuinely think these are skills that they need to test for, without understanding the problems that creates.

Well... yeah. If the skills are relevant to the job, this conversation wouldn't be happening. It's when the combination of the problem being both irrelevant to the job, and designed in a way to favor the fresh generalists out of school that we (potentially) see discrimination against age.

And deliberate or not, discrimination is discrimination. It might be more palatable if it isn't deliberate, but it doesn't change anything for the interviewee - and is still a problem that should probably be addressed.

I get the point, but you could also argue that big companies want people who are strong on fundamentals and consider them something you shouldn't forget.

As in, the army won't hire a 40 year old for SOF if they can't run just as fast as the 18 year old can, even though they PREFER >30 candidates for, say Green Berets, but ANY candidate is useless if they can't meet basic fitness standards.

Same idea here, to some degree.

Can you write cleaner code and foresee problems as you get older. For sure.

Do a lot of older people get complacent, forget everything, or never knew anything? For sure, and I think they are testing for that.

Ageism is real and scary, but you also have to be proactive in defending yourself against it.

I have seen young devs try to devour an older dev, but they stay away when said older dev schools them.

College dropout here. Young people sometimes don't know this stuff either.

This is probably less ageist than it is education-ist, which is not too far away from classist.

Personally, I do think it's worth testing candidates on these pure CS skills, even though I myself didn't have them and had to study before I interviewed at Google. What I've found since then is:

1. Surprise, surprise, I actually have used quite a few of these concepts in my work. My experience may not be typical, but my role really does benefit from my having a better grounding in algorithms than I did before.

2. When communicating with other people at the company, it is very helpful to be able to presume a baseline understanding of algorithms, data structures, and big-O. A lot of code reviews and design discussions are easier and faster when you can just say "yeah, but that's O(n^2)" or "BFS would let you early out more frequently here".

As an interview technique, I also think there is some value in testing an arbitrary skill a candidate might not have, because it's a good gauge of hustle and discipline. Yeah, learning algorithms is a chore and a hassle. But... a lot of shit you have to do at work is a chore and a hassle.

If the interviewer can see that you're able to make yourself do that for the interview, it's a good sign you'll have the discipline to do some of the grunge work that is inescapable in the software field.

I agree with your first points, but...

> Yeah, learning algorithms is a chore and a hassle

> If the interviewer can see that you're able to make yourself do that for the interview, it's a good sign you'll have the discipline to do some of the grunge work...

This doesn't make any sense, unless very, very specific bounds are put on the interview questions beforehand...

Without that, what is a candidate to do? Memorize all known data structures and algorithms?

> Memorize all known data structures and algorithms?

No, but you should know the classics. That's kind of the "general contract" for how these big tech companies interview. Most also proactively tell candidates what material they should expect to be interviewed on, like:

https://careers.google.com/how-we-hire/interview/#onsite-int...

A good interviewer is not aiming to ask gotcha questions where if you don't know that one specific weird algorithm for that one specific data structure, you're entirely hosed. That provides almost no useful signal to the interviewer.

But they will ask questions where some well known data structure is part of the solution and then provide guidance as needed based on what you seem to know.

Of course some young people don't know the things either. If it is discriminatory against older people, that doesn't mean younger people get a free pass.

I agree with a lot of what you have said - but the issues at hand here (at least, my interpretation) is not absolute fundamentals which are obviously important.

The issue (again, my interpretation) is taking something that is taught in school, somewhat rarely applied in practice (or, is replaced by a tool/library/whatever in practice) and putting some sort of spin on it then expecting someone to be able to answer it. Or taking a problem which already has an industry-accepted solution and asking the candidate to remake the wheel in 30 minutes.

If your fresh out of school you're more likely to remember that one obscure class you took few months ago which covered some trick situation. Or you'll remember that class which taught you about that industry-accepted solution and the why behind it.

If you've been in the field for 15 years using some tool/library to solve the problem, you're less likely to remember that one obscure class you took 15 years ago which explained the origin. Or that class which covered the trick situations.

For what its worth, I don't think this is a widespread problem and very likely not deliberate when it does happen. But, I think it happens often enough that we should at least be talking about it.

Isn’t a better question, why are you interviewing for the same positions in your 40s that a fresh grad could do? I’m 45 and still mostly work at jobs where I’m officially a “senior software engineer”, occasional “team lead” or “architect”. But, I am not trying to compete with fresh grads.

In your 40s, you should have a trusted network of former managers, coworkers, and external recruiters that help you bypass a lot of the BS.

>Isn’t a better question, why are you interviewing for the same positions in your 40s that a fresh grad could do?

Do you generally look down on everyone who needs a job, or just the ones who need a job and are old?

If you can't find work as a senior, and your options are junior or not working, which would you choose?

>In your 40s, you should have a trusted network of former managers, coworkers, and external recruiters that help you bypass a lot of the BS.

Shame on those not as lucky, extroverted, or with the same opportunities as you, eh?

Do you generally look down on everyone who needs a job, or just the ones who need a job and are old?

I’m 45. I stayed at one company way too long until I was 35 and didn’t get aggressive about my career until 10 years ago.

If you can't find work as a senior, and your options are junior or not working, which would you choose?

In 2019, in many major cities in the US - including Atlanta where I live - an experienced developer looking for a job is such a rare breed that you have to fight off recruiters. In the last 10 years it’s never taken me more than a month to find a job at whatever level I was at at the time (I was an “expert beginner” in 2009). I’m not a special snowflake, I’m just a bog standard “Enterprise Developer”

Shame on those not as lucky, extroverted, or with the same opportunities as you, eh?

I graduated from a no name college in a small town in 1996. What “great opportunities”?

The last thing anyone has ever called me is “extroverted”, I did what I had to do because I didn’t want to be at the age I’m at now without having the optionality of changing jobs.

Ah, so anyone with a certain amount of experience applying for junior-like positions is just being dumb. I get it. You should let the OP know that they should be fighting off recruiters instead of applying for jobs you feel are too lowly for their experience.

I’m not saying it’s right or wrong. But the reality of the job market is that if you’re 40+ and not willing to spend months doing leetCode and don’t do what I’m suggesting, you are going to end up in a situation where you can’t find a job.

Anyone applying for a junior position should expect to have skills matching or exceeding the other people applying for the same position. Saying candidates should get a free pass because of age sounds far more discriminatory than an even playing field.

If you've been in the industry for years, have a stalled career, and are looking down the ladder for a job is there a sinister bias against age, or are you just not qualified?

I didn’t say free pass. I didn’t say they shouldn’t have the skills needed to do the job. This is about CS trivia interviews, non-applicable to the job. In these cases, fresh graduates have an advantage.

I also never said that it is a "sinister bias". Are some of them not qualified? Obviously. But there are people who, believe it or not, are experienced and qualified but have other circumstances which force them to step down a rung on the corporate ladder.

As I have stated elsewhere, I don’t think this is a widespread problem. I certainly don’t think anyone should get a free pass.

From my other comment:

>The issue (again, my interpretation) is taking something that is taught in school, somewhat rarely applied in practice (or, is replaced by a tool/library/whatever in practice) and putting some sort of spin on it then expecting someone to be able to answer it. Or taking a problem which already has an industry-accepted solution and asking the candidate to remake the wheel in 30 minutes.

I didn’t say free pass. I didn’t say they shouldn’t have the skills needed to do the job. This is about CS trivia interviews, non-applicable to the job. In these cases, fresh graduates have an advantage.

And they are at a great disadvantage if they get a whiteboard architecture interview. If you want to apply for a job as a junior developer in an environment where they care about leetCode skills, you have to be willing to put in the effort. I am not willing to do so. Therefore I’ve optimized my skillset, my network and where I’ve chosen to live so I don’t have to.

There are all loads of websites and books that can get you back up to speed with that if you need it.

You haven't answered the OP's question. Just because such interviews are avoidable, at some expense that I'll get to later, is orthogonal to whether they perpetuate age discrimination.

Yes, everyone "should" have a trusted network like you say, but that only works if you're a bit flexible about what you work on or where. If you have more specific goals regarding projects, locations, markets, scale, or salary, you might find only two or three places hiring and they might all have blanket whiteboard-interview policies even for senior or specialized hires. That's how I found myself in front of a whiteboard at 52. It worked out for me, but what if it hadn't? I could have compromised on some of my goals and used my network to get a job elsewhere. I've been there and done that too, but I wouldn't have welcomed the compromise. I also no longer wish to participate in a system of side-door hires that perpetuates discrimination.

It's easy to say what others "should" do, but they're not you. They might have different values and priorities that leave them with less flexibility regarding whether to do such interviews.

You haven't answered the OP's question. Just because such interviews are avoidable, at some expense that I'll get to later, is orthogonal to whether they perpetuate age discrimination.

It’s not age discrimination. There is nothing stopping anyone at any age from studying “Cracking the Code”, going on the various leetCode sites and practicing.

If you have more specific goals regarding projects, locations, markets, scale, or salary, you might find only two or three places hiring and they might all have blanket whiteboard-interview policies even for senior or specialized hires.

In that case, you do what it takes. I said below that because of $bad_decisions, I found myself at 35 only qualified for mid level roles. 8 years later after following my own advice - job hopping, networking, Resume Driven Development, etc., I found myself reaching close to the maximum salary I could reasonable get as a developer/team lead/architect in my local market.

I don’t have to learn LeetCode to qualify for the next level, but I have spent the last two years immersing myself into all things AWS and cloud development/dev ops and project management so I could qualify to be an overpriced consultant.

If I wanted to move to the west coast and work for a FAANG, I would have spent the last year or two preparing for that instead.

I could have compromised on some of my goals and used my network to get a job elsewhere. I've been there and done that too, but I wouldn't have welcomed the compromise.

And the poster can make the decision. If he wants to play that game, he has to train for it. Don’t say you want to run a marathon and not be willing to put in the training and then complain about it.

I also no longer wish to participate in a system of side-door hires that perpetuates discrimination.

I’m a 45 year old Black guy from a small town in the south. Trust me,I’m not part of any “old boys club” by nature of any innate “privilege”.

It's easy to say what others "should" do, but they're not you. They might have different values and priorities that leave them with less flexibility regarding whether to do such interviews

If their priority is to work for companies that require hard whiteboard interviews so they can earn $300K+ instead of being a bog standard Yet another software as a service full stack CRUD senior engineer where they can earn $130K - $160K in many major US cities, don’t complain that they have to put in the work. I’ve had to put in the work to be qualified for the next level after my youngest graduates. I don’t want the travel requirements right now.

> don’t complain that they have to put in the work

This isn't about whether people are willing to do the work. It's about whether they have to do the same amount of work and whether their performance is measured the same way. If not, that's discrimination. People who want to run a marathon should have to do the work, but they shouldn't have to wear weights on their ankles while others don't.

As I said, it didn't stop me personally. But I know others who also did the work and got the short end of that effort/reward disparity. That doesn't mean they were wrong for trying. Your choices might be right for you or they might be mere "sour grapes" rationalization. I don't know and I don't care, but they can't and shouldn't be projected onto others. Discrimination is discrimination even when it doesn't affect you.

Say I wanted to be a modern web developer and that I spent 10 years maintaining an old ASP.Net WebForms app. Would it be “discrimination” if I had to spend a year learning the modern $cool_kids stack to be competitive with younger developers who may have learned everything in a boot camp?

Was it “discrimination” that I had to spend six months to be competitive in 2008 after being at the same company for a decade writing VB6 apps and writing programs in C++ with MFC/DCOM?

What about the six months in 1999 I spent playing around with C++/MFC because I spent the first three years of my career writing C and FORTRAN on DEC VAX and Stratus VOS mainframes?

If you want to stay an active software developer you have to always be learning to stay competitive.

No, those don't sound like discrimination. Discrimination would be if you spent that year learning the material then went into the interview and they gave you a problem that was utterly irrelevant but more familiar to those bootcamp kids. Or if they gave you a relevant problem and you solved it fine using an obvious-seeming algorithm you learned ten years ago, then got "corrected" because everyone uses a different algorithm nowadays. Maybe even an algorithm that's objectively worse for that particular case, but arguing the point would only cost you more points. Those are things I've seen happen.

As I suspect you know, discrimination rarely declares itself. It's usually subtle, sometimes even unconscious, but often it's still there. "I didn't care so I didn't try so I have no direct experience" is not a good argument for dismissing others' choices as inferior or their experiences as insignificant.

Discrimination would be if you spent that year learning the material then went into the interview and they gave you a problem that was utterly irrelevant but more familiar to those bootcamp kids.

The modern $cool_kids framework would be more familiar to those boot camp kids than it would have been to that hypothetical guy who spent years doing WebForms. Every time I’ve interviewed since 2009 I’ve had to prepare myself beforehand for the types of interviews required for the type of job I wanted. I’m sure half the developers on this board have been targeted by one of the Big tech companies. Everyone knows what to expect at the interviews. The recruiters basically tell you. If I wanted to do the stereotypical r/cscareerquestions “work for a Big N”, I know just how to prepare for it. I have no reason to believe that if I prepared that I wouldn’t be just as competitive. In fact, I would be just as insulted if they gave me a different easier process because of my age because they thought I couldn’t handle a whiteboard interview as I would be if they gave me a different process because of my color if I’m applying for the same job.

Maybe even an algorithm that's objectively worse for that particular case, but arguing the point would only cost you more points. Those are things I've seen happen.

This is life. To paraphrase Buffett, the interview process can stay irrational much longer than I can stay solvent. If you’re an older developer, you should have the wisdom to know which battles you should fight and when you should just play along to reach the ends you want.

As I suspect you know, discrimination rarely declares itself. It's usually subtle, sometimes even unconscious, but it's still there. When evaluating such claims, it's helpful to look at what actually happens to others instead of projecting our own personal experience onto them.

He never said that he studied hard and thought that he was well prepared for the type of interview that he knew they were going to give but hired someone that wasn’t as prepared. If he doesn’t have time to prepare for the interview because of family obligations, that’s no more “discrimination” than me not being able to accept consulting gigs right now because I don’t want to be on the road right now because of family obligations.

What gets me is the entitlement around OP's post. They're older so clearly they don't have time to brush up on DS and algos. That rubs me the wrong way, as some one who transisitioned in to CS from another field and worked on learning that stuff. Yeah the signal is mostly on how many hoops you'll jump through and base analytic ability, but everyone has to do it and expecting a free pass just because you're old pisses me off.

I think the previous generation is so used to the idea of "pay your dues and skip ahead" popularized by their parents that even the idea that a fresh grad might work harder and be a better fit destroys their whole world view.

I've known plenty of talented engineers of all ages; they all can crush a white board interview; just because OP doesn't want to doesn't imply discrimination (or at least unlawful discrimination).

>they don't have time to brush up on DS and algos

The problem with the whiteboard trivia questions at hand is that they are trivia. They are deliberately obscure, or presented in a trick way. Brushing up on all the data structures and algorithms in the world and how those might be twisted into some 30-minute problem doesn't seem to be an effective use of time.

The fact that you somehow have an incredibly talented pool of friends that can crush any whiteboard interview thrown there way does not really represent most people - given by the fact that whiteboard CS trivia is a common topic, written about (negatively) by a number of talented professionals.

There's a selection bias there. Few people will write, and even fewer would read, a blog post about showing up and doing well on an interview (and most companies generally don't want you posting direct answers to the process). It is true that many positions are trying to find people with more ability than is required for the position, but are you arguing that the interview process should select most people?

Further more, there's a breakdown between pure trivia (problems that either just require knowing raw data or can't easily be solved from first principles) and "all white board problems". In my experience the people that take to the internet to complain weren't asked to verify a linked list isn't cyclical or write a topographic sort for a given graph; they were asked to traverse a binary tree or print Fizz Buzz.

>There's a selection bias there.

You're right, that is true.

>but are you arguing that the interview process should select most people?

Not by any means. Just that when possible, and to the extent possible, interviews should select using the least-bias methods available and to select the most applicable candidate for the position. Not the candidate that had the best recall memory of obscure problems after spending a few months studying from some "beat the whiteboard interview" website.

I have no problem with whiteboard problems in general. It's a very specific subset of whiteboard problems that are used as a be-all-end-all, and are solving problems which will never be encountered in the position. These are they type of questions all of my comments have been regarding - not the whiteboard questions that demonstrate knowledge that will be used within the course of the job, or obscure questions where you are graded on the how rather than if you memorized the correct answer.

Im going to be biased by my experience, but, I've only encountered one problem i'd consider explicitly trick trivia (and it wasn't on the white board, it was one of these "solve this problem on hacker rank to get an interview" type of deals so maybe I was being naive and you were supposed to look it up).

Overwhelmingly problems, especially outside of FANG or hedge fund types (which I'd argue can actually use algo exp) align much closer to Fizz Buzz in difficulty. What I have seen, is supposedly senior candidates completely fail at those problems and be pretty arrogant at the fact. If you can't write a for loop or traverse a tree and print the nodes, etc I don't really care how many years you've been employed you're not a good fit. I wish we didnt' have to ask senior people to white board fizz buzz, but if you don't have a network willing to stick a neck out it just has to be done.

This may be a metro thing; NYC is a different make up than SF. Here at the very least, I've far more entitled unqualified people with no qualifications other than they got their first job when all you need to know to be a programmer was html and failed upward on a mountain of bullshit ever sense than I have seen qualified people choke at the whiteboard.

It's more that this is stuff you haven't used in years (because people don't write heapshort algorithms for a living) but you have been practicing and learning a ton of others (adding value to your company) that simply get eclipsed behind damned pedantic interviews.

Let me put it this way. I use 4-6 prog languages at work. On a weekly basis. But you can say that I confused the syntax for the language I wrote in the interview and fail the interview on that basis and you would be legit from your PoV. Point is -in real world- I don't need and it offers no value to remember the exact syntax between Python, Ruby, Nodejs to do this or that. The thing is I can search the syntax and have it in a sec because I know the logic behind them all. And most of actually working people I know are very busy staying sharp in what they do rather than wasting time upskiling in WB sorting algos.

If you're writing code on a whiteboard in an interview, syntax, library calls, etc, should not at all be part of the evaluation process. You dodged a bullet on that one.

Being able to "get the recursive solution fast enough"? Depends a lot on the expectations, might or might not be an eliminating criterion. Definitely a problem e.g. for functional-heavy environments, where that style of reasoning is expected to be your bread and butter.

In the general case, I've seen fairly senior developers crash and burn on basic programming interviews (be they on a whiteboard, on a laptop, or whatever other format) due to genuinely weak programming skills, so I don't agree with the assumption that some candidates are "above" these interviews.

Also, a lot of seemingly pointless questions are good questions phrased wrong. E.g. I will never ask you to implement depth-first tree traversal on a whiteboard, but will ask to pretty print a directory structure, and make a note of whether a candidate notices this actually _is_ depth-first traversal dressed up as a practical day-to-day problem.

Of course, just because the interview format is not fundamentally flawed doesn't mean that plenty of companies don't mess up implementing it in practice...

Then again, your PSes suggest you don't want a reasoned discussion so much as you just needed to get that off your chest, which is fair enough.

In my experience, whiteboard interviews are absolutely a form of gatekeeping. Whether the firms know it or not, they are excluding candidates who would have succeeded in the role by including weird unrelated side content in the interview. As the OP rightly mentions, nothing you program on a whiteboard has any application once you are actually in the job. It can be incredibly frustrating to know that you can do the work of a job, but be denied because of an old superstitious test.

The only silver lining is that, ultimately, companies hire the candidates they interview for. If a company makes its hiring decisions based on trivia quizzing and whiteboards, they'll ultimately produce software that reflects that. During my last big job search, I eventually started asking upfront if there was whiteboard coding in the interview. I don't want to waste my time.

Beyond whiteboard based coding being a bad medium, on-the-spot programming exercises are a super noisy, poor medium for assessment compared to the alternative: a work sample in the form of a 4-8 hour programming exercise done by the person on their own terms. No exploding deadline, no restrictions on tools other than those necessary to show the person's relevant job skills. Make a bunch of them, put the time into them, and let the candidate have a chance to pick from a library of exercises that are interesting and fun to do.

The main downside to a work sample is that a lot of people will say they simply don't have the time to do it. That's fine, you'll lose some people, but you'll also have people applying who really want to work for the company. From there, you'll have a small number of people who do a great job on it. By the time they are in your office interviewing, the idea that you'd reject them because of a slip-up on a small coding exercise on a whiteboard is absurd, because you already have a mountain of evidence regarding their skills as a programmer. The in-interview exercises will be there to test other skills like communication and collaboration, not writing good programs.

I think there's a good argument that larger-scale work-sample exercises like this are even more ageist because older candidates are more likely to have family commitments that give them less free time to allocate for things like this.

Frankly, I've heard this before and I disagree. (I'm a parent.) It does mean you have to be selective with regards to what companies you apply to: you don't have infinite time (and nor does anyone.)

It's a catch-22, however. I look for companies that have good interview processes, because it means they are going to have good employees. I feel pretty strongly that good skill assessment is a critical component to hiring good people. I don't think you can hire programmers based upon resumes, references, or 'track record' alone. I think you need to assess their skills in a very deep way during the interview process, since there are a lot of candidates who look good on paper and can talk the talk (deliberately) but when actually put to work aren't up to the job.

So, I look highly upon companies that actually provide a good forum for showcasing my skills: not just because it means my interview will be fair, but it also means that the people I'm working with will have had their skills assessed in a similar way. I'm willing to make that tradeoff in time and prioritization. It's basically this tradeoff: unless you think you can hire good programmers without a assessment, you either should expect to be assessed (and should look kindly upon assessment mechanisms you feel do a good job of assessing your skills, like a work sample), or you should expect to work with less skilled programmers, on average, if you get the job.

edit: should add, I love your game programming book! :) thanks for writing it.

Yes, I agree with you overall. I'm not crazy about the algorithms-on-a-whiteboard process, even after having been on the other side of the table many times. I have very little confidence on my ability to judge someone's suitability as an engineer based on their performance at a whiteboard.

At the same time, I just wanted to point out that deeper interviews have flaws too. The time commitment is a real challenge, in particular for people that have kids or are in an economic place where they may be working multiple jobs. You don't want someone's inability to commit the time to interview to inadvertently filter them out. Especially because the people who have the least time are often the ones most in need of a good-paying, stable software job.

> edit: should add, I love your game programming book! :) thanks for writing it.

You're welcome! :)

The last place had me wasting (as I now understand) a weekend for a project as well. Go figure.

I tend to avoid places that whiteboard, the one time I did have to do it I sucked it up only because a friend stuck their neck out to get me the interview. I was told syntax didn't have to be perfect. Yeah I think they may come up with stupid excuses basically to not hire you.

Honestly, interviews go two ways: you figure out if you really want to work there, and they do as well. If they don't want you, assume it's for the best, you would of had to deal with worse: coworkers who hate your personality or have a toxic personality.

you figure out if you really want to work there, and they do as well

I don't think this can be overstated. If you don't enjoy the interview process, you probably don't want to work there.

At the same time, interviewing is often the only way you can find out if a company is really serious about hiring. In my experience, most companies with organized HR have certain positions that they are "always hiring". Which isn't really true, they just want to have the light on in case a rock star happens to be looking for a job.

I've been on a bunch of interviews where it was clear neither the company or hiring manager was enthusiastic about finding someone to fill a position, but that HR was pressuring them to keep the light on.

I don't think this can be overstated. If you don't enjoy the interview process, you probably don't want to work there.

I disagree with this. The interview that I enjoyed the most was with founders who took me out for beer. We talked a bit about software but most of the discussion was small talk.

After a few months of working there, I realized that some of the people in the office didn't really have any qualifications except "liking beer" and it wasn't a professionally interesting place to work.

My least pleasant interview experience was with Google but I enjoy working there.

I was not prepared when I had my last interview like this, but if I ever go interviewing again I'll make sure to have my own algorithmic problem at hand (to which I'd know by heart all the tricks and improvements).

Then at the end of the interview I'll ask the interviewers to solve the problem (or just give a description of how it would work). Point being - if they interview you on this stuff but can't do it themselves without knowing the solutions before, then how could they reasonably claim to be assessing you? And would you want to work for someone who does this to potential employees?

It sometimes seems like these interviews are dk measuring contests between the two parties.

That's perfect. If you think an interview went badly. Give them an algorithm problem at the question session that very likely they won't be able to solve. That's a perfect way to show them their bias.

It amazes me people still actually do this. Why would you, in 2019, not just ask a person to bring their laptop with their preferred development environment set up on it and ask them to solve some basic coding exercises there instead.

Physically writing code with a marker on a wall seems akin to asking a mechanic applying for a job to demonstrate their skill at repairing cars by performing a 'repair' on a miniature car made of lego bricks.

Edit: one thing I noticed once I started having candidates work on their own laptop was a) some very unqualified people slipped through the screen and this can be obvious when they have no programming tools on their personal machine and b) you can learn a lot quickly from seeing someone use their own machine -- you get a clean signal if they are adept at using their text editor, git, build tools, etc, without risk of a contrived setup making it a false negative.

Square’s interview was like that a few years ago. Even has pair programming with the interviewer. Most fun I had in an interview!

Still stings when you thought you had a positive experience but they didnt think so. Only other time I had that experience was with first dates that I thought went well.

Yep nobody likes getting turned down by a potential employer, but it stings 'less' if you feel like you were treated fairly and given an objective, un-biased forum to showcase your skills. Nothing is more demoralizing than being able to replay in your head the point in the interview where you got 'dinged' for something ridiculous due to a quirk of the process like marker-based-programming and feeling that sent you on the trajectory for a rejection. In those scenarios, it can even be a self-fullfilling prophecy, since if you are intimidated by marker-based-programming it can just lead to little mistakes due to nerves that ultimately cost you the job.

> Nothing is more demoralizing than being able to reply in your head the point in the interview where you got 'dinged' for something ridiculous due to a quirk of the process like marker-based-programming and feeling that sent you on the trajectory for a rejection.

Honestly, I'm so desensitized to that so I don't feel that way. I go in expecting a random brain teaser that I BS my way through.

I actually land most jobs by recycling interview questions and answers from prior interviews.

"Let me know if you've seen this question before" NOPE

But more companies have also done more core competency related exercises with IDE's set up or take home exercises. Haven't been paid for a take home exercise yet, but I'm hearing thats happening a little more too. I think a lot of startups in the bay area are content that their employees will stay for around 18 months, so they dont need the brainteaser rationale that they need to interview an engineer on the idea that they change teams.

I hope you don't ding them on speed. "My own machine" has an ergo keyboard because typing hunched over a small laptop is always awkward.

I don't have a problem with whiteboarding, I collaborate with teammates all the time to design rough sketches and even bits of code on the whiteboard. The only critism I would have is if the interviewer is overly strict on things like syntax and API names.

White boarding questions should be related to the fundamentals of computer science and programming. Trees, hashes and arrays have been and will be around forever, it's fair game in an interview setting.

Right but these questions can get mind bending. Like count the amount of ways to make change for a dollar. That's a basic tree question.

Anyone else thinks that Whiteboard interview is just covered ageism?

It really depends on who is interviewing you. It can be. Even the Google Hangouts, screen-sharing one can be. I've definitely had that sense from one interview.

Given that I am 42 yrs old and been at this line of work for 14 yrs now

I'm a bit older than you, and have just a bit more experience, so I think I know where you are coming from.

Whiteboarding simply tests for skills that are not needed nor exercised once you're out of uni.

Again, this greatly depends on who is applying the technique and how it is being applied. It can be applied to see if the person can actually do the kind of systems thinking to put a new design together and make it specifiable, such that someone could go and implement it.

That said, I've also taught courses to high school, college, and professional students, and I think the skill set for interviewing and the difficulty of learning good application of the techniques is of the same scale as teaching. In other words, don't expect to get good outcomes by just giving interviewers a few seminars, then telling them to go at it. You'll get the same level of interviewing as the level of teaching you get by doing the same thing to TA's with no experience.

The biggest single issue I've seen in whiteboard interviews, is the interviewers being hyper focused on what they want to find, and not listening to what the candidate is saying.

Yesterday I read that Google actually decreases their expectations in the white boarding exercises for experienced hires because they realize the leetcoding techniques will not be as fresh in an experienced dev's mind. The expectations are higher in regards to system design and resume questions. That seems to be fair imo.

Later in the material it said that they reject over 80% of people who make it onsite. The bar at FAANGs is just relatively high regardless what kind of role you are trying to get. My mentality is preparing for high bar whiteboard interviews best case lands a job at a FAANG and worst case makes it incredibly easier to land a job elsewhere at a company that doesn't rely on whiteboarding or has a lower bar in general. That's to say investing in whiteboard practice has little downside and has an acceptable time/reward ratio given the results if you are even just ok at it. In terms of ageism whiteboarding is not required to filter older devs out. Resumes viewing can do that. Why would they waste 6+ hours of their expensive Sr. devs time to put someone through a pointless exercise? Serious candidates will commit the same 1-3 months of study whether they are 23 or 43.

Great to hear that. I went through that hell (of course fell into the 80%) a few moths ago. Needless to say I was in total awe by the whole process. Awe as in, what the heck did I waste whole weeks for? How can the -seemingly best IT company- hire like that? Funniest part was that the recruiter giving me the bad news was assuming that I'd spent some more time in the future trying again to get in g. Like this is a life purpose or sth and she actually mentioned exactly that. Most people don't get in at first attempt. Which is like saying "we know we do it wrong because we hire the same people the second time around" so what the heck is all that supposed to test? Perseverance? Anyway - after that I had serious doubts that I'd ever be happy working there anyway so I was pretty confident that there wouldn't be no second time.

They hire that way because they are optimizing to avoid hiring bad engineers. Their entire process is shaped around that goal. In such a process, passing on good people is not considered a problem -- especially when they will reapply, which they do.

I think it's a bit in between. FWIW, at 54 I've never failed a whiteboard interview, including at my current FAANG employer, so this is most certainly not sour grapes.

While not deliberately ageist, I think whiteboard interviews work out a bit that way. What can be tested in such an interview? Only a sampling of domain knowledge. It will tend to be a sample weighted toward the particular problems and algorithms that will be super-fresh in the minds of people still in or fresh out of school (usually because the interviewers themselves are). To someone older but still well versed in that domain, those particular details might have been crowded out by a thousand other things learned since. They might seem less familiar because of changes in language, notation, or idiom. Those same differences will also affect how the result is "graded" even if the candidate solves the problem quickly and well.

Whiteboard interviews also fail to measure other things such as ability to select algorithms or higher-level approaches, people or organizational skills, industry knowledge, or a developed "instinct" about what symptoms suggest what problems in the relevant kinds of code. As more weight is given to whiteboard skills, less weight is given to literally everything else.

As I said, I don't think any of this intentionally disadvantages older workers, but it can have that effect without intention. It has never hurt me personally, but I have plenty of peers who I know beyond doubt could code rings around the people who interviewed them. They just couldn't dance that particular dance well enough in that moment and got rejected. That's a loss for the (potential) employer as well as for them.

Not saying that whiteboard interviews are perfect, but is there something inherent to them that makes them favorable to younger applicants? Your main argument to this effect is:

> Whiteboarding simply tests for skills that are not needed nor exercised once you're out of uni.

But I don't know if "whiteboarding skills" are any more useful during college either. Also, I always thought explanations were the crucial part of the interview, and I think technical explanation is an important skill.

That said, it may be a flawed practice. I'm open to arguments to that effect. But so is everything else[1]. I'm interested to hear some thoughts.

[1] https://en.m.wikipedia.org/wiki/Goodhart's_law

100% not ageism. Whiteboarding itself is just a skill to practice. I don’t pick jobs based on the interview process, I pick the companies I wanted to join and practice the skills needed to pass the interview. After 10 years in the industry my whiteboarding was always terrible until my last round of interviews where I decided to actually focus on it and I passed the interviews at Facebook and Google. My problem was that I could always solve the problems but I was too slow without the keyboard and the compiler to help. So I practiced writing code without those tools and got faster. I think if anything my experience helped, so I’ve come around on whiteboarding. It’s not perfect, but any good coder can learn it and the bar is not really that high.

Same with "culture fit" interviews imo. How people don't think they just create massive bias is amazing to me.

Oh yes... this is a really lame concept.

I want to work with people who are 'not assholes'. That's important. Otherwise, I don't care if they're just like me or whatever 'culture fit' means.

> I want to work with people who are 'not assholes'. That's important.

That's what culture fit means. It's a more polite way of saying "Not an Asshole"

I think in some cases it means something more akin to "it'd be fun to hang out with this person in a social setting". I've had plenty of good co-workers where that wasn't really the case and selecting for it is a mistake.

Not to mention there's a pretty broad range of behaviors that probably don't make someone an asshole, but may or may not work at different companies.

Things like valuing collaboration, how blunt feedback is during code reviews, whether tech leads coaching and spending time developing junior colleagues is valued or viewed as wasted time, how open a company is with finances, where company events are on the continuum between a couple glasses of wine vs kegs of beers where people get wasted, etc.

> where company events are on the continuum between a couple glasses of wine vs kegs of beers where people get wasted, etc.

This should have zero bearing on hiring people. How much they drink is their own business as long as they don't get rowdy or harass colleagues or something.

Among other things, are you going to, say, not hire someone who's LDS because they don't drink at all?

"Not the right culture fit" is pretty much code for "we have reasons we'd like to reject the candidate which we don't want to go into too much detail about".

The vaguer the reason for rejection the more suspicious I tend to be that it's at least implicitly related to some sort of shameful prejudice.

Dinging a candidate on culture fit is very rare for me, and basically means "I think some people would quit to avoid working with this guy."

IME when a candidate gets dinged for a reason that would make people quit to avoid working with him (e.g. "he obviously doesn't shower") then people don't tend to invoke the words "culture fit".

While it is a bit general i think it is valid. I’ve made some bad hires and they had common warning signs. Some people are obvious ronin developers that refuse to accept input or accept that there is a bitter idea than theirs. Also, I need my devs to talk to BAs, customers and other companies we integrate with. You will be representing us so it’s not just our team/company that gets affected by a bad hire.

I do not think white boarding is a cover for ageism.

I think a group collaborative exercise where you're sketching, drawing, or otherwise visualizing an abstract concept to explain a point, answer a question, or justify a decision is a skill that talented, effective people can leverage regularly to get great results at work.

I think testing for this skill is a really good idea.

I think that doing this in a way that's equitable and emotionally supportive to the candidate takes thoughtfulness and effort, and not every company/person in this process does this well.

I also think there's a great number of people who turn this concept in to a boogeyman to rationalize their interpersonal or technical ineffectiveness.

I would use a whiteboard interview to evaluate a candidate (and have), I would happily submit to a whiteboard interview (and have), and I think that all things being equal, the noise around them mostly comes from people who perform poorly on them and if I'm a betting man, a team made up of people who performed well on an equitable, well structured whiteboarding exercise would outperform one made of people who did not in the work context of building software as a team.

Some of the most impressive whiteboard/coderpad performances I’ve seen have been from middle aged candidates. When someone has been using a language for 15+ years, their agility and fluency in expressing their algorithmic ideas in code is incredible. Most candidates seem to understand and articulate a solution by the end of the interview, but it’s the fluent ones who can prove it with end to end working code.

Whiteboard interviews would be great if they tested the kind of things that we would do on a whiteboard, namely design and _maybe_ pseudocode. If someone is interviewing for an algorithm job, I'd expect they could write text in boxes that might describe how the algorithm works. If someone is interviewing for a front end position, I'd expect that they could draw some boxes describing the UI, and depending on the underlying technology maybe add the info on the containers and subwindows, or describing the MVC model, or high level actions drawn with arrows that show what gets affected if some button or UI item is pressed or selected. If someone is being hired for a networking job, then I might expect to draw up some boxes that show a topology for some scenario and identify where the security structures might need to be. For a straight-up programming job, maybe I could see drawing flow charts or sequence diagrams or something that might actually be useful to draw out. I would certainly not expect to write code on a whiteboard. That's not what whiteboards are for.

I've been on both sides of the whiteboard interview (candidate and interviewer), and I've failed a good number of them. The last one I had as a candidate was about 4 years ago, incidentally when I was 42 (I did get that job and I'm still with the same company).

The best whiteboard interview evaluates a candidate for technical skills and soft skills at the same time. I want to see if candidates ask questions and can deal successfully with ambiguity as much as knowing the "right" answer. At the same time I'm asking questions about their previous work, specifically looking for concrete examples of how they balance the needs of different stakeholders in a project.

The worst whiteboard interviews look to evaluate knowledge of a specific algorithm, and don't provide help when the candidate is stuck. The very worst is just a pretext to cover up the interviewers biases.

In my experience, the right company is out there for you, but as an older candidate it can take waiting a long time for the right opportunity where you can highlight the specific skills you've spent your life accumulating.

i wouldn't take it too personally nor read too much into it. the whiteboard interview wants to extract signal ranging from "make sure this person isn't a complete n00b/fraud" to really relevant problems that should probably be eminently doable, depending on role. but due to a variety of factors it doesn't do this very well. for many the biggest is social pressure where at least 1 person is completely watching you work, which is stressful if novel or you're shy. or lack of familiar tooling, or whatever.

yes there are myriad better ways to extract this signal but, as the saying goes, you get to choose the game you play but not its rules. you've enumerated one option which is refusing whiteboard interviews, but you could also level up your whiteboard game without too too much effort. personally i don't think it's time to reach for malice after 2 failed attempts at something i'm inferring you haven't done in awhile.

You’re suspicions and frustrations are valid and are based on your experience alone. No one else here was in those interview rooms with you and if you subconsciously picked up on the presence of an age bias you probably weren’t pulling it out of thin air. In my experience in multiple industries as both interviewer and interviewee I’ve felt similar biases and often had them inarguably confirmed. And I’m somewhat ashamed to say that I’ve partially acted on such biases as well in rare cases. Interviewees deserve better treatment and more transparency, period. No one should have the right to exert that kind of toxic power dynamic on a fellow professional. I’m 32 in a new workplace in SF and I can already feel the subtle force of ageism lurking in the subtext of interactions with coworkers. I appreciated this post, thank you for speaking out on this. PS I love white-boarding.

There's a basic truth about being a knowledge worker that most people don't think about. This truth holds for young, old, programmer and non-programmer alike.

If you want to stay relevant and fresh long term, you need to be continuously learning. You can get away with not worrying about ongoing learning in the short term, say 8 years or less, but in the long term it's going to catch up with you.

This is one key reason programmers tend to move to other careers or into management after 10+ years: it's a lot of work to continuously learn. And worse than that, it's uncomfortable and makes you feel dumb when you know you're really smart and capable. Learning to embrace that feeling of being dumb, of being a beginner, is key to growth. And once you stop growing and learning, you start getting old.

For developers this means learning new languages, techniques, technologies, methodologies. If we accept that this learning is going to be happening, then it's not too much to ask that data structures and algorithms refreshers are part of this ongoing learning say 1 out of every 3 or 4 years.

Most engineers actually don't do this, and just stick with what they've been doing for the most part. Or just happen to passively learn whatever is rolling by them in the course of doing their job.

For engineering, there are actually tons of things that need to be studied that are technically not part of the job: writing skills, communication skills, math skills. Sometimes these things help you even though they're not part of the daily grind. The same goes for algorithms and data structures.

Studying these things also sends a signal to your interviewer: you're willing to go figure it out even when it's not fun and not convenient. As a hiring manager, I like that. And we can debate whether it's a good thing, but it is what the situation is at many places. Plus, it's fun to study a lot of it, so it's a good option to get on the learning.

> Whiteboarding simply tests for skills that are not needed nor exercised once you're out of uni.

In today's tech industry, these algorithm questions is now used as an effort to trip up candidates and to always try to "See how you think" in an unrealistic scenario. The questions I've been given and have seen are mostly irrelevant and are always done for us in the libraries I use at work.

I had interviewed at one startup in the UK who asked me a algorithm question that they admitted that they don't use and their excuse is the same: "To see how you think." Not only this doesn't make sense if one has already seen this problem, but the fact that they don't use it makes you wonder the real reason why they are doing this.

The simple answer is: Because it works for FAANG (Who actually do use these algorithms); Thus everyone else copies them. This is why hiring in this industry is a complete circus.

> Things like improper syntax and not getting the damned recursive solution fast enough.

A problem statement like that is like: `Design and implement the optimal solution to this 'problem' in X language in less than 15 minutes.`

This is a red flag for you as a candidate who is allowing room for the interviewer to nit-pick you here to waste your time. It should never be that important to worry about the specific language semantics here due to the time limit. But again the interviewer is there to be impressed on how much the candidate knows about the intricate details of the language + data structure + algorithms all in 15 minutes which is nonsensical requirements for a typical software engineering role.

Frankly speaking, the interview dance in the tech-industry is an excuse to trip up candidates who have not practiced for more than 6-9 months on data structures and algorithms and the latest tools that everyone is adopting. It is so 'broken' that interviewing at FAANG companies is an entire industry itself.

For them, whiteboarding like this is essentially trying to find a silver needle in the sky.

A lot of teams at FAANG companies don't use those algorithms either.

However, if you want to hire generalist programmers who are good at solving problems and can work on a variety of projects, it's perfectly reasonable to want to see how they think.

I've only done whiteboarding in interviews for system diagram type stuff and explaining high level ideas. At my job, this is mostly what we use the whiteboards for in day-to-day work. Some people say they built a system, but when you ask them to draw the boxes and arrows to describe how data flows, it becomes obvious what pieces (if any) they actually touched. I think the people who do best in these are either more senior in their careers or have done a lot of side-projects from scratch. They have either seen a system evolve over time and solved scaling bottlenecks or they've set up many systems with a few different stacks and have thought about what the pieces are for.

It depends. If you're talking about whiteboarding code, I only have to do that once a year or so, usually because I'm in a meeting and want to demonstrate what I mean and code is easier. If you're talking about whiteboarding a design, I do that much more frequently. I prefer a pair programming exercise in this case, but I've reverted to whiteboard in cases where there were technical issues. It's not my favorite but neither is trying to do it in a text editor without support.

I see nothing wrong in having to show a high level design of a system as a senior engineer, because we are asked to do that quite often.

I'm older as well, but I usually ask my candidates to use the whiteboard to workout solutions. It demonstrates that you can communicate effectively, as well as think on your feet :) I don't think it should be all about coding riddles, but I also don't think you should be surprised by them.

As a developer, I've always used whiteboarding as a way to communicate ideas, architecture, etc. There have been whiteboards in every office of every company I've worked at.

I'd say somewhere around 75% of all interviews I've had for positions at other companies have included whiteboarding.

I don’t see ageism in it.

If you’re, say, six years out of school you are still quite young but your school skills that might give you an advantage at a whiteboard will be pretty damn rusty.

Interviews in general are not really “fair” since the employer really has no way to get out of a short meeting (or series of short meetings) what they really want to know.

Given that it isn’t possible to have reasonable certainty and the massive cost of being wrong, a strategy of erring on the side of rejecting good candidates rather than accepting poor candidates isn’t unreasonable as long as you feel your pool of candidates is rich enough.

I'm young and have also been turned down often due to whiteboard interviews. What surprises me is that you were only rejected twice in a few months. I had to go through many, many more rejections than that much quicker than that before I found a good fit. Don't assume these interviews favor young people, it certainly didn't feel like that to me. I think most places just want to reject most people, because it's easier to justify rejecting someone good than accepting someone bad.

I'm going through this right now, with 26 years of professional experience and an undergrad degree in CompSci.

There are many problems with hiring. Many. And as with standardized testing in public schools, one problem is how to judge the capability of many people (applicants, in this case) in a reasonable time, ESPECIALLY when the judges may not be experts in all relevant topics. The popular answer is to test against standards that are easy to measure. In the end, the companies may end up with fewer false positives (hiring an idiot), but will accept the likelihood of having more false negatives (missing out on a good employee).

I don't agree with this approach, but mainly because of more a fundamental reason. The #1 reason that most hiring is broken nowadays is that it focuses on specific skills (often an unlikely/unrealistic laundry-list of technologies) rather than focusing on the candidate's ability to learn, think, and communicate.

Regarding filtering out older candidates, this is more a side effect of testing on topics that would be more familiar to more recent grads. Likewise, if interviews included demonstrating how a candidate would choose between C#, Python, Ruby, Go, C++, Java, or Javascript for a given fantasy scenario, or when to choose between bare metal servers onsite or virtualized hardware onsite or managed or unmanaged cloud resources, younger and less experienced candidates would fail more than older ones. They just don't have enough experiences in different situations to know how to make these decisions (with an reasoning to back them up).

The practical reality that I see is that older developers just may not be worth the extra cost compared to younger, less experienced ones. This will be especially true in many corporate environments where the more experienced, more senior dev will have higher expectations, want more authority and autonomy, and otherwise feel stymied by corporate drag. If the older worker hasn't ascended into management, they have little road left to travel.

What many of us older devs didn't realize is the situation we would now be in. At this point, we must forge our own paths - by starting a consulting business, forming a startup, building a SaaS or other income-generating product, etc. It does little good to be angry at the system (since our complaints will absolutely not change anything).

I buy this. But then again, why go through all the trouble? They can just reject you once they see how old you are (and blame something else or not tell you at all).

I’m 45, had dozens of interviews in the last 10 years, only one or two rejections and 5 jobs. I am a developer and haven’t had anything resembling a white board interview.

For the job I have now, I was hired as a developer but never actually had any development related questions besides asking about my previous projects and architectural decisions. I also don’t live anywhere near Silicon Valley and mostly worked at your standard Enterprise shops.

Can you please contribute the names of these companies to https://github.com/poteto/hiring-without-whiteboards You'd make me and a lot other people a big big favor. Thanks a mil.

I can tell you that it’s every company I’ve interviewed with in Atlanta for the last 20 years.

Anyone can crash and burn in a situation like that, particularly since it sounds like they are putting too much emphasis on the wrong things. I have had a couple of interviewers go back to the question and ask how I would approach it in a more realistic setting, meaning that they were more interest in process than the solution. Unfortunately, that was the exception rather than the rule.

If we stipulate that whiteboard interviews might be useful for evaluating candidates in some cases, a good whiteboard interview would have specific criteria expressed in some sort of rubric or other document. That document would be shared with the candidate and evaluator(s) in advance of the interview. This ensures that the candidate and evaluators have a shared notion of what constitutes success before the interview. An opaque process, unfortunately, can cultivate the type of suspicion that you're expressing here. It sounds like your whiteboard interviews did not give you a good sense of the types of skills they were looking to evaluate during the interview.

I think it's great that you have such high self-esteem and aren't doubting yourself just because some other people don't see your value. That said, I think more data is needed before concluding that whiteboard interviews in general are tantamount to an age filter.

Edit: please note that I have said "if we stipulate," not "if we accept as an a priori truth" that whiteboard interviews are good. It's simply a rhetorical device for evaluating whether or not your whiteboard interview is at risk for evaluator bias.

This is a ridiculous position to take. The amount of code that I have to write on a whiteboard to successfully do my job as an engineer is shockingly close to nil. The very notion of having a whiteboard section for a programming job is insane.

You wouldn't expect a driver's test to include a significant oral portion, where the drivers spend an hour describing how they would parallel park. A whiteboard interview makes just as much sense, regardless if you're sharing a rubric.

I happen to agree that whiteboarding is not a good use of time in an interview, at least that's what I've concluded from my own experience. But not everyone shares that opinion. And for what it's worth, I'd take a whiteboard interview with specific, measurable criteria for success over a coding challenge with no transparency any day of the week.

Please note I said "if we were to stipulate," implying that some teams value whiteboard interviews in good faith, not that I'm advocating for investing 30-60 precious minutes in an exercise that might not align well with what your team values in a colleague.

Edit:

I'd also like to point out that parallel parking is a well-defined task with a narrow set of criteria for success. Creating valuable software is not such an easily-measured endeavor.

Whether or not whiteboard interviews make sense for programmers is a different question than whether or not they are intended as an age filter.

If there is a portion of a programming interview that doesn't make sense for programmers; but the results of this section skew the results of the interview highly towards recent college graduates, what would you say is going on?

I think you're addressing a symptom, not a problem. When any candidate evaluation process is opaque, you invite bias into the process. Whether whiteboard interviews are useful or not is subject to debate (it's not a factual statement that whiteboard interviews are universally bad). Whether a whiteboard interview is done fairly and without bias is a different proposition altogether, and the interviewers can do a lot in order to address this concern.

There are also portions of most interviews, e.g. system design questions, that heavily favor senior candidates.

It seems like a whiteboard is more akin to the paper drivers test, which is a significant, non-driving part of getting a license. While whiteboard interviews can easily descend into gotcha-type puzzles with the wrong interviewer, that in itself is a solid sign you don't want to work for that company - they've failed your test, and they've done it in a nice, easy to comprehend way. Thank them and move on.

If, on the other hand, the problem with whiteboard interviews is that they're asking someone to come up with 'trivial recursive solutions' and 'know things somebody who just graduated might about data structures and algorithms'... While I agree that many positions do not require a solid, able-to-apply-at-a-moment's-notice knowledge of the above, I can't think of a single one that wouldn't have severely benefitted from having that knowledge.

If someone is unable to use basic recursion, recognize patterns in their problems and refactor them using higher abstractions (or just know of the existence of the higher abstractions in the first place and solve the problem more easily because of it), figure out how to put together basic data structures and algorithms, or even attempt to think through out loud how they would solve a problem they don't know the solution to, it isn't ageism - it's discovering that someone isn't the right fit for how you imagine the engineering culture at your company should be.

I'm a bit older than you, and am really wary and tired of lame interview stuff too.

IMHO two samples isn't quite enough to form useful data. It's a rough trend, certainly, but more tests are needed to be sure.

Could be you dodged a bullet. Could be the interviewers were hungry. Could be they didn't like your clothes.

42 is not that old.

Could be his attitude. The older we get, the more rigid we come across. I know I personally put up with a lot less shit than I used to, hence why I doubt many would want to work with me - and that’s fine by me.

This is a discrimination issue, and this thread is full of comments about people that have not been discriminated against. good for you, but it doesn't mean the problem doesn't exist.

I think leetcoding has become the norm to increase the friction when considering new job opportunities and keep wages lower. It incentivizes people to cut down on job hopping.

That makes zero sense. Companies may want to increase friction for people leaving them but they want to DECREASE friction for people joining them. Using white boarding as part of your recruiting process would increase friction in the wrong direction.

If everyone uses whiteboards and leetcode, existing employers win. Now, I'm less incentivized to join $NEW_FANG because I have other obligations in life and can't commit to that much leetcode. On second thought, it does lead into the OP's point: it seems like a legal proxy for age discrimination. New grads, which will work for less and offer no experience (beyond internships), will have more aptitude for leetcode-style assessment.

Read my comment again. White boarding increases friction in the wrong direction. Companies make decisions to benefit themselves, not the industry as a whole.

Also hiring people who are willing to work for less money is not age discrimination.

well i agree with the part about low wages; i asked an interviewer to show me an example of a real challenge they were trying to solve (or had solved) and let me take a crack at it. instead i was told, "no, no.. please lets see if you can write a function that adds these numbers..." my eyes rolled so far back into my head i just stared at the whiteboard and thought, so you want a grad who can do this with their eyes closed (they have a memorized solution that will in no way predict their ability to solve the real problems) but probably will do it for a pay grade just above "intern".

Literally only college grads are marginally good at that. Nobody likes whiteboard interviews and has to brush up. Everyone knows tech interviews are inefficient.

2nd interview in a few months you were rejected? The only ageism here is that you probably dont have time to interview at the number of companies that your competition does. Last time I interviewed I did 16 interviews in one month at probably a dozen companies, received 2 offers. There are some blogs posted here where people talk about doing many many more than that.

I would say whiteboards suck but no not the ageism you are looking for.

You’re giving zero details here aside from “i failed the whiteboard interview and it was horrible”

What happened?

Maybe it’s you.

Most juniors fails white-boarding as well, so we can assume that most seniors would fail whiteboard interviews when they were young as well. So I think this isn't ageism, just people with lots of experience who don't want to admit that they weren't the top X% of their cohort. Of course it is easy to believe you could have passed them back then due to the Dunning Kruger and the "Good Old days" effect, but that doesn't mean that it is true.

If your argument is that you barely passed those interviews a decade ago and it takes too much energy to practice again, then I'll say it is a feature. The more we discourage less capable people from joining the better, don't you agree?

Of course this all assumes that white-boarding is a good indicator, but the companies administrating them has pretty good statistics that they work. Also it doesn't have to be on a white board, at least Google lets you write on a Chromebook since a few years back. The important part is that the candidate has to solve and code a non-trivial problem not available in public (meaning they can't have seen it before).

You’re giving zero context here aside from “there was a whiteboard and it was horrible.”

What happened?

Age has nothing to do with it - if you can’t communicate.

I've already said way more than I should considering I need to stay in this business for a good few more years. Communication was fine if that's what you're asking.

I'm a bit older than OP - just recently turned 46. I've been a software engineer (professionally) since I was 18 years old when I was first hired by a small mom-n-pop shop.

One would think I could simply plop my resume down, do an in-person interview, show a bit of code I've written in the past, plus my github, and that'd be enough. Alas, it isn't.

I've had good interviews that used a whiteboard, and bad ones that did. Overall, though, I detest whiteboard "challenges" and I specifically avoid them. Currently, with my use of recruiters, I tell them specifically not to send me to such interviews if they use a whiteboard (it would have to be something really unique for me to consider it - maybe for a ground-floor startup opp, or something in robotics or AI, etc).

The best interview I had that used a whiteboard was basically where they asked me to write fizzbuzz whiteboard style. Whenever I am given such a task (ie - write code), I ask the interviewer if they mind if I use "pseudocode" - just to get the whole "wrong syntax or keyword" issue out of the way. I've never had a turn-down from this ask. I liked that they wanted me to show I could do fizzbuzz "from memory" because it would show I wasn't copying/pasting from that github repo of "all versions of fizzbuzz", and it would also show I had some idea about programming. After that, and the in-person portion of the interview, they gave me a take-home challenge to write some piece of small software (IIRC, it was a random-number dice game or something), and upload it to their system for evaluation. I actually ended up getting an offer of a position from that job, but I ended up taking a different position with another company.

The worst whiteboard interview I had, though, felt like a complete grilling session. It started off reasonable enough; ushered into a large conference room, and I was questioned by a couple of programmers on their team, plus their hiring manager. All seemed ok. They asked me to do some whiteboard work - some SQL coding IIRC, among other things - all was going ok as I was writing down an answer, but every time I turned around to the interviewers - there were more people in the room. By the end of it all, it felt like the entire staff of the company was in that room and nobody was out doing their job. Had to be 20 or 30 people in there. To be honest, it rattled me - mainly because it was so odd.

I didn't get an offer on that job - and to this day, I am glad I didn't. While the company and the office location all had a "hip and upcoming" startup-like vibe, plus open-office floor plan, etc - at the same time, I wondered why they had such a large SWE team (10+ people from what I recall) for what was essentially a basic PHP CRUD application.

It was interesting to note OP's idea of it being a potential age filter; I'm not sure I agree with that fully. I wonder if it isn't meant as more of a filter for those who didn't go to school to learn the craft. I mean, I've probably done at least once certain things being asked for - but if they couch them in terms that are "defined in the literature" (this also covers asking about "patterns") - I'll most likely be lost. Because I don't know all of that terminology, or what it applies to. I've been coding in some fashion or another since I was 10 years old, but I haven't gone to school for it (aside from a couple of community college classes for C/C++ - algorithms and/or patterns were not discussed).

If so, it's kinda on them because they didn't read my resume carefully; I note up-front that I don't have that education, that I am a self-learner, and that I don't like to be a "specialist" in a particular language or framework-du-jour. Rather, I'm a business problem solver - the ultimate choice of how that problem is solved is an implementation detail that has only a certain bearing on the problem solution. Mainly, it's better to come up with a solution and then choose a language for the specifics of that solution that will work to implement it. 9/10 times you don't need the latest language or framework for most problems. It's more knowing when you do, rather than just picking one and sticking with it forever (ie - I don't want to become someone mired in only using and knowing COBOL). Likely, any problems that crop up in a solution tend to do with how the solution was implemented, not what language/framework it was implemented in.

Lastly - something I have noted post-interview is the fact that seemingly none of the potential employers care to contact or do contact any references you give them. You can ask them if they want/need references, but even those that do, never follow up on them. I am not sure why this doesn't happen - maybe it's just a simple constraint of time vs number of resumes/interviews? Or maybe it's due to past candidates gaming the system, and making it an unreliable metric to the process?

This is an interesting take. I'm in my forties, will/hope to be a direct tech contributor for my full career, and definitely make sure to prepare well for whiteboard interviews. I find them fun to a degree, and I used to nail them in my youth...and still do well...

Still, the ageism take is interesting but I don't like falling back to that kind of thinking b/c it is counterproductive.

The evolution of my own performance in whiteboard interviews (and anecdotally what I've heard from other experienced developers) is interesting:

I don't feel like it is directly due to age or cognitive change/decline, but more to do with mastery/experience.

As you get more experienced in this craft (as with others), one of the most important skills you learn is navigating _context_. After solving real world problems repeatedly, you move further away from the aseptic environs of academia/learning and find that prioritization and contextual understanding is far more important to superior execution.

More explanation...

I was in an interview recently and got the typical line of puzzle coding questions. These puzzle questions are completely denuded of context (which is irritable to a professional practitioner). Or, rather, the context becomes not to solve a problem with a given set of outcome constraints (real world) ... but solve a problem and try to guess what the interviewer's particular fetishes are and try to hit those.

Do you get the impression the interviewer has a fetish for OO solutions? You better angle on that or your going to get the ding. Do they want to see you pull out a cool data structure like a min heap? You better realize that right away and get there. Generally speaking, you can "win" in these types of interviews if you angle for big-O optimality (I've found).

I've interviewed this way, myself. But over time -- with experience -- I've found that this doesn't really even correlate that well with outcome. I've interviewed and worked with people that absolutely nail these whiteboard problems but when you get them on the job, and with real world curveballs thrown at them, they freeze - either due to some issue of work ethic, psychological issue/fear, or in the absence of grades they just can't seem to make a move.

What I've found is interviewing with just a Q & A style response and digging into the work they've done and finding out how much ownership they have taken in their past work, how much curiosity they show (for any given piece of tech, just ask and see how well they know it and can even teach it to you if you don't know it), how much drive they have to get things not just done, but get them done well/solidly. Then, pretty quickly I can tell you if we've got a good hire.

Conversely I've made hires where the candidate did not do so well in the whiteboard but proceeded to excel in the professional context.

Think about this: if you have a person that is curious and drives to build the thing well... imagine the day (and these days come but not so often) that they encounter some need for a difficult algorithm. What is this conscientious person going to do? They're not going wing it and write a bad solution. They are going to go do their due diligence, their research, consult with their team members, and they'll get the right solution. So, say they are not so great with coming up with a novel algo on their own. One, that's a skill they can develop, but two -- it's a skill that's only needed in a few people on your team and then you'll overcome those steps at the intermittent times that they come through.

Now of course this ^ way of interviewing requires a personal skillset in one's self -- that is, you have to have a good work ethic, be intensely curious, very responsible, etc in order to recognize these same qualities in the candidate.

Unfortunately, I've found the industry dominates with "smart people" but who tend toward what I call a 'philistinic' position. They lean way too much on their natural intelligence and use that as an excuse to not really grow their skillset. This is what some people call 'expert beginners' and there are far more of these, ime, than truly skilled practitioners.

So -- back to the ageism thing. I think it's less ageism and more an overall industry deficit. If we understood our work better and could produce more masters/professionals then I'd think we'd see an increased valuing of experience.

Blaming it on ageism I think only deters us from getting there.

Why are you still applying to entry level dev roles at 42? Do you have a portfolio?

I'm around this age and haven't applied for entry-level dev roles since I was truly an entry level candidate.

I've endured whiteboard sessions for every role I've gone for.

shouldn’t you have built up a body of work that conveys your level of knowledge so you dont have to endure these assessments?

It was not an entry level. There was no designation to the role actually.

But what does that question mean anyway? Say I've been working in java stack for 10 years but for whatever reason I want to move to js/frontend. What else is there than entry level to begin with? Tech careers (at least honest ones) are rarely linear and there are hundreds of reasons for that.

you're being subjected to these entry level assessments because you haven't proved that you can apply your software design skills across different paradigms - build a portfolio or maintain a github

No, that's not why. Some companies just do this for every engineering hire, even those being hired for senior or specialized roles. I came in to my current job with two and a half decades of experience across multiple specialties, nearly a decade on a project they relied on and for which I was an upstream maintainer ... and I still got the whiteboard. Maybe there are some exceptions, but I have yet to meet one. Even characterizing it as an "entry level assessment" already misses the mark. It's more about avoiding bias (or the appearance of it) by trying to apply a uniform process and standard across the board.

Some might say you shouldn't want to work at those companies if you don't like their hiring process, as though there's nothing to any company but the hiring process. It's like saying you shouldn't join the military if you don't like basic training. Nobody likes basic training. People join organizations despite those things, and I for one am not going to judge them or assume their reasons are silly just because I might decide differently.

If it was trivial you would have completed the exercises, no?

Truth is you're using age and "years coded" as a cover for competency. Hit the books, refresh your knowledge stack. There's no shame in improving.

I'm 40. As it happens I like Haskell and I've spent some time with it, and I expect I could get through most recursion interview tests, so this is not sour grapes on my part, but: I really can see just how easily my career and hobbies could have turned so I would be a good developer that should pass interviews, but stumble and fall when trying to write a recursive version of some algorithm.

(I'd add that in practice, almost nobody ever directly writes a recursive version of anything anymore. You should generally be using combinators like map and filter and the crazier stuff Haskell provides rather than directly writing recursion schemes by hand. It does happen in Haskell for a couple of specific cases, but even the ones I can think of are exceptional cases for dealing with certain optimizer corner cases, not places where it was absolutely necessary to write direct recursive code. Even for a pure-FP job I wouldn't hammer on it in an interview; I'd want to very rapidly move up the stack to more interesting and relevant questions in our precious interview time. I suppose it's an integration testing approach to interviews rather than unit testing; I'd rather find something where recursion is used in passing to ensure that you've got it than sit there and pound on that specifically. It's not a good interview question unless that's all your interviewee can handle.)

The whiteboard threads are always interesting to me because with more than ten years experience in software development in enterprise and startups now, I've never had to do a whiteboard interview.

Are they common outside the big six names? I.e., outside of Facebook, Google, Apple, Microsoft, Amazon, and Netflix? I wonder what the actual percentage of "Needed to pass a whiteboard-based Q&A to get a salaried position" is.

From my viewpoint, having never run in to them, they seem like something that was much more popular in the past, but now rarely used or only used at the aforementioned big six companies.

In the 2019 Stack Overflow developer survey, 27.8% of respondents said they encountered whiteboarding as part of their last successful interview process that resulted in a job offer.

https://insights.stackoverflow.com/survey/2019#work-_-interv...

Oh cool, thanks for the link! I should have thought to look at SO, as I generally read those survey results, but it didn't occur to me to look for this question there. 28% is a bit higher than I would have guessed even to that answer.

Reply on news.ycombinator.com