Hacker News Reader

Comment by jjav | Hacker News Reader

> 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.

View on HN

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%. ;)

If they carry a wallet card that has on it:

    V = I * R
    I = V / R
    R = V / I

they are not real EEs.

And yeah, I've been trashed multiple times for this opinion, but I'm not backing down!

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.

Sounds like the resume screening is either non-existent or insufficient then.

Nope, they have solid resumes. Top companies and relevant experience on paper. They claim skills with the right tools. They are just idiots.

"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?

Quite the opposite (and sadly, still. American). I'm just so frustrated how I'm 10 years into this career and the interview process feels more random than ever. I can apply to 100 job and interview for 10 that all fall through. Then I can just go to a bar and trip into an opportunity I wasn't fully expecting. What does that say about the interview process?

>No HR doesn't investigate candidates or do background checks before you interview

An HR screen isn't a background check. It's "can you talk about your roles and provlems solved like you actually did it. A good HR screen should make sure they aren't blatantly lying

>that would be very expensive and silly.

Let's both not pretend the interview proces is in any way optimized for any metric. You have often non-tech roles create a description for a tech role (leading to famous blunders like "have and jave script is the same") . You have an increasing amount of rounds of interviews to go through for a job that may not exist or may already be reserved. And more and more of the parts are being outsourced, leading to power quality candidates. All that before throwing a reckless reliance of AI on everything.

The most optimal hiring is to focus on high quality hires brought in as fast as possible. Or not to hire if you don't need to hire. But we're not really running on sensible business practices these days.

You keep saying 'we'. The companies I have worked for have on average had very streamlined interview processes, with the exception of very large (>2000 engineer) companies. I don't know how to fix hiring for companies that big. I'm sure you have a lot of 'ideas' that are really just pointing out the problems. We all see the problems, but fixing them means either empowering individual managers (many of which would just hire their cronies instantly if allowed to) or inventing new ways to do HR which is obviously nontrivial, especially with incumbent HR morons fighting you.

An HR screen will sometimes remove frauds (not usually because they can't really tell, it removes uncharasmatic frauds only), but it also has a very high probability of removing anyone on the autism spectrum - no matter how qualified. I really don't want people on the autism spectrum removed from my hiring funnel for software engineer. If you ever looked over the shoulder of a recruiter or HR when they do a first pass on resumes you will be horrified at how many of the best candidates they pass over because they have no idea what they are reading, and how many very poor candidates they pass along for very stupid reasons like having 'Yale' for their college (despite it being for History and despite it being the extension school, true story, and this person ended up getting hired despite negative interview feedback and then fired for incompetence a few months later).

> An HR screen isn't a background check. It's "can you talk about your roles and provlems solved like you actually did it. A good HR screen should make sure they aren't blatantly lying

Correct. While not perfect, if you have good HR hiring team they will do a decent job at feeling out the people before they get to you.

> I can apply to 100 job and interview for 10 that all fall through.

Part of the difficulty is that (despite any myths around engineering shortage) there are so many qualified people for every role that it is overwhelming.

I just opened a new job req last week, I have over 1100 resumes in the queue already. And this is a pretty specialized technical role in a specialized department, not a generic "javascript software engineer" role, either.

Obviously I can't read all of them, which makes me sad because someone took the time to send their resume and I feel like I should give them the respect of reading it, but there are simply not enough hours in a week. While HR does the screening, I also go and do a random sampling of the resumes and everyone who has applied seems at least moderately qualified. But of course I can only talk to about 1% of them at best.

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.

> successfully maintain a legacy code base (even their own!).

Haha I hate all the code I wrote more than 5 years ago.

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.

> You hire the best candidate overall

How, exactly, would you do that?

Say you open a new position and you get 100 resumes a day, every day, until you shut down the role and pick someone.

How are you hiring the best candidate overall?

How long are you waiting for "the best"?

How many resumes are you really evaluating per day? With 100 coming in, how do you know you didn't miss "the best" one?

Do you ever get tired of arguing in bad faith?

1. https://en.wikipedia.org/wiki/Secretary_problem literally tells you exactly what to do in your situation. I'm sure someone, probably a professor or fun video on social media has told you about this a dozen times in your life, but if you didn't pay attention you can always Google it or ask ChatGPT https://chatgpt.com/share/67d3a121-13e4-8006-9ae3-625838875e...

2. While I said the goal was to hire the best candidate, this was as compared to someone who is just barely better than not filling the position. Hiring a top 5 candidate is also very good. The argument in GP was (paraphrasing) "I know people that aren't good programmers but they can manage to do little changes to existing code therefore you shouldn't give interview problems these dummies can't solve."

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.

Why would you clear the cache if it's not cached?

Or is this ironic?

Sorry got my code blocks swapped around and didn't proof-read carefully enough.

It was utterly mundane code.

i spent too much time on thedailywtf.

Reply on news.ycombinator.com