Anyone else thinks that Whiteboard interview is just covered ageism?
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
144 comments
[ 3.1 ms ] story [ 205 ms ] threadHonestly, 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.
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 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 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.
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.
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.
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.
Also hiring people who are willing to work for less money is not age discrimination.
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.
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.
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.
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.
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.
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.
> 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?
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.
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.
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.
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?
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.
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 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.
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.
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.
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.
There are all loads of websites and books that can get you back up to speed with that if you need it.
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.
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.
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.
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.
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.
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.
You're still looking at this as a matter of how well you can play the game, not whether it's actually a fair game anyone should have to play. That still doesn't answer the OP's question, and I'm not interested in a strategy discussion right now. I've had plenty of those. If you can't bring yourself to think or talk about social problems as they might affect others, then we have no common ground or reason to engage with one another.
It isn’t any more discriminatory that a new college graduate has recently learned skills that an older developer will have to learn on his own than it is that I had to learn C# or Java on my own to be competitive since neither existed when I graduated from college and a new college grad could learn those languages in school.
We all signed up for field that requires constant learning and evolving with the landscape. I’ve been programming since 1986 in 65C02 assembly language in 6th grade. I’ve known exactly what I was signing up for the day I stepped foot on a college campus in 1992.
If someone has to put forth a little effort to qualify for a job that puts you well into the top decile of income - it’s not a bad tradeoff.
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).
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.
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.
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.
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.
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.
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'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.)
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.
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.
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.
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
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.
See - I've even gone through that. I'm that diligent.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
That's what culture fit means. It's a more polite way of saying "Not an Asshole"
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.
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?
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.
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.
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.
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.
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.
I've endured whiteboard sessions for every role I've gone for.
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.
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.
What happened?
Maybe it’s you.
> 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
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.
https://insights.stackoverflow.com/survey/2019#work-_-interv...
What happened?
Age has nothing to do with it - if you can’t communicate.
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 wh...
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.