Work at older, non-tech companies that have tech departments. Almost every single one of my jobs has matched this pattern, and none of them included a coding exercise as part of the interview process.
Silicon Valley and its satellites seem to disproportionately favor code interviews compared to the rest of the US market, for some ungodly reason.
> Silicon Valley and its satellites seem to disproportionately favor code interviews compared to the rest of the US market, for some ungodly reason.
I work at a well known SV tech company with about 3k ppl and we got over 50,000 job applications last year. Code interviews suck, but they're a scalable way to assess skill with minimal bias.
There could be an argument made that most code interviews have a bias twords younger less experienced developers. They are the ones that take the time and study these questions. Years of experience probably won't help since the questions don't represent day to day problems most developers are solving.
I interview at FAANG and we do take this into account by holding pretty much anyone over ~2 years of experience to the same standard with respect to leetcode questions.
A fresh grad is expect to be able to solve ~medium problems.
Someone with ~2 years of experience is expected to be able to solve ~hard problems.
Someone with 10 or 20 years of experience is still only expected to be able to solve ~hard problems.
The standards for a more experienced candidate are of course higher for other attributes: Leadership skills, communication skills, etc.
Would you suggest someone with 10-20 years of experience to practice and learn how to solve leetcode problems? Or just expect them to be able to solve them without any prior exposure?
And if you would suggest they learn them what would that person be gaining that they lacked before?
"Skill" is probably one of the least valuable metrics of a given hire's performance over time for an employer.
Yes, being able to effectively select for the people most likely to develop a competitive non-extant algorithm is an important metric for certain employers that skill tests will assist with. However, it's as niche to general society as academic studies are.
This is not to say that it's unworthy of practice or attention. In some cases, it's absolutely justified.
What I'm advocating for, however, is skewed towards the broad middle of employment cases - people who are competent, able to solve most day-to-day problems, and not adverse to new practices.
In most cases, people aren't looking to advance the knowledge of a particular field of study. They're just looking to solve problems for their day job while earning appropriate compensation. The employer gets a satisfactory advancement of their capabilities, and the employee gets to enjoy a quality of life they're used to.
The "broad middle" is much messier, but also easier to filter for. As a hiring manager, I would look for people that are A) not obvious assholes, and B) likely to improve my team's performance in some measurable way.
In other words... Company X, which lives and dies by having the absolute latest technology available to humanity, may well need to use code interviews to even establish a baseline performance metric. Company Y, which is just interested in appreciably improving its market share versus a wide cohort, is probably better served by "softer" hiring metrics.
One possible a consideration would be that "softer" hiring metrics breed mediocrity and complacency in the long run. Should the company in question to pivot into a more, let's say, intellectually rigorous direction, how should they handle the predicament they've put themselves in without the end result being bankruptcy, mass layoffs, bad PR, or some combination of the three?
the fact that SV companies are getting 50,000 applicants while other more or less critical sectors struggle to field any talent at all points to a (the?) deeper problem at the root of the leetcode fiasco
Older, non-tech company with a tech department employee here. And uh, yeah, we do code exercises with candidates. Nothing ridiculous, we just put a basic, relatively straightforward problem in front of the candidate (two notches above fizzbuzz) and ask them to solve it, or at least talk us through how they might solve it.
We've had a problem with candidates who seem impressive on paper and during the first phase of the interview, and then can't solve this exercise without being seen to glance at Google or SO results on camera -- or worse, being caught copying a worked example directly off the web!
There are plenty of people who can talk a good talk about their technology experience but can't write a line of code to save their lives! Entire majors at universities are devoted to this; when I was in college, all the people who couldn't cut it in CS because math, fell back to MIS -- Management Information Systems -- whose courses had big colorful textbooks I call "Richard Scarry books" because they're packed full of busy-looking illustrations. MIS helps you learn about technology in a business context, but prepares you very little for actually doing technology and building the systems with it. The coding exercise helps screen out the people who can't actually do what's needed of a developer.
I guess people reach for leetcode because it's easy, but it misses the point of the coding exercise. The point is to screen out people who can't program at all, not to select for the programming equivalent of NES speedrunners. So it needs to be set at a very low bar and administered by forgiving interviewers.
> Silicon Valley and its satellites seem to disproportionately favor code interviews compared to the rest of the US market, for some ungodly reason.
It's all the money that they're making compared to everyone else. Even in a crash like we're seeing now, they have extremely high revenue per employee.
Tech companies favor deeper tech skills greater than non-tech companies do, is what I'm reading, and it does not sound too surprising.
You are also less likely to deal with the "leetcode" subject matter (e.g. design and analysis of algorithms) at a non-tech company, so if you don't want to deal with that, applying at a non-tech company is a good idea. Does not mean that a job at a tech company won't be like that, though. They have CRUD SaaS apps, too...
You can't have your cake and eat it, too. If you want to get paid as a developer who has to design algorithms as part of their job, you should know how to design algorithms.
Doesn't mean that pay grade is fully correlated with skill, of course. There are other industries that pay more and don't require anything like that.
Most of us are not designing algorithms, most of the time, or any of the time
Many engineers are just filling seats in places that are just in the business of sucking up talent from the market instead of having a bunch of entreprenuers running around
Silicon Valley and its satellites seem to disproportionately favor code interviews compared to the rest of the US market, for some ungodly reason.