It is definitely about the coding skills. It is too easy to bullshit and there is a financial incentive to do so. Also many people with genunine 10 years of experience are not too good at coding.
The idea that everything boils down to answering some intro to programming questions quickly is absurd.
These questions, while certainly aimed at identifying core competency areas, are also an opportunity for the candidate to demonstrate an aptitude for problem solving. Nobody really cares "how many piano tuners operate in Seattle". What they care about is, given that kind of question, how a candidate responds. You might be surprised by the number of people totally unable to even generate a reasonable estimate:
- How many people live in Seattle? - What percentage have pianos? - How often does a piano need tuning? - How long does it take to tune a piano? - How many pianos can be tuned per work day (given commuting time)? - etc.. driving towards a number.
Did the candidate attack the problem and even attempt to solve it? Did they use metrics? The list goes on... Most LC-style questions (save the "aha! moment" ones) have a similar impetus, but are also much more practical and efficient because they test for many things at once.
And if I'm being honest... most FAANGs aren't looking for engineers that require quiet and time to solve problems. They are looking for elite engineers who can write a solution nearly as fast as the problem is presented (I'm obviously exaggerating a little bit here). The difficulty of the questions presented to me (6 technical interviews) were what I consider semi-trivial. I was able to describe the solution-space within seconds of reading the prompt and code an optimal solution nearly as fast as I could type in all cases. It honestly made me wonder about how poorly the average programmer must perform such that these were the questions they needed to evaluate my potential.
Another commenter posted this article [0] about the interviewing philosophy back in the early '00s. I found it very enlightening, and reassuringly, while reading through it I knew the answer to nearly every question (and could expand upon the topics) just off the top of my head. I'm not trying to sound arrogant here but the idea that a FAANG, who pays top-dollar for engineers, would settle for "10 years experience" as a suitable replacement for "demonstrates ability" is what's absurd. A false positive is way more costly than a false negative.
[0] https://sites.google.com/site/steveyegge2/five-essential-pho...
I can imagine it, because I've been that person.
It's simple interview anxiety, which causes temporary but severe performance degradation. Then when the interview is over, the anxiety suddenly disappears, and you can even go back and do the same problems much more easily.
But I suppose interviewers will just assume that my resume is a lie or that I managed to incompetently hold onto previous jobs.
If these people are finding work elsewhere and doing productive work for years what does it say about your process?
Or do you think companies never fire people?
We already fired plenty of people that we hired. So yes, our hiring process is not perfect. But if you're a JavaScript developer and can't explain the difference between var, let and const, I'm not going to hire you. If you claim these people are great developers, you are free to hire them.
Let me know the details of your company. Whenever we find a candidate that doesn't satisfy our requirements (which is around 90% of them), I'll send them to you so you can hire them.
I've said that even if you hire people who do know the basics of the language, and some algorithms, and even could solve a toy problem on paper, you might still hire someone who can't code at scale. Coding interviews typically don't test design skills, documentation skills, ability to not get lost on a larger code base, debugging skills, tendency to avoid hacks and increase tech debt etc.
The question changes to: is what you are testing the actual skill you need? Are you hiring a teacher who is going to explain var,let,const as part of their job or are you hiring someone who needs to know how properly to use var,let,const?
Send me over any developer who fails your teaching requirements for var,let,const but has code samples with proper usage.
I've never seen a senior developer fired for poor coding. I've seen them get fired for being part of a department cut or because they got into a fight with the owner/boss. I've seen them fired because they make too much compared to outsourced resources.
I'm sorry what? I don't expect them to teach me, I just want them to tell the difference. By the way, the ones that can't say: "they told me to always use let". I'll send them to you :D. Best of luck.
> I've never seen a senior developer fired for poor coding.
I've seen plenty. If a junior dev needs to help you out of trouble every time, you know there is something wrong.
Some people just reach their limit very soon, and can hide away in some comppanies. Probaly companies where you seem to work. Other companies probably just have a higher bar, no disrespect meant.
A junior helping a senior? Shame on them? Fire the senior? That sounds really foolish. You realize that junior/senior/etc are labels and someone you hire a junior can know more syntax than a senior in a framework. That's okay that the senior seeks helo.. it's natural and what a senior should do. p You are presenting your company in a bad light and making yourself sound inexperienced.
Could you have reached your limit? Would your methods fly elsewhere? Apply the len to yourself and see where you end up.
I can't really believe that people here think when you have more years under your belt, you somehow must be good. People get fired in companies because they don't reach the expected level. If you keep them, other colleagues will get frustrated and leave on their own. And then you're stuck with the underperformers.
And yes, everyone has limitations. Some sooner than others. Welcome to reality.
I find the discussions here very silly that somehow you must hire everyone without a technical interview, and never fire anyone because people don't have limitations. Not going to respond anymore.
What I read is a knee jerk justification for your hiring methodology without being open to any feedback.
You should take a breath. Clearly people disagree with you. Try to empathize with where they're coming from and understand the point they're trying to make.
Look, I have a lot of experience with the hiring process. It's very difficult. I will listen to someone with a lot of hiring experience. But just saying "it's broken" isn't going to cut it.
And remark that a big part of our hiring practice is to put the candidate at ease. I even say that they won't get everything right, and that's no problem. I help them out when they get stuck, etc.