I totally understand your point of view, but looking at it from the other side it’s not as simple. We had candidates with 10+ years of experience in their resume, talking to them it seemed they know what they’re doing, they showed some of the code they’ve supposedly written. Then they got hired and it turned out they can’t code - their PRs are below junior level, constant bugs, communication is abysmal, they overshoot their estimations by 3-4x, etc.
Thus happened to us twice, and after we introduced a simple live coding session to our interviews where you have to implement a simple real world web component (for a frontend position) suddenly the problem of bad hires disappeared almost entirely (you can’t judge someone’s character during a short interview but that’s another issue).
We recently interviewed a candidate, with 7 years of experience at a FAANG company, fail a really basic coding interview and we don't even make you write code.
I have no idea what these people expect. We ask coding questions, we have basic programming skills as a requirement, what do they think will happen if they get the job? Do they expect to just magically learn the required skills or hope that nobody will notice that they're not able to close their tasks?
Do you think working at a FANG would make you a better developer? I’m sorry but I think that’s a bad expectation, hire from a startup if you want great developers, their span of control and influence is much wider. Most of us at FANG are pigeon holed into a very narrow topic, have to work with really annoying, slow and complex internal build systems. And write very little actual code. Also, unless you have global scale problems, a lot of the skills developed working at that level aren’t useful to smaller orgs and will just drive up costs. Dont look to FANGs for guidance is my advice.
> Do you think working at a FANG would make you a better developer?
No, but I do expect any reasonably competently run company to figure out that the person they hired isn't actually able to do their job, especially after 7 years. I was also under the impression that this company actually did coding challenges as part of their interview process, yet this person managed to slip through their interview process. On the other hand our approach to just talk about programming in general terms seems to spot this type of candidate pretty quickly.
One of our most used questions is to ask people to tell us about something they don't like in a language or tool (one the candidate is very familiar with or enjoy using). It's pretty hard to imaging even a senior Java who doesn't have some pet pew about the language.
> No, but I do expect any reasonably competently run company to figure out that the person they hired isn't actually able to do their job, especially after 7 years.
Oh, they did. This person probably did not get paid as much as their peers. A great deal of compensation is discretionary.
Whether any decision-maker actually stood to benefit from removing this person from their position is another matter, however. Firings seem very uncommon, and layoffs depend on business conditions.
It's less that working at a FANG produces better devs and more that FANG can afford to be picky and so having worked there is a sign you passed a high hurdle once.
Kinda the same idea as having Harvard or Stanford as your alma matter. Most schools will teach you most of the same stuff, but those universities only take the "best". If your idea of "best" is similar, you'd take that Harvard also liked the person as a good signal.
There are lots of roles at big companies that don't involve actually writing code. The bigger the company, the more communication and organizational overhead there is, and the more not-actually-coding work there is. Even within roles that have a "software engineering" title.
Hell, I barely touch any code in my current company. The only reason I can still code is because I love it, started programming at about 11 years old, and still do it in my spare time. If it was "just a job" for me, then no doubt the skill would atrophy.
I interview best when I'm relaxed and it doesn't feel like there's a lot riding on the interview. What has worked for me is to interview early (when I feel "maybe I should leave my current job", rather than "I have to leave this awful job ASAP or I'll lose my mind"). Even then, I've had bad interviews - where it's like forgetting your own phone number or PIN; It's hard to recover from your brain short-circuiting early on, I suspect my interviewers may have thought I'm a fraud too, but such is life.
Interviewing has plenty of randomness - on a few occasions, the stars were aligned and I solved sequences of very challenging technical questions much quicker than the interviewers had planned, which gave the impression that I'm some sort of genius. That performance was not representative of my usual capabilities, but I didn't tell them that (:
The IT job market is a two sided lemon market, people may lie on their CV but companies can be very abusive as well. If you don't do what OP suggests, people will not respect you. I've had five developers join my interview call to see if I can implement a palindrome checker. This is proof that non of them bothered to read my CV and check out my github projects. This is not respectful, and you have to stand your ground against such nonsens. Let them now this is not what you expect from people working for you and and that you expect better from them in the future. If they don't like that you won't have lost anything.
Was it the task itself you feel was disrespectful or the way they ran it? Anyone can put up fake/inflated CV so it's not really proof they didn't bother to read it, GitHub can be easier or harder to fake/inflate depending on the projects. Doing something like a quick palindrome checker to show "Hey, yep - I'm real not some random inflated applicant you probably got 10 applications of alongside mine" seems more than reasonable/respectful (by both sides). I can also easily see how 5 people can hop on and completely run that task in the wrong way and come off as being know it all douchebags or the like but that'd be a different independent issue really.
same experience, same conclusion. I used to hire without coding interviews, i don't anymore.
Although i see it as a way for the candidate and i to talk about code in general, and assess his level. No as a simple barrier.
i hired a candidate that completely failed a code interview because he was super nervous, but just talking about the problem made me quite sure he was actually good.
Just by introducing coding interview, how would you know they will not overshoot estimations by 3-4x? It's not one person's job, normally estimates are done by the entire team
The problem there is that the amount of time being wasted is asymmetrical since the employer isn't present, so the typical experience from the candidate's perspective is spending an evening working on a project and then getting no feedback and a canned rejection letter.
Just kidding, but you should value your applicants time. You could just as well show them bad code that is a problem and ask them what they notice when they look at that code. If they are good they point put the problem(s) if they are bad you will probably be able to figure it out based on asking them alone.
Thus happened to us twice, and after we introduced a simple live coding session to our interviews where you have to implement a simple real world web component (for a frontend position) suddenly the problem of bad hires disappeared almost entirely (you can’t judge someone’s character during a short interview but that’s another issue).