6 ms·

I have done probably 500 to 1000 tech screens for big tech companies (as the interviewer) and this is completely true. I have interviewed many people employed

I have done probably 500 to 1000 tech screens for big tech companies (as the interviewer) and this is completely true. 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.

momocowcow 2y ago
You are still not testing if they can code. But whether under the scrutiny of another person, they can code. Maybe this is important to you, maybe peer programming is important to you for example. I remember a young dev who couldn’t pass such tests, as he would get too nervous, yet he had written the core tech for many shipped products. The type of guy you would just stick in dark room. With age this type of stuff settles down.
- giantg2 2y ago
  I agree with both you and the parent to some degree. I have experienced interviews that went badly because they were in an IDE I wasn't familiar with, or in Leetcode (never used it). So I'm distracted by how to use the tool rather than how to code the solution. But I can also see how stuff like finding a substring is easy - most languages have a function for it. But at that point, you're testing different things - problem-solving vs rote memorization of a provided function. 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.
  - WalterBright 2y ago
    > rote memorization of a provided function. I never mesmerized strstr(). But using it frequently makes it stick in my mind.
    - giantg2 2y ago
      Not everyone uses it (or their language equivalent) frequently depending on the needs of their project. If I'm really using it frequently, then I would probably be looking at higher accuracy/resiliency options like parsing the input and comparing to a map, or regexes.
- alabastervlog 2y ago
  “Scrutiny of another” who’s a peer or even a client is super different from an interview. 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.
  - WalterBright 2y ago
    My first attempts at public speaking were a frozen horror. But I kept doing it, and it kept getting easier and easier. 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.
mixmastamyk 2y ago
Some people are good coders but can’t do it with an adversarial person watching. I’m often one of them. Might as well put a suitcase with $200k and a copper clock ticking away on the table next to them.
- bobthepanda 2y ago
  As someone who does these types of interviews on both ends, something like this is why I like to start with an outrageously simple question to break the ice. 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.
  - ltbarcly3 2y ago
    I just saw that this comment was fading from downvotes. 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.
    - gjm11 2y ago
      Elsewhere in this thread there is literally an example of someone who, by their own description, worked at a FAANG company for some years getting good performance reviews, has enough interview experience that even if they couldn't generally code their way out of a paper bag they were surely good at interview-question coding, ... and, under pressure from a pushy interviewer, completely failed to do a straightforward coding task. 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.
hibikir 2y ago
What is really crazy about this though is that sometimes it really is the interview setting, as people unused to interviews can, at times, emotionally collapse. I have seen people who are actually good programmers get wrecked by simple questions because of their inability to handle stress, and how the lack of interview practice turns a simple exercise into a hellscape. 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.
- geoka9 2y ago
  Not to imply that you're wrong, but I've always been bad at LC interviews, but surprisingly (for myself) passable when called upon to troubleshoot and code up a hot fix in the middle of the night. Maybe those are not entirely similar types of pressures.
  - lubujackson 2y ago
    There is a big difference between solving a critical bug, which is your job, vs. passing an arbitrary leetcode test from a disinterested 22 year old where you might lose your house if you get it wrong. You have 15 minutes.
    - WalterBright 2y ago
      The cure for such fears is to: 1. study the leetcode books in advance 2. do lots of interviews In the military, there's a saying: train hard => fight easy
- quinnirill 2y ago
  It’s also not the same kind of stress. I’ve interviewed many a candidate who were sweating and/or shaking at some point of the interview (with heavy reassurance and me trying to to steer the conversation towards and area where they feel stronger), but they can often end up being calm and reliable alert responders nonetheless. So far I’ve seen very little if any correlation between being able to handle interview stress and on-call stress.
insane_dreamer 2y ago
Knowing the right answer and knowing the right answer with a gun to your head are two different skills.
ezekiel68 2y ago
The other replies to this comment aren't wrong but I feel they fail to take into account that (especially with startups): having someone watch you code during an interview is one of the the least stressful experiences the person will face with the company - once the job begins. Companies can't take on the risk of dealing with a bunch of passive-aggressive bullcrap once the real code reviews begin after the hire. Most tech job reqs contain the words "Excellent written and verbal communication skills" on purpose. Imagine a person with a pilot's license refusing to fly tandem for an airline interview.
- acdha 2y ago
  > 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.
  - ltbarcly3 2y ago
    Go on youtube and watch NTSB / FAA investigation reports. If you think that a pilot's license demonstrates that someone is a competent pilot you are very very mistaken, and there are scores of counter examples. 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.
throwaway151883 2y ago
> check if text has mismatched parens 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.
- __turbobrew__ 2y ago
  I run coding interviews at BIGCO. Half of the candidate success relies on the skills of the interviewer. A bad interviewer can bomb the best candidates. 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.
  - 3vidence 2y ago
    As an interviewer at Google, we arent given an exact list of questions to ask or what to evaluate (there are broad categories). 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
jjav 2y ago
> 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.
- al_borland 2y ago
  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.
  - ltbarcly3 2y 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.
    - jamesfinlayson 2y ago
      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.
Aeolun 2y ago
Dude, I have no idea what a stack is because I never studied computer science. It’s never held me back except during interviews with people that expected me to understand computer science fundamentals. 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.
GarnetFloride 2y ago
It's rather funny, but I wonder if you've ever been a Game Master? One of the most common problems running a game, is making the puzzles simple enough. You have to use kindergarten or back of the cereal box level puzzles or the players will fail. I played with engineers, it's a game, and there is nothing riding on the outcome and we often failed stupid simple puzzles. Interviews have a lot riding on them and yes stress is terrible. Stress eats working memory for breakfast, NASA learned that the hard way.
johnnyanmac 2y ago
At that point I have to ask if your screening is really working. There's hundreds, thousands of potential SWEs that can be productive, but you keep picking people who struggle with CS101 problems? 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?
fzeroracer 2y ago
Typically speaking, when you encounter a problem in excess I believe you should start to assume that perhaps the problem is on your side. 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.
genewitch 2y ago
You just reminded me I said it on a programming interview for Java one time and my friend was giving them the Fizzbuzz test. 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.

momocowcow 2y ago

You are still not testing if they can code. But whether under the scrutiny of another person, they can code. Maybe this is important to you, maybe peer programming is important to you for example. I remember a young dev who couldn’t pass such tests, as he would get too nervous, yet he had written the core tech for many shipped products. The type of guy you would just stick in dark room. With age this type of stuff settles down.

giantg2 2y ago
I agree with both you and the parent to some degree. I have experienced interviews that went badly because they were in an IDE I wasn't familiar with, or in Leetcode (never used it). So I'm distracted by how to use the tool rather than how to code the solution. But I can also see how stuff like finding a substring is easy - most languages have a function for it. But at that point, you're testing different things - problem-solving vs rote memorization of a provided function. 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.
- WalterBright 2y ago
  > rote memorization of a provided function. I never mesmerized strstr(). But using it frequently makes it stick in my mind.
  - giantg2 2y ago
    Not everyone uses it (or their language equivalent) frequently depending on the needs of their project. If I'm really using it frequently, then I would probably be looking at higher accuracy/resiliency options like parsing the input and comparing to a map, or regexes.
alabastervlog 2y ago
“Scrutiny of another” who’s a peer or even a client is super different from an interview. 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.
- WalterBright 2y ago
  My first attempts at public speaking were a frozen horror. But I kept doing it, and it kept getting easier and easier. 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.

mixmastamyk 2y ago

Some people are good coders but can’t do it with an adversarial person watching. I’m often one of them. Might as well put a suitcase with $200k and a copper clock ticking away on the table next to them.

bobthepanda 2y ago
As someone who does these types of interviews on both ends, something like this is why I like to start with an outrageously simple question to break the ice. 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.
- ltbarcly3 2y ago
  I just saw that this comment was fading from downvotes. 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.
  - gjm11 2y ago
    Elsewhere in this thread there is literally an example of someone who, by their own description, worked at a FAANG company for some years getting good performance reviews, has enough interview experience that even if they couldn't generally code their way out of a paper bag they were surely good at interview-question coding, ... and, under pressure from a pushy interviewer, completely failed to do a straightforward coding task. 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.

hibikir 2y ago

What is really crazy about this though is that sometimes it really is the interview setting, as people unused to interviews can, at times, emotionally collapse. I have seen people who are actually good programmers get wrecked by simple questions because of their inability to handle stress, and how the lack of interview practice turns a simple exercise into a hellscape. 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.

geoka9 2y ago
Not to imply that you're wrong, but I've always been bad at LC interviews, but surprisingly (for myself) passable when called upon to troubleshoot and code up a hot fix in the middle of the night. Maybe those are not entirely similar types of pressures.
- lubujackson 2y ago
  There is a big difference between solving a critical bug, which is your job, vs. passing an arbitrary leetcode test from a disinterested 22 year old where you might lose your house if you get it wrong. You have 15 minutes.
  - WalterBright 2y ago
    The cure for such fears is to: 1. study the leetcode books in advance 2. do lots of interviews In the military, there's a saying: train hard => fight easy
quinnirill 2y ago
It’s also not the same kind of stress. I’ve interviewed many a candidate who were sweating and/or shaking at some point of the interview (with heavy reassurance and me trying to to steer the conversation towards and area where they feel stronger), but they can often end up being calm and reliable alert responders nonetheless. So far I’ve seen very little if any correlation between being able to handle interview stress and on-call stress.

insane_dreamer 2y ago

Knowing the right answer and knowing the right answer with a gun to your head are two different skills.

ezekiel68 2y ago

The other replies to this comment aren't wrong but I feel they fail to take into account that (especially with startups): having someone watch you code during an interview is one of the the least stressful experiences the person will face with the company - once the job begins. Companies can't take on the risk of dealing with a bunch of passive-aggressive bullcrap once the real code reviews begin after the hire. Most tech job reqs contain the words "Excellent written and verbal communication skills" on purpose. Imagine a person with a pilot's license refusing to fly tandem for an airline interview.

acdha 2y ago
> 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.
- ltbarcly3 2y ago
  Go on youtube and watch NTSB / FAA investigation reports. If you think that a pilot's license demonstrates that someone is a competent pilot you are very very mistaken, and there are scores of counter examples. 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.

throwaway151883 2y ago

> check if text has mismatched parens 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.

__turbobrew__ 2y ago
I run coding interviews at BIGCO. Half of the candidate success relies on the skills of the interviewer. A bad interviewer can bomb the best candidates. 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.
- 3vidence 2y ago
  As an interviewer at Google, we arent given an exact list of questions to ask or what to evaluate (there are broad categories). 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

jjav 2y ago

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

al_borland 2y ago
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.
- ltbarcly3 2y 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.
  - jamesfinlayson 2y ago
    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.

Aeolun 2y ago

Dude, I have no idea what a stack is because I never studied computer science. It’s never held me back except during interviews with people that expected me to understand computer science fundamentals. 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.

GarnetFloride 2y ago

It's rather funny, but I wonder if you've ever been a Game Master? One of the most common problems running a game, is making the puzzles simple enough. You have to use kindergarten or back of the cereal box level puzzles or the players will fail. I played with engineers, it's a game, and there is nothing riding on the outcome and we often failed stupid simple puzzles. Interviews have a lot riding on them and yes stress is terrible. Stress eats working memory for breakfast, NASA learned that the hard way.

johnnyanmac 2y ago

At that point I have to ask if your screening is really working. There's hundreds, thousands of potential SWEs that can be productive, but you keep picking people who struggle with CS101 problems? 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?

fzeroracer 2y ago

Typically speaking, when you encounter a problem in excess I believe you should start to assume that perhaps the problem is on your side. 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.

genewitch 2y ago

You just reminded me I said it on a programming interview for Java one time and my friend was giving them the Fizzbuzz test. 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.