Compare to a recent interview with the world's best employer (tm): the interviewer was young, was upset that my solution wasn't written in Java (???), and when I described my experience I talked about dashboards and he didn't know what that was. I described it as charts and he didn't know what that was. I described it as graphs and he also didn't know what that was. The interviewer had a bit of an accent so maybe it was a language issue but I had never run into someone who hasn't heard of a chart!
It’s at this point that I would end the interview and let them know it doesn’t feel like it would be a good fit.
If you literally know what questions are being asked in a test, you should probably fucking just learn it an move on.
Inverting a binary tree is not hard. That people keep using this as a joke is more a testament to the stubbornness of people believing they shouldn't have to do no learnin' no more than it is bad interviewing practices.
Expecting engineers to develop skills they don't learn/use in their actual professions to prove they're capable of working a job makes no sense. If these leetcode puzzles were actually relevant, why do so many engineers have to spend time outside of work "grinding" in order to get better at them?
I used to feel this way, but I think I’ve changed my mind. Interviews aren’t really primarily testing for skills you’ll use day to day, they’re testing for breadth of skills and knowledge and more importantly breadth of understanding. When I’m interviewing, knowing if the candidate has the specific skills for the job is the bare minimum needed to get in the door. I’m really more interested in potential, how much they can grow, and indicators of growth potential include how interested they are in the art of programming in it’s many different forms, whether it’s algorithms or math or software architecture, or coordinating people who write software. Puzzles are only the tiniest fraction of all that, but they’re still a signal that you like thinking about algorithms, and have exposure to different ways to write code and lots of algorithmic concepts.
A university CS degree isn’t particularly good at teaching job skills per se either, there isn’t much I use in my job day to day that I practiced in school, at a superficial level. But the school degree is pretty good at covering the broad concepts of computer science, and that has lasting value over the course of a software career.
Put up a job posting on a job board and you'll get hundreds of applications. 90% of those you're going to throw out because the resume doesn't match the job description at all. What does that tell you about the candidate pool? It's an all out assault of candidate spam. You have to employ these sorts of basic filters to even get the number of interviews you do down to a managable number.
This is endemic to the point where applying only for jobs where you fit the job description is a losing strategy.
And even if your own job posting isn't one of those, how is the applicant supposed to know you're one of the few employers who actually means what's in the job description?
Most people who are smart and get things done will be capable of shipping code, if they can stay motivated. And that’s where having some signal about their interest can help. I want to know if people can inspire their teammates, not just get along, I want to know if they can lead by example, whether they’ll rise quickly, and whether they’ll love it for many years. The essential job functions are just plumbing, the important parts are more than that and aren’t demonstrated by evaluating for narrow, specific job skills.
Look, I don’t in a million years think grinding on Leetcode is some singular answer, or even particularly good. But I don’t see anything wrong with people who are interested doing it, and I also don’t see anything wrong with asking interview questions. I never put a huge weight on such algorithm questions, and there are a dozen other major interview categories. So there’s nothing wrong with asking a few algorithm theory questions, to see the bounds of what people know. I like getting into questions that people don’t know the answer to, whether it opens a conversation about what it means, or whether the candidate has no idea or doesn’t care, that is a small amount of useful signal to me.
It's like a chef complaining about being asked to make a fried egg. They might not be making that exact food in their job, but it's trivial for anyone proficient with the basic techniques that they need in their job.
"Leetcode puzzles"... jeez.
If I were hiring you to work on raw data streams, I'd expect you to be able to figure out how to count in binary on your fingers in 10 seconds, if you hadn't already figured it out while sitting around bored somewhere.
You know what my first job was out of college after graduating with the highest GPA in my major? QA tester. That's all I could get. I had to beg to get commit access to fix bugs I found that I knew exactly how to fix.
I thought the meme depended on it being some obscure, difficult, and irrelevant thing.
It is also extremely simple:
TreeNode* invertTree(TreeNode* root) {
if (root) {
invertTree(root->left);
invertTree(root->right);
std::swap(root->left, root->right);
}
return root;
}It does apply. GUIs are fundamentally tree structures. Relational databases are fundamentally tree structures. JSON documents are fundamentally tree structures. Almost everything you're touching in a CRUD app is some kind of tree and you think knowing how to work with trees has "very, very little to do" with writing them? Again, how would you know?
I'm so serious that not knowing how to invert a binary tree is ludicrously bad. It's just a swap operation. You walk the tree and you swap the left and right branches of every branch you find. That's it. It's not black magic.
invert(tree):
if(tree not null):
temp := tree.left
tree.left <- tree.right
tree.right <- temp
invert(tree.left)
invert(tree.right)
But that's the sort of programmer who gets hired, because SOP for Javascript development (and oftentimes elsewhere) is to import the existing library, and any developer who insists on writing that code themselves would be considered a code cowboy wasting company time and resources, and likely writing less safe code in the process.
Because implementing low level algorithms like that is almost never an issue for application programming in modern languages, for which robust libraries for such operations exist and are data agnostic.
Unless you are using Go, pretty much the only modern popular language that both features static typing and lacks generics, so that kind of algorithm re-implementation task might make some sense for screening application programmers using Go.
Except it is. You spend a lot of time traversing nested tree-structured data, validating it, sorting it, filtering it. If you can't do the simple inversion operation you have no hope with the more complicated stuff.
Why would you do that? The whole point of libraries of generic operations is that you can apply them to thing you have without copying.
And most of the time, you can rely on the Master degrees to pull through. Although I once worked with someone without a degree, but he could do magic like no other programmer I met.