Most tech companies which have a monopoly don't care about the usefulness of a person's skills. They only care about arbitrary puzzle-solving abilities and other random abilities which have nothing to do with productivity. When applying for a job at these companies, the criteria are so arbitrary that you're basically a beggar. You just have to try to figure out what they want to hear, what they want to see then you basically have to tell them and show them exactly that; all while simultaneously using your face muscles to project a sense of enthusiasm. Just like a beggar who does backflips or plays the ukulele on a banjo; you just have to do whatever random crap will impress them enough to toss a few coins your way.
I can confirm this with recent interviewing experience. I interviewed at a top tech company and got asked puzzle coding questions I wasn't prepared for. Testing whether I can find the longest palindrome subsequence of a string optimally via a tabular or memoized dynamic programming solution in 20 minutes has practically zero ability to measure how effective I am on the job. That said, after that interview I studied the algorithm and am now slightly prepared for the next big tech company I interview with, I guess.
In contrast, at another interview I got given a take-home assignment that I almost didn't want to do because it felt like the kind of work I would do in my day job and I didn't want to do that in the evening or my time off. That task, on the other hand, probably measures infinitely better how effective I am on the job.
Testing whether I can find the longest palindrome subsequence of a string optimally via a tabular or memoized dynamic programming solution in 20 minutes has practically zero ability to measure how effective I am on the job.
Not just "practically zero" - but like, "for sure zero". As in, there is absolutely zero chance you would need to solve a problems like this (or Sudoku, etc) in the course of actual engineering work.
Generally, interview puzzles have almost zero applicability to real world work. It's similar to many colleges: the hardest part is getting in. One coding test involved a math formula I hadn't seen in 20+ years. It was simple, but if you "forgot" that, you were stuck.
You're better off giving someone a more realistic take home test and have them walk you through it during the interview. You'd get a better feel for what their "real" code looks like when they're under less pressure, how they communicate while presenting their solution, etc.
I don't think that's accurate - your example is closer to asking a programmer to take a typing test and hire them based on wpm. Both are hitting keys on a keyboard after all.
I agree that, if you're hiring someone who will primarily be managing others or, maybe, architecting some systems, without doing the actual implementation (which, btw, I think is a suboptimal way of doing things), then you shouldn't test their coding. But if you're hiring someone to code, you need to check they understand how strings, memory, dynamic programming etc works.
I don't agree, of all the jobs I had, I've never had to do anything close to a typical coding puzzle. There are much more real-world scenarios you can test people on.
I think it depends on where you are located, the culture, how competitive the current market is, etc. In the early 2010's, it seems the US had a shift towards these sorts of "puzzle" interviews. Before that it was more laid back, maybe a take home test as part of the filter...
We might be arguing besides each other. The puzzles I'm arguing for are e.g. simplified toy versions of problems solved in the existing code base. That solves a real-world problem, so it fits your requirement.
It's probably because these companies have so many good applicants, and they're big enough that a "great" junior engineer can't do much more vs a "good" one. So they're not looking for top engineers, they're filtering out bad ones and then basically choosing at random.
Unfortunately, if there are many more potential employees then you're going to be a beggar no matter what. If you're applying to companies who only get a few applicants per position, then you have leverage and the companies actually have to look for quality.
> If you're applying to companies who only get a few applicants per position, then you have leverage and the companies actually have to look for quality.
Unfortunately, a lot of smaller companies simply cargo cult on BigCo hiring, as that's all they know. I see smaller companies who have unfilled positions for 12 months or more, because they apply the same method to hiring as the company with hundreds or thousands of applicants.
Tech giants do have some broken hiring practices, but I think even they will notice a difference if a job applicant believes in their own value and in their own abilities. Nobody wants to hire someone who doesn't. It's an unattractive quality, and it suggests they won't succeed as an employee.
And interviewing at a very selective company doesn't need to negate your belief in your own value. If you could be the top applicant at some other company but you interview at a company that might not even hire you, then applying there should be a choice that you're making because the trade-off is somehow beneficial to you. Your value within the overall job market remains, and you can always walk away.
I think that changes rapidly when you interview past the mid- code monkey positions. I doubt a VP of engineering would be interviewed on anything but opinions and experience.
When that shift happens depends on the company and what the team is hiring for.
