Anyone else thinks that Whiteboard interview is just covered ageism?

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.

&quot;It&#x27;s the second time in a few months I&#x27;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.&quot;<p>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.<p>That is, if I fail it, it&#x27;s not because I am older, it&#x27;s because I don&#x27;t know stuff fresh grads know.<p>IT is full of grinding pretty meaningless stuff (especially at lower levels), as much as we romanticize it.

If you&#x27;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.<p>Being able to &quot;get the recursive solution fast enough&quot;? 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.<p>In the general case, I&#x27;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&#x27;t agree with the assumption that some candidates are &quot;above&quot; these interviews.<p>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.<p>Of course, just because the interview format is not fundamentally flawed doesn&#x27;t mean that plenty of companies don&#x27;t mess up implementing it in practice...<p>Then again, your PSes suggest you don&#x27;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.<p>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&#x27;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&#x27;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&#x27;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.<p>The main downside to a work sample is that a lot of people will say they simply don&#x27;t have the time to do it. That&#x27;s fine, you&#x27;ll lose some people, but you&#x27;ll also have people applying who really want to work for the company. From there, you&#x27;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&#x27;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 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&#x27;t have to be perfect. Yeah I think they may come up with stupid excuses basically to not hire you.<p>Honestly, interviews go two ways: you figure out if you <i>really</i> want to work there, and they do as well. If they don&#x27;t want you, assume it&#x27;s for the best, you would of had to deal with worse: coworkers who hate your personality or have a toxic personality.

I was not prepared when I had my last interview like this, but if I ever go interviewing again I&#x27;ll make sure to have my own algorithmic problem at hand (to which I&#x27;d know by heart all the tricks and improvements).<p>Then at the end of the interview I&#x27;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&#x27;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?<p>It sometimes seems like these interviews are d<i></i>k measuring contests between the two parties.

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.<p>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 &#x27;repair&#x27; on a miniature car made of lego bricks.<p>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.

I don&#x27;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.<p>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&#x27;s fair game in an interview setting.

<i>Anyone else thinks that Whiteboard interview is just covered ageism?</i><p>It really depends on who is interviewing you. It can be. Even the Google Hangouts, screen-sharing one can be. I&#x27;ve definitely had that sense from one interview.<p><i>Given that I am 42 yrs old and been at this line of work for 14 yrs now</i><p>I&#x27;m a bit older than you, and have just a bit more experience, so I think I know where you are coming from.<p><i>Whiteboarding simply tests for skills that are not needed nor exercised once you&#x27;re out of uni.</i><p>Again, this greatly depends on who is applying the technique and how it is being applied. It <i>can</i> 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.<p>That said, I&#x27;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&#x27;t expect to get good outcomes by just giving interviewers a few seminars, then telling them to go at it. You&#x27;ll get the same level of interviewing as the level of teaching you get by doing the same thing to TA&#x27;s with no experience.<p>The biggest single issue I&#x27;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&#x27;s mind. The expectations are higher in regards to system design and resume questions. That seems to be fair imo.<p>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&#x27;t rely on whiteboarding or has a lower bar in general. That&#x27;s to say investing in whiteboard practice has little downside and has an acceptable time&#x2F;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.

I think it&#x27;s a bit in between. FWIW, at 54 I&#x27;ve never failed a whiteboard interview, including at my current FAANG employer, so this is most certainly not sour grapes.<p>While not <i>deliberately</i> 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 <i>particular</i> 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 &quot;graded&quot; even if the candidate solves the problem quickly and well.<p>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 &quot;instinct&quot; 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.<p>As I said, I don&#x27;t think any of this <i>intentionally</i> 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&#x27;t dance that particular dance well enough in that moment and got rejected. That&#x27;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:<p>&gt; Whiteboarding simply tests for skills that are not needed nor exercised once you&#x27;re out of uni.<p>But I don&#x27;t know if &quot;whiteboarding skills&quot; are any more useful <i>during</i> college either. Also, I always thought explanations were the crucial part of the interview, and I think technical explanation is an important skill.<p>That said, it may be a flawed practice. I&#x27;m open to arguments to that effect. But so is everything else[1]. I&#x27;m interested to hear some thoughts.<p>[1] <a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Goodhart&#x27;s_law" rel="nofollow">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Goodhart&#x27;s_law</a>

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 &quot;culture fit&quot; interviews imo. How people don&#x27;t think they just create massive bias is amazing to me.

I do not think white boarding is a cover for ageism.<p>I think a group collaborative exercise where you&#x27;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.<p>I think testing for this skill is a really good idea.<p>I think that doing this in a way that&#x27;s equitable and emotionally supportive to the candidate takes thoughtfulness and effort, and not every company&#x2F;person in this process does this well.<p>I also think there&#x27;s a great number of people who turn this concept in to a boogeyman to rationalize their interpersonal or technical ineffectiveness.<p>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&#x27;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&#x2F;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&#x27;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&#x27;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&#x27;s not what whiteboards are for.

I&#x27;ve been on both sides of the whiteboard interview (candidate and interviewer), and I&#x27;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&#x27;m still with the same company).<p>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 &quot;right&quot; answer. At the same time I&#x27;m asking questions about their previous work, specifically looking for concrete examples of how they balance the needs of different stakeholders in a project.<p>The worst whiteboard interviews look to evaluate knowledge of a specific algorithm, and don&#x27;t provide help when the candidate is stuck. The very worst is just a pretext to cover up the interviewers biases.<p>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&#x27;ve spent your life accumulating.

i wouldn&#x27;t take it too personally nor read too much into it. the whiteboard interview wants to extract signal ranging from &quot;make sure this person isn&#x27;t a complete n00b&#x2F;fraud&quot; to really relevant problems that should probably be eminently doable, depending on role. but due to a variety of factors it doesn&#x27;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&#x27;re shy. or lack of familiar tooling, or whatever.<p>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&#x27;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&#x27;t think it&#x27;s time to reach for malice after 2 failed attempts at something i&#x27;m inferring you haven&#x27;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&#x27;s a basic truth about being a knowledge worker that most people don&#x27;t think about. This truth holds for young, old, programmer and non-programmer alike.<p>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&#x27;s going to catch up with you.<p>This is one key reason programmers tend to move to other careers or into management after 10+ years: it&#x27;s a lot of work to continuously learn. And worse than that, it&#x27;s uncomfortable and makes you feel dumb when you know you&#x27;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.<p>For developers this means learning new languages, techniques, technologies, methodologies. If we accept that this learning is going to be happening, then it&#x27;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.<p>Most engineers actually don&#x27;t do this, and just stick with what they&#x27;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.<p>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&#x27;re not part of the daily grind. The same goes for algorithms and data structures.<p>Studying these things also sends a signal to your interviewer: you&#x27;re willing to go figure it out even when it&#x27;s not fun and not convenient. As a hiring manager, I like that. And we can debate whether it&#x27;s a good thing, but it is what the situation is at many places. Plus, it&#x27;s fun to study a lot of it, so it&#x27;s a good option to get on the learning.

&gt; Whiteboarding simply tests for skills that are not needed nor exercised once you&#x27;re out of uni.<p>In today&#x27;s tech industry, these algorithm questions is now used as an effort to trip up candidates and to always try to &quot;See how you think&quot; in an unrealistic scenario. The questions I&#x27;ve been given and have seen are mostly irrelevant and are always done for us in the libraries I use at work.<p>I had interviewed at one startup in the UK who asked me a algorithm question that they admitted that they don&#x27;t use and their excuse is the same: &quot;To see how you think.&quot; Not only this doesn&#x27;t make sense if one has already seen this problem, but the fact that they don&#x27;t use it makes you wonder the real reason why they are doing this.<p>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.<p>&gt; Things like improper syntax and not getting the damned recursive solution fast enough.<p>A problem statement like that is like: `Design and implement the optimal solution to this &#x27;problem&#x27; in X language in less than 15 minutes.`<p>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.<p>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 &#x27;broken&#x27; that interviewing at FAANG companies is an entire industry itself.<p>For them, whiteboarding like this is essentially trying to find a silver needle in the sky.

I&#x27;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&#x27;ve set up many systems with a few different stacks and have thought about what the pieces are for.

It depends. If you&#x27;re talking about whiteboarding code, I only have to do that once a year or so, usually because I&#x27;m in a meeting and want to demonstrate what I mean and code is easier. If you&#x27;re talking about whiteboarding a design, I do that much more frequently. I prefer a pair programming exercise in this case, but I&#x27;ve reverted to whiteboard in cases where there were technical issues. It&#x27;s not my favorite but neither is trying to do it in a text editor without support.<p>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&#x27;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&#x27;t think it should be all about coding riddles, but I also don&#x27;t think you should be surprised by them.<p>As a developer, I&#x27;ve always used whiteboarding as a way to communicate ideas, architecture, etc. There have been whiteboards in every office of every company I&#x27;ve worked at.<p>I&#x27;d say somewhere around 75% of all interviews I&#x27;ve had for positions at other companies have included whiteboarding.

I don’t see ageism in it.<p>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.<p>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.<p>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&#x27;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&#x27;t assume these interviews favor young people, it certainly didn&#x27;t feel like that to me. I think most places just want to reject most people, because it&#x27;s easier to justify rejecting someone good than accepting someone bad.

I&#x27;m going through this right now, with 26 years of professional experience and an undergrad degree in CompSci.<p>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).<p>I don&#x27;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&#x2F;unrealistic laundry-list of technologies) rather than focusing on the candidate&#x27;s ability to learn, think, and communicate.<p>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&#x27;t have enough experiences in different situations to know how to make these decisions (with an reasoning to back them up).<p>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&#x27;t ascended into management, they have little road left to travel.<p>What many of us older devs didn&#x27;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.<p>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.

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&#x27;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.<p>I think it&#x27;s great that you have such high self-esteem and aren&#x27;t doubting yourself just because some other people don&#x27;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.<p>Edit: please note that I have said &quot;if we stipulate,&quot; not &quot;if we accept as an a priori truth&quot; that whiteboard interviews are good. It&#x27;s simply a rhetorical device for evaluating whether or not your whiteboard interview is at risk for evaluator bias.

I&#x27;m a bit older than you, and am really wary and tired of lame interview stuff too.

IMHO two samples isn&#x27;t quite enough to form useful data. It&#x27;s a rough trend, certainly, but more tests are needed to be sure.<p>Could be you dodged a bullet. Could be the interviewers were hungry. Could be they didn&#x27;t like your clothes.<p>42 is not that old.

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&#x27;t mean the problem doesn&#x27;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.

Literally only college grads are marginally good at that. Nobody likes whiteboard interviews and has to brush up. Everyone knows tech interviews are inefficient.<p>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.<p>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”<p>What happened?<p>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&#x27;t ageism, just people with lots of experience who don&#x27;t want to admit that they weren&#x27;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 &quot;Good Old days&quot; effect, but that doesn&#x27;t mean that it is true.<p>If your argument is that you barely passed those interviews a decade ago and it takes too much energy to practice again, then I&#x27;ll say it is a feature. The more we discourage less capable people from joining the better, don&#x27;t you agree?<p>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&#x27;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&#x27;t have seen it before).

You’re giving zero context here aside from “there was a whiteboard and it was horrible.”<p>What happened?<p>Age has nothing to do with it - if you can’t communicate.

I&#x27;m a bit older than OP - just recently turned 46. I&#x27;ve been a software engineer (professionally) since I was 18 years old when I was first hired by a small mom-n-pop shop.<p>One would think I could simply plop my resume down, do an in-person interview, show a bit of code I&#x27;ve written in the past, plus my github, and that&#x27;d be enough. Alas, it isn&#x27;t.<p>I&#x27;ve had good interviews that used a whiteboard, and bad ones that did. Overall, though, I detest whiteboard &quot;challenges&quot; 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).<p>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 &quot;pseudocode&quot; - just to get the whole &quot;wrong syntax or keyword&quot; issue out of the way. I&#x27;ve never had a turn-down from this ask. I liked that they wanted me to show I could do fizzbuzz &quot;from memory&quot; because it would show I wasn&#x27;t copying&#x2F;pasting from that github repo of &quot;all versions of fizzbuzz&quot;, 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.<p>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.<p>I didn&#x27;t get an offer on that job - and to this day, I am glad I didn&#x27;t. While the company and the office location all had a &quot;hip and upcoming&quot; 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.<p>It was interesting to note OP&#x27;s idea of it being a potential age filter; I&#x27;m not sure I agree with that fully. I wonder if it isn&#x27;t meant as more of a filter for those who didn&#x27;t go to school to learn the craft. I mean, I&#x27;ve probably done at least once certain things being asked for - but if they couch them in terms that are &quot;defined in the literature&quot; (this also covers asking about &quot;patterns&quot;) - I&#x27;ll most likely be lost. Because I don&#x27;t know all of that terminology, or what it applies to. I&#x27;ve been coding in some fashion or another since I was 10 years old, but I haven&#x27;t gone to school for it (aside from a couple of community college classes for C&#x2F;C++ - algorithms and&#x2F;or patterns were not discussed).<p>If so, it&#x27;s kinda on them because they didn&#x27;t read my resume carefully; I note up-front that I don&#x27;t have that education, that I am a self-learner, and that I don&#x27;t like to be a &quot;specialist&quot; in a particular language or framework-du-jour. Rather, I&#x27;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&#x27;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&#x2F;10 times you don&#x27;t need the latest language or framework for most problems. It&#x27;s more knowing when you do, rather than just picking one and sticking with it forever (ie - I don&#x27;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&#x2F;framework it was implemented in.<p>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&#x2F;need references, but even those that do, never follow up on them. I am not sure why this doesn&#x27;t happen - maybe it&#x27;s just a simple constraint of time vs number of resumes&#x2F;interviews? Or maybe it&#x27;s due to past candidates gaming the system, and making it an unreliable metric to the process?

This is an interesting take. I&#x27;m in my forties, will&#x2F;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...<p>Still, the ageism take is interesting but I don&#x27;t like falling back to that kind of thinking b&#x2F;c it is counterproductive.<p>The evolution of my own performance in whiteboard interviews (and anecdotally what I&#x27;ve heard from other experienced developers) is interesting:<p>I don&#x27;t feel like it is directly due to age or cognitive change&#x2F;decline, but more to do with mastery&#x2F;experience.<p>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&#x2F;learning and find that prioritization and contextual understanding is far more important to superior execution.<p>More explanation...<p>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 <i>outcome</i> constraints (real world) ... but solve a problem and try to guess what the interviewer&#x27;s particular fetishes are and try to hit those.<p>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 &quot;win&quot; in these types of interviews if you angle for big-O optimality (I&#x27;ve found).<p>I&#x27;ve interviewed this way, myself. But over time -- with experience -- I&#x27;ve found that this doesn&#x27;t really even correlate that well with outcome. I&#x27;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&#x2F;fear, or in the absence of <i>grades</i> they just can&#x27;t seem to make a move.<p>What I&#x27;ve found is interviewing with just a Q &amp; A style response and digging into the work they&#x27;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&#x27;t know it), how much drive they have to get things not just done, but get them done well&#x2F;solidly. Then, pretty quickly I can tell you if we&#x27;ve got a good hire.<p>Conversely I&#x27;ve made hires where the candidate did not do so well in the whiteboard but proceeded to excel in the professional context.<p>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&#x27;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&#x27;ll get the right solution. So, say they are not so great with coming up with a novel algo on their own. One, that&#x27;s a skill they can develop, but two -- it&#x27;s a skill that&#x27;s only needed in a few people on your team and then you&#x27;ll overcome those steps at the intermittent times that they come through.<p>Now of course this ^ way of interviewing requires a personal skillset in one&#x27;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.<p>Unfortunately, I&#x27;ve found the industry dominates with &quot;smart people&quot; but who tend toward what I call a &#x27;philistinic&#x27; 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 &#x27;expert beginners&#x27; and there are far more of these, ime, than truly skilled practitioners.<p>So -- back to the ageism thing. I think it&#x27;s less ageism and more an overall industry deficit. If we understood our work better and could produce more masters&#x2F;professionals then I&#x27;d think we&#x27;d see an increased valuing of experience.<p>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?

If it was trivial you would have completed the exercises, no?<p>Truth is you&#x27;re using age and &quot;years coded&quot; as a cover for competency. Hit the books, refresh your knowledge stack. There&#x27;s no shame in improving.

The whiteboard threads are always interesting to me because with more than ten years experience in software development in enterprise and startups now, I&#x27;ve never had to do a whiteboard interview.<p>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 &quot;Needed to pass a whiteboard-based Q&amp;A to get a salaried position&quot; is.<p>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.