> I have interviewed many people employed in tech as programmers for their entire career and they can't code.
Think about this contradictory statement for a while. Can it actually be true? Or is there something else going on?
If the interviewee has nothing but sub-1yr stints on their resume, perpetually getting fired before vesting at any company, then yes, it's very possible they actually can't code and just fake it at every interview.
But everyone else... if they have spent years at tech companies writing production code then obviously they know how to code. They might be great or maybe mediocre, but guaranteed they at least know how to code.
So, if your interviewing technique is concluding something that is obviously impossible, then start by considering how to improve the interview technique.
I’m an electrical engineer who does circuit design. I’ve interviewed many electrical engineers over the years and the situation of applicants having “years” of experience while simultaneously not knowing how to design a single circuit is real. In our field it’s usually because although the person’s title is engineer, in practice, they don’t do any engineering. There’s just a ton of peripheral work (basically paperwork related to operations and compliance), which is very important, but is not design.
My guess is computer science has a similar issue.
Lots of people with programming in thier job title but they don’t actually program. And based on ltbarcly3’s empirical measurement, “lots” is above 10%. ;)
10% of applicants that make it to a phone screen. I estimate that the number is much lower than 10% overall because incompetent people with good looking resumes tend to do a lot more interviews than good candidates.
"claim" kills? Isn't part of the HR screening about some litmus test to make sure they aren't very obviously lying?
And yes, this is part of why the obsession with FAANG on resume is very overrated. Very few companies require the skillsete FAANG needs. Some of thst FAANG culture is orthogonal to what medium/small sized companies require.
I don't think you read the thread. They did have those jobs, and presumably they were on teams that did vaguely what is on their resume. No HR doesn't investigate candidates or do background checks before you interview them, that would be very expensive and silly.
I feel like you kind of vaguely are aware of these topics but have never actually had a job or something because you seem completely unfamiliar with the basics of how hiring is done in the industry. Are you from Eastern Europe maybe?
I know a lot of people who can tweak code that already exists. However, if they are sitting in front of an empty text editor and given a goal, they don’t know how to break the problem down and build a solution with the tools the language gives them.
In a large environment, someone may rarely need to start from nothing, so the interview format throws them.
That said, I think being able to break down a problem to solve it with code is a really important skill. Without it, the person will always have to lean on others to fill that skill gap.
> I know a lot of people who can tweak code that already exists. However, if they are sitting in front of an empty text editor and given a goal, they don’t know how to break the problem down and build a solution with the tools the language gives them.
But being able to break things down and come up with a solution is not necessarily something that needs to be done quickly, in the time you have for an interview. Quite often I've been faced with a new problem and done absolutely nothing visible for ages. Literally just reading around the problem, asking questions, and sketching in my mind without writing a single line of code.
This is often faster and better than starting immediately.
There's another extreme, too: people who can code up an app in a matter of days, but can never learn to navigate and successfully maintain a legacy code base (even their own!).
And there's no easy objective way to screen for this in a job interview. So they pretend it doesn't exist and never ask questions like: "Suppose you're designing a green-field app that you think will grow over time like X, Y, and Z. How would you design and organize your code so that the app stays maintainable and flexible over time?"
I could talk for hours on this subject with concrete examples if anyone ever asked.
I think another problem is that there are so few engineers/architects who really "get it" on this subject. I can only think of a few ex-coworkers with whom I could have the kind of in-depth conversation about app design and organization that I'm picturing.
I've never worked in big tech, always for startups or non-tech corps with a few rock star devs and a lot of decent devs. So maybe it's different at a FAANG. But in my head I'm picturing a bunch of algo-geniuses whose code turns into a big mess over time when requirements take a right-turn and break all their beautiful abstractions. I've worked on a few apps like that and it's not fun.
Nothing on interviews is objective to begin with, so we can discount that.
Your template sounds like a fine way to ask such a question. I think the issue is managers or someone above simply don't want to invest in proper interview questions and instead just do that FAANG does. Even though very few companies need such core algorithmic knowledge but need people who can properly navigate legacy code. FAANGs will actually make sure new hires learn the code base, unlike many companies thst want you to "hit the ground running".
I think this is why people job hop. They never have to support their unmaintainable greenfield app. Without the pain of those mistakes, they never learn to make the next one better either.
The goal when hiring isn't to find someone who is barely skilled enough to just slightly come out as better to have on staff than not. In fact these are often the worst hires as they slow everything down and create work for you to find tasks they are capable of, but it seems unfair to fire them because they aren't totally useless all the time. You hire the best candidate overall, and you are very far from describing that.
Too right. I had an idiot manager who hired the next person with a pulse - we got some money-motivated guy that complained about everything and didn't listen to what he actually needed to do, and my manager nearly destroyed the team by pretending that he was fine.
I thought that too until we had a guy start two years ago that interviewed well and answered questions like he knew what he was talking about but then when he started, one of his first questions was how to figure what endpoint was being called by a website (as obvious as looking at your browser's Network tab, or browsing the website's source to find the endpoint). Not long after that he had to clear a couple more values as part of a cache invalidation procedure and was utterly bamboozled by the if (!cached) { clearCache(); } else { cache(data); } logic. That was an exceptionally draining few months until he was sacked.
Think about this contradictory statement for a while. Can it actually be true? Or is there something else going on?
If the interviewee has nothing but sub-1yr stints on their resume, perpetually getting fired before vesting at any company, then yes, it's very possible they actually can't code and just fake it at every interview.
But everyone else... if they have spent years at tech companies writing production code then obviously they know how to code. They might be great or maybe mediocre, but guaranteed they at least know how to code.
So, if your interviewing technique is concluding something that is obviously impossible, then start by considering how to improve the interview technique.