Hacker News new | ask | show | jobs
by soham 3477 days ago
Elephant in the room, IMHO, is the technical interview process.

In software engineering roles at big/desirable/fast-growing companies, the interview process favors faster (by definition, younger) minds. Both young and old are put thru the same/similar coding interviews at many of these places, and often faster coders are younger, and get the job.

You can't fix ageism without fixing the interview process. Being jovial, healthy, nice and culturally sensitive are necessary and useful things to keep your job after you join, but the gatekeeping itself is biased on the other side, which reduces the intake to a trickle.

6 comments

36 year old checking in. If there is any perceivable gap in speed between a younger and older software engineer, that gap can EASILY be made up with experience. After over 10 years in the industry I can honestly say interview questions aren't that original. If anything I have a huge advantage because I've heard all of them before: Answer a question that demonstrates you understand polymorphism + Algorithms 101 And that covers most of the questions I see right there. Yes it's insanely stupid to interview like that, no I don't think my age does now or ever will put me at a big disadvantage.

In my experience older people get cut out based on not being "a good cultural fit". This has been discussed ad finem on Hacker News because "cultural fit" leads to all kinds of discrimination: racial, gender, age, etc.

Every job I've had we put a person through a series of interviews, then we have a group meeting and we vote. There is no quantifiable evidence that this person actually interviewed the best. It comes down to how people feel in a room. That is the issue, not the speed at which a person can give answers. I've seen people voted down based on all kinds of illegitimate reasons and with age I think it came down to fear in some cases. A lot of software teams don't want to hire the best person they can find. They want to hire someone who is pretty OK, but will also make them look good. Yes, sometimes people don't get the job because they are too good. Am I going to hire someone who makes me look like an under-performer, or could get promoted to before me? Bingo, bad cultural fit.

the interview process favors faster (by definition, younger) minds

Algo-on-the-whiteboard interviews favour people who have recently been cramming for their final-year CS exams - by SHEER COINCIDENCE they happen to be in their early 20s...

I would even say they favor people who have been cramming algo-on-the-whiteboard type of questions. I mean, there are several businesses built around this (CtCI, leetcode, ...)

I know some North American universities have adapted to the practice and are now preparing students, but I assume this is relatively new. My algo and DS classes weren't about cramming at all.

Now to be fair, reasonable companies will focus on higher-level, systems design and architecture type of questions when interviewing seasoned engineers. Or at least, they really should.

Since everyone knows what they're getting into with a tech interview, I don't see why it's such a bad metric. Many companies purposefully give you a rubric/criteria to study. It's a good way of measuring whether a candidate can take the time to learn/prepare a specific set of knowledge, and then work through problems in a way that includes the interviewer (ie. other devs if hired) in the steps to solve the problem.
> It's a good way of measuring whether a candidate can take the time to learn/prepare a specific set of knowledge

And how isn't that a terrible metric? Most of my current coworkers would fail as they simply don't have the time.

> Since everyone knows what they're getting into with a tech interview, I don't see why it's such a bad metric. Many companies purposefully give you a rubric/criteria to study.

It's often so broad that to really cover everything that might come up you've got to have time to make the studying a part-time job.

And even then you might get hit with one of those "you almost have to have seen the trick before" questions, like detecting a cycle in a broken linked-list with O(1) memory.

Why interview in a way that's unrepresentative of the actual work?

The only reason is that you want to build an environment where the work is secondary, such as wanting to hire a bunch of bros to go drinking with and help you spend all that sweet VC cash...

Exactly, it's the choice of evaluation criteria.

Meanwhile, experienced developers have their brains tuned towards on-the-job skills that are harder to cram (like an instinct for edge-cases) while "shelving" the stuff that you don't need.

I'm not sure it's because the interview favors faster minds. When you're 25, and good at what you're doing, there is a good chance you simply don't see what a 40 years old have to offer. Never mind that the day they turn 40 themself, they'll be able to brig far more value to the table because they have 15 years of additional experience.

If there is noone with 20 years of dev experience within the company, there is noone to speak up for this, and the cycle continues.

Why do you think often faster coders are younger? With many more tricks up their sleeves, a more experienced coder will be faster. Or are you saying compared to literally older people, but not experienced?
I don't think the assertion has any basis in objective data in the first place but is based on a personal feeling. I don't see the value of trying to discuss reasons for something that only "exists" based on spurious subjective personal claims?
Young coders can code that 10,000 line bad idea they had really fast, while older ones can recognize that a problem isn't new and avoid the 10,000 lines altogether.
Cognitively, people do slow down after 21 or so. It is likely not to be a linear process, but I'm sure a quick google of research will find this. It is not, as suggested by the other comment, spurious feeling, but a well-known cognitive fact about humans. And experience in eal things doens't help with random tests, expecially if you're 20 more years away from your CS finals.

Whether this translates into a perceptible disadvantage in code tests is less likely to have been tested, but it is given what we know, and given other arguments above, quite possible and indeed likely.

At least one study suggests that unlike athletic abilities that do peak at around 20, fluid intelligence is more complex and may peak all the way up to 50 years. http://m.pss.sagepub.com/content/26/4/433
Technical interviews don't necessarily favor faster coders. I have been on both sides of technical interviews and what counts most is that an applicant asks the right questions and chooses the right approach.

What you're definitely not looking for is a candidate that hacks some solution together quickly but with badly structured code, makes a lot of unconfirmed assumptions and doesn't listen to advice.

> technical interview process

Even before that is the technical screening process. If the company has standardized on Angular 2, your experience with Dojo, Ext-JS, jQuery and even Angular 1 is considered irrelevant by the screeners - you may as well have experience in medieval basket weaving; they won't even call you. If the company has standardized on Groovy, your experience with Java is equally irrelevant. If the company has standardized on MySQL, your experience with Oracle is irrelevant. If the company has standardized on Linux, your experience with Solaris is irrelevant. And on and on it goes...

There's a perception (which I've already seen repeated 10 times in this thread, and I'm only halfway through it) that the "new thing" always completely replaces and invalidates the old thing. But that's almost never the case. Angular uses jQuery. jQuery uses Javascript. Javascript uses the DOM. Groovy uses Java. Hibernate uses JDBC. AJAX uses HTTP. HTTP uses TCP/IP. They all use the OS. And when X uses Y, Y can go wrong in ways you didn't expect if you just assumed that Y became meaningless when X came along.

So we have this environment where the hiring managers are shooting themselves in the foot by looking for style over substance and anybody who tries to bring it up is dismissed as a dinosaur with a case of sour grapes.