Many people who interview feel like random people off the street. You really can't tell if the resume's completely bullshit until you ask them to sit down and implement fizz-buzz.
> Focusing so heavily on computer science trivia questions favor those who recently went to college, since those tidbits are so rarely needed at the drop of a hat in industry those neurons wither away with more time away from academia. Older developers know you can just look it up.
Is this still a common practice? Neither Facebook, Google, nor Amazon trains its interviewers to ask bullshit trivia questions to non-intern candidates (I don't know if they train them to ask, or not ask those questions to intern candidates.) I mean, it's entirely possible that particular interviewers at those companies do, but I have skimmed through many, many interview transcripts. None of them focused on bullshit trivia.
(Unless you feel that 'Is it possible to have a memory leak in a language like Java or C#?' is bullshit trivia. I've had people who have spent five years programming in those languages answer, with full conviction, 'No'. After some more prodding, they sometimes say yes, if there was a bug in the garbage collector.)
At this point, this feels like a meme that has been ten years out of date (Because all it takes is one person having a bad interview experience to revive it.)
So even if there’s not explicit bias against older devs there is implicit bias by favoring quick whiteboard speed (memorization/practice) over the practiced thoughtfulness of older devs. And a one-off interview focused heavily on algos can sink anyone. It only takes one.
This isn’t limited to FB. The $Elite companies I got offers from are the ones where I lucked through that one tricky interview by knowing it offhand.
I worry as I get older, even as I become a stronger developer, I will become less and less able to marathon through these interviews. No wonder so many older devs switch to management.
Yet, when blasting interviews, I have found that people tend to conflate the two.
I agree that 60 minutes on a whiteboard or a laptop is not the best way to ask someone to solve a coding problem. Homework is worse, though. Maybe 90 minutes is a better time slot.
At least in-person, both parties invest about as much time into the interview.
I've identified some common elements, but each of the companies mixed and matched them in different ways and degrees. The techniques used were:
- timed online test (e.g. HackerRank or Codility), reviewed later by the team
- online, real-time coding during the phone screen (e.g. HackerRank or CollabEdit)
- take-home project with a deadline (usually up to 2 weeks), reviewed later by the team
- phone, video-conference or on-site discussion about employment history and experience
- phone, video-conference or on-site discussion about technical problems
- on-site whiteboard coding
- on-site coding on company-provided box
- on-site coding on candidate's own box
- coffee-shop conversation about behavioral topics
The topics for technical discussions were:
- algorithms, data structures and complexity (big-O notation, trees, hash tables, lists, circular buffers, breadth-first and depth-first traversal, binary search, recursion)
- scalability (caching, load-balancing, sharding)
- concurrency (locks, conditional variables, contention, memory fences)
- mathematics (vectors and matrices, linear algebra, computational geometry, combinatorics and probability)
- low-level concepts (manual memory management, cache locality, specifics of garbage collection, VMTs in C++)
- object-oriented design (inheritance, polymorphism, fragile base class, composition over inheritance)
- API design (specifying constraints, changing API based on requirement changes, paging results, increasing or decreasing operation granularity)
Now, I know that this is just 8 companies. I know that this is a drop in the ocean. I know that the plural of "anecdote" is not "data". But over and over again, I've seen the same claim on HN: our industry focuses too much on computer science "trivia" questions. For an audience that usually requires quality, sourced data to support arguments, we seem to be awfully quick to draw generalized conclusions about this specific topic.
- Fraudster gets hired and cannot do the job. They get let go.
- Fraudster gets hired and can do the job. No harm.
- Fraudster gets hired and can kind of do the job. They get placed on a performance improvement plan, and you train them until they either can or cannot do the job.
Think of this from the perspective of both parties. I think the risk of this type of bad actor is wildly overstated.
Focusing so heavily on computer science trivia questions favor those who recently went to college, since those tidbits are so rarely needed at the drop of a hat in industry those neurons wither away with more time away from academia. Older developers know you can just look it up.
Take home quizzes and side projects require significant time investments. People tend to have less free time as they get older due to family obligations, changing priorities, and so on. People directly out of college likely have less of these external time pressures and would have less of a problem solving your so-clever little project that only takes 20 hours.
Until we, as an industry, get over the lie that hiring must be incredibly accurate and therefore favor the so-called "false negative", we won't get rid of this kind of discrimination and we'll continue to harm people simply because they're older; not to mention losing out on potential co-workers with a plethora of knowledge and experience.
It's bizarre to me that ageism exists. Other forms of discrimination can be traced to othering someone because they are dissimilar to you. Every single human will become an older person one day, barring early death. Perpetuating this cycle is self defeating in the end.