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.
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.
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?
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."
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.
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".
Haha I hate all the code I wrote more than 5 years ago.
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.
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%. ;)
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 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?
>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.
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.
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).
V = I * R
I = V / R
R = V / I
And yeah, I've been trashed multiple times for this opinion, but I'm not backing down!
Or is this ironic?
I always try to give everyone I’ve interviewed the benefit of the doubt. You never know what’s going on in their lives, and even if they fail a trivial question it doesn’t mean they are faking the ability to code.
I joined Facebook back in 2018. Didn’t study at all for the interview and passed somehow. Then I probably conducted 200-300 interviews in my time there, so I became quite familiar with the questions. My performance ratings were all exceeds or greatly exceeds. I voluntarily left on my own after four years to join a unicorn startup. I didn’t prep for that interview either but passed it too. Well, the startup failed and many people went back to Meta. So I actually prepared quite a bit this time and scheduled a mock interview with them. The mock interviewer said I did great and not to change a thing. When it came time for the real screening interview... I failed the matching parentheses question.
I generally try not to make excuses. Almost every interview I’ve failed has clearly been my own fault. But in this particular one the interviewer kept interrupting me every two seconds and I absolutely could not think. I had done matching parentheses many times before in practice, but the constant interrupting rattled me to the point where I totally lost focus and bombed it. Not a great experience.
So yeah, I’d just recommend giving people the benefit of the doubt. Everyone has difficult moments occasionally, but it doesn’t mean they’re stupid or can’t code.
Something I have changed my stance on a bit is automated coding interviews. I used to be adamantly against a company giving candidates automated code tests, but I see now that it takes the interviewer out of the equation.
There have been times I’ve received answers in interview that weren’t the written answers, but I looked it up afterward and tested it out… and they were right. I learned something news and tweaked the answer reference as a result. If those questions were in the pre-screening instead of asked directly by me, it would have filtered out good people.
I remember fighting to get access to the pre-screen data to see what the answers were and find if there were any other cases like this, where the non-technical pre-screener was filtering out potentially good candidates, because we couldn’t give them exhaustive answers to questions being asked.
It is really entirely up to each interviewer how the interview goes and they are usually scheduled between 2 other meetings so often the interviewer is distracted.
Very strange system imo, lots of randomness
Well yes, that's why I'm against it. A one way "interview" is an audition, not an interview. There's nothing worse than wasting 2, 5, 10+ hours on something that ends up with a template rejection letter.
That's great for the interviewer, but devastating for the interviewee. They can't even get feedback on how to improve.
There is also nothing worse than wasting 2, 5, 10+ hours on an in person interview to just have the interviewer flunk you our be unfair to you.
I still believe that personal interviews are important, I'm just raising the fact that a large portion of an interviewee's success is based upon their interviewer.
>There is also nothing worse than wasting 2, 5, 10+ hours on an in person interview to just have the interviewer flunk you our be unfair to you
The interview stage inflation is definitely a problem, but speaking with actual people still has benefits. You get an idea of their culture and you can still network even in such a situation. It's not guaranteed but you get a much higher chance to get advice and feedback on or off the record if you're polite. People are flexible, some standardized exam may never even reach a human.
>'m just raising the fact that a large portion of an interviewee's success is based upon their interviewer.
Indeed. I'm just stating a viewpoint where an interview needs to be personal. An audition in this software space is about as impersonal as you can get.
Wat? Feeling the pressure is even worse when you're young!
It's not as if testing for performance under stress is useless: Tough on call rotations happen, and you might need someone that does well under pressure at 3 am in the morning. But the picture you get on a screening isn't as clear as it appears.
1. study the leetcode books in advance
2. do lots of interviews
In the military, there's a saying: train hard => fight easy
On a stop-the-world production incident at 3am I know that codebase like the back of my hand, and my job very likely doesn’t depend on whether I solve it in the next 30m. There’s barely anything stressful about it.
On an interview, with my future on the line, and presented with an unfamiliar problem?
The latter has more in common with an open mic night, the prospect of which the vast majority of people are terrified and would break down if they attempted it.
I recommend that when there's an opportunity to get up in front of a mike, take it, and get comfortable with it. It's a skill that will serve you well.
I feel like a good middle is to allow Google for documentation searches, not solution searches. Without searching (or IDE with radix completion), I'd probably fail the test for not knowing the syntax off the top of my head.
I never mesmerized strstr(). But using it frequently makes it stick in my mind.
Might as well put a suitcase with $200k and a copper clock ticking away on the table next to them.
Surprisingly, I have an 80% fail rate on the first question usually, which is just “find the second largest number in an array of numbers” for a 5 YOE role.
I think HN is just overwhelmed with people who somehow got hired into technical jobs but can't do them. Anyone who thinks that 'finding second largest number in an array' or 'finding if a string is a substring of another string' are hard, or that the pressures of an interview are a valid excuse for being unable to do it are simply not intelligent enough to be successful in this field and they are casting about for some excuse to protect their ego. These are problems that a bright 12 year old with no programming experience could do for fun, and these folks are purporting to be educated, experienced, professional programmers.
As much as people like to say 'muh anxiety', I've yet to meet someone who can't do very basic coding in an interview but also they are capable of basic coding in any other context. I would suggest that this sort of person is so rare that you will probably never meet one over the course of a normal career.
I guess they could just by lying "to protect their ego" but in that case why post their comment at all?
It really is the case that some people sometimes completely go to pieces when stressed, and mocking them by saying "muh anxiety" doesn't stop that being true.
To some degree the interview is not about getting the question right but also how you respond to questions about your answers. I would rather have someone who started with a totally incorrect answer and then reason back and forth with them til they got on the right path, than someone who came up with the right answer and then clammed up and refused to explain how they got there. (I once had a candidate tell me, verbatim, "I don't think analyzing performance of an algorithm is part of an engineer's job.")
I would prefer if there were a more humane, less stressful, and scalable way to do an interview. The problem is that as a profession we lack the continued examination/licensing of other fields like engineering or medicine, so we don't have a good barometer of skills otherwise. And I often have to sift through massive numbers of people clearly overshooting their shot to get a good position.
Yes maybe someone can't come up with this in an interview. My point is 99.99% of the time when someone fails this they are lying about their work history or they are so stupid they can't hope to do the job. 00.01% of the time they could do this easily and the stars aligned to give them a rare bad day. The best way to deal with that is to just assume everyone who fails this can't do the work, and the 00.01% person just interviews somewhere else and doesn't have another bad day. I don't even know what the alternative to that is, just hire everyone who claims to be qualified and hope for the best? Give everyone who demonstrates very very strong incompetence signals 2 or 3 more tries?
def matched(str):
count = 0
for c in str:
if c == "(":
count += 1
elif c == ")":
count -= 1
if count < 0:
return False
return count == 0In an era where linters and autocomplete and IDEs have existed for decades it’s silly to fail an interview based on tiny error checks.
I think this is good evidence that, in fact, it's not vanishingly unlikely that someone genuinely competent flubs what should be an embarrassingly straightforward coding task in an interview.
That doesn't, unfortunately, mean I have a good suggestion for a better way of telling who is and who isn't capable of writing code. Maybe this is the best we can do. If it really is just a matter of "sometimes, at random, people have bad days"[1] then provided it's fairly rare this issue doesn't matter too much. I'm more worried about the possibility that it's more "a smallish fraction of otherwise-good people often have this sort of bad day", because then that smallish fraction of people may be getting completely overlooked, which is bad for them because it may take them ages to get a job and bad for employers because it effectively reduces the pool of good people to hire.
[1] In this particular case, the "bad day" seems to have included an obnoxious interviewer, which it's reasonable to hope wouldn't be repeated at another company's interview.
But, again, pointing out a problem unfortunately doesn't guarantee having a good answer. But, equally, not having a good answer doesn't mean the problem isn't real. It would be very nice to believe that all the people failing interviews because they fail to solve an easy coding problem are undeserving incompetents who should be bombing out of the interviews, but it looks to me like that ain't so.
Lets say we interview 100 (N) people for a role. (100 is a lot but pick a number yourself and follow along)
The probability that a random interviewee is a top programmer is lets say 1/50 (T). So in our pool of 100 we have on average 2. Give everyone this problem, and if they get it right they move to round 2 which is 4 more interviews. Lets say 20 (P) people pass to round #2.
We are paying for a total of 100 + 80 = 180 interviews (N + 4P). To give everyone who failed the first round another try would require another 80 (N - P) interviews. So for almost 50% more cost (N-P)/(N + 4P) we gain (T * N * 5%) = 0.1 additional top programmer making it to round 2 on average. Just interviewing another 80 people (same cost) would get us (T * 80 * 95%) == 1.52 additional top programmers to round #2 on average. There's basically no reasonable % you can pick for how often people screw up where it makes sense to do anything but just ignore the possibility.
Before, you were saying: anyone who says "muh anxiety" is just trying to cover for the fact that they're incompetent.
I suggested that we've got pretty good evidence that interview stress really truly can, and not only-vanishingly-occasionally, make competent people fail to do simple interview-type coding tasks.
So now you're advancing a different claim: even if some competent people appear incompetent in some interviews because of the stress of interviewing, you should make interview decisions as if those people are just plain incompetent, because most people who fail to do simple interview-type coding tasks really are incompetent and identifying the few who were just stressed out is difficult.
That could very well be true! But it's not what I was arguing against before.
... But I'll argue against it just a bit, even though I mean it when I say it could well be true.
1. There may be much less inefficient ways of catching the competent-but-stressed candidates than "just interview everyone twice"; completely incompetent people probably don't interview exactly the same as competent-but-stressed ones. (I don't know for sure because, of course, when you interview someone and they don't perform well you don't generally get to tell which category they were in. But I bet it would be possible to find out.)
2. If the situation is that some people are particularly susceptible to interview stress (but that this doesn't make them bad at actual programming jobs unless they're in an extra-stressful environment), the "eh, just reject them" strategy might be good for companies that are hiring but punishingly bad for the people affected who just can't get a job because they are bad at interviews. If there were a good way to identify people who are good but fall apart readily under interview-stress, that might be a big deal for those people. (Which someone on the hiring side might not care about, of course; but it's sad when some group of people gets systematically screwed over.)
I repeat, as I have said before, that I don't have a solution to this problem nor even good reason to believe that there is one. I'm just pushing back against the blithe assertion that there isn't a real problem here.
Unless you mean using a "substring" function or regexes... coming up with the naïve O(n^2) algorithm is indeed easy, but finding a fast algorithm like KMP is, I would say, non-trivial?
For the "second-largest number in array" it's rather easy to come up with an O(n) algorithm, so I would consider the two cases to be different.
Imagine a person with a pilot's license refusing to fly tandem for an airline interview.
That’s not a great comparison since a pilot has already passed substantially harder tests to get that license and a flight is exactly what the job is. If you have a candidate with a pilot’s license you can assume at least a baseline level of capability which you can’t assume for a software engineer. That has pros and cons but it definitely means interviewing is a noisier process.
The other problem, however, is deeper: the job of flying a plane is exactly what’s tested to get a pilot’s license but what many places do for developer interviews is wildly unlike the actual job so it’s more like interviewing pilots based on trivia questions about the number of rivets on a B-52 and how well they can solve 3-D puzzles, and then being surprised when there isn’t much correlation with real world performance. For example, only at the most toxic companies will the interview be one of the least stressful parts because the rest of the job is a team effort. What makes the interview challenges stressful is doing it without your normal tools while someone else is looking for reasons to fail you, but in a normal job your coworkers are trying to help you succeed because even if you’re not friends you are all better off when your company succeeds. At a startup, trying to ding someone for trivia challenges is like hitting the iceberg to prove that the navigator made a mistake.
Airlines very strictly test pilots and insist on check rides regardless of what official qualifications pilots show up with. They do this because they are professional organizations with decades of experience and it is necessary for safety. Giving someone the benefit of the doubt because they manage to meet the absolute minimum standard that makes operating an airplane legal is insane.
In contrast, we don’t have anything like real certifications for developers and many of the interviewing questions are very unlike the actual job. Hiring would be easier if we did have something closer to what a pilot’s license conveys, but that’d also slow the field down since programming has changed a lot more over the last 50 years than flying.
If someone asks me what the time complexity of something or the other (I literally had to go look up the name), I completely freeze up.
Whether you know the term doesn’t matter when you understand the basic concept that for inside for == bad.
Anyhow, it seems to be working out pretty well for me, so while I’m also annoyed by incompetent people the idea that it’s due to lacking CS fundamentals sounds bizarre to me.
You sure it's not nepotism, or an inability to make sure the resume fits the person? Or any other number of non-merit based criteria from HR?
For context, back when I was interviewing I encountered many interviewers who process involved simple questions with simple solutions but with extra gaslighting on top. 'Are you SURE that's the right solution?' while I'm in the middle of throwing out a correct answer. It's actually very easy to guide someone away from a correct solution into the wrong one by simply making them second guess themselves under pressure.
It was something that I started to be extra cognizant about when I was the one interviewing people, that it's really quite easy to throw someone off track.
And, and having to explain everything, well, this person had never heard of it. And, and for the more, didn't know what modulo was, like, how do you, how do you say you know Java?
I suck at programming but I could bang out 100% of the things mentioned in this thread. In like four languages, including FORTRAN.
I have interviewed many people employed in tech as programmers for their entire career and they can't code. I don't meen leetcode, I mean they get confused trying to write brute force substring search. The nested for loop seems to be too complex for them to keep in their head all at once.
I have had numerous people cry. Again this was a screen, not leetcode. I'm asking them to check if text has mismatched parens, or find a substring. Things you do for homework in your 2nd programming class freshman year. Things every competent programmer can do while chitchatting about the job.
I would estimate that more than 10% of screens are like this, again these are employed people in the industry for years, sometimes tens of years.
Edit: I understand that people can get flustered, I understand that some people have trouble under pressure or while being observed. That's why I pointed out multiple times that the problems I gave are extremely, EXTREMELY easy. I'm basically asking them to write down their name and they sit and look at the pen like they've never seen one before. If you can't write a 5 line function to find whether a substring occurs in a larger string when given 45 minutes, your choice of programming language, and as many attempts as you need to debug and try again you simply will not be able to do any useful work as a programmer. If you don't know that to match parens you need to use a stack (or at least that it's one way to do it) you either have a very poor memory or no training in computer science at all - either of which is frankly disqualifying. Anyone borderline competent would invent a stack when presented with this problem if they hadn't already been told this fact a dozen times during their education or even light reading about algorithms.