5 ms·

One thing about interviewing that surprises and confuses me is the number of people who seemingly can't program despite working as programmers or having a maste

One thing about interviewing that surprises and confuses me is the number of people who seemingly can't program despite working as programmers or having a master's in CS. My "FizzBuzz" coding question that I ask on phone screens is "Write a function that takes a string and returns a list containing the most frequent character." It has a few clarifications that are needed and I expect the person to ask about (What if there is no most frequent character like in an empty string (return an empty list), multiple characters equally frequent (each equally frequent character should be in the returned list once), etc) and has some basic logic requirements. I am continuously astounded when people can't do this. I encourage them to use the language they're most comfortable with. I give them time to think about the problem, encourage them to ask questions etc. If they seem stuck I'll ask them to walk me through what they're thinking about, etc. I've had multiple people with master's degrees in CS or with years of professional programming experience get stumped by this problem and it just makes zero sense to me. I took undergraduate CS courses and this would've been an easy problem in those classes. I was a TA in an undergraduate intro to programming course and I would've expected all of my students to be able to solve this problem in similar circumstances. It seems to me like someone with a Master's degree in math has come in and I'm asking them to "solve for x" in the kind of equation you might give to an eighth grader and they're unable to do it.

listenallyall 6y ago
"A list containing the most frequent character." There's only one (not counting ties), so you want a single-item list? Or if 's' is the most frequent, because there are 5 of them, do you want [s, s, s, s, s]? Or since the list just needs to contain the most frequent character, seems like [r, s, t] would be correct as well. Now that I think about it, just returning the original string would have to contain the most frequent character. Also, do capital and lowercase of the same letter count as different characters? Just seems like a rather unclear directive.
- ALittleLight 6y ago
  Yes, it's supposed to be unclear because I expect the candidate to clarify the requirements. Jumping in to implementing something would be a bad move. Asking questions like these would be a good first step. I think of it as the FizzBuzz version of getting requirements for the thing you're supposed to be doing.
  - listenallyall 6y ago
    Alright so give me the damn job! Covid has screwed me over, I'll start Monday
  - dakiol 6y ago
    Oh, I hate this. I get your point but as a potential new hire of your company I'm also interviewing you. This means that if you state a problem in a very ambiguous way (like you did in your first message) that's already a red flag for me. Sure, I don't expect 100% accuracy in your problem statement, but I don't expect either lazynnes for the sake of "let's see if the interviewer asks good questions before implementing anything". Expect professionalism from both parts.
    - ip26 6y ago
      Both sides have a point. Perhaps your parent runs a shop where ambiguous requirements are one of the biggest problems they face, whereas you prefer to work in roles where the requirements are already established and you focus on working within them.
    - ALittleLight 6y ago
      That's fine. I don't think every job is a fit for every person or vice versa. Your reaction is a positive one for my question - if you don't want to work where you have to clarify ambiguous requirements then you wouldn't want to work for the company I'm at, and it's best we figure that out as early as possible, like in the phone screen.
  - lambdatronics 6y ago
    >Jumping in to implementing something would be a bad move. I would expect a skilled programmer to be be able to make intelligent inferences about the intended behavior in the face of ambiguous problem statements. FWIW, I would probably explain my reasoning as I went -- would you interrupt a candidate to say you'd rather see a different behavior (ex: my prototype would return a list with an empty string, but maybe you'd rather an empty list), or just silently judge them? Also, it look me about 2 minutes to produce a reasonable prototype -- maybe if the challenge were harder I'd expect someone to ask more questions up front, but in this case it's trivial to iterate. If the only thing you are testing for is the instinct to clarify unclear requirements, you'll surprise people who are used to the leetcode-style, thereby getting false negatives. It's just as much a trick question then, just in a different dimension.
returningfory2 6y ago
Earlier this year I had an experience where I was the interviewee in the situation you describe, and it was very humbling. I had just received offers from two FAANGs, and I was flown into the Bay Area to interview at a third. One of the interviews was mostly behavioral, with 20 mins at the end for an algorithms problem that I had done before on LeetCode. I did so badly that after 20 minutes the only thing on the whiteboard was the problem statement. I still remember the interviewer taking a picture of it, and me kind of cringing because of how bad it looked. I didn't get an offer, unsurprisingly.
jpgvm 6y ago
This happens to me in interviews when either I'm too exhausted to be interviewing or I'm just having a really off day. It should be obvious from my Github and general OSS contributions I can code and do meaningful things but sometimes I just can't code on-demand. Unfortunately people tire me very quickly, I have a limited budget of people time per-day and interviews frequently blow that budget early in the day yet continue into the afternoon (talking particulary onsites for bay area companies here). I would say 9/10 I manage fine but there have been occasions especially when I have been in between jobs and taking lots of interviews when I have just bombed because a particular company stacked all the code heavy interviews late into the panel. Separately from that speaking as a hiring manager for several roles I don't think coding on demand is a good metric. I don't expect people to do it once hired so it's not useful as a measurement of their fitness for the role either. Design heavy interview questions on the other hand I find very useful. They generally are less specific and speak more to experience, knowledge and taste. Things that are very relevant in an engineers real-world productivity. They are very punishing vs code on-demand interviews for new grads though so if your pipeline expects to take a lot of new grads you may need a different approach. However in my experience questions like "How would you architect a replacement of Amazons S3 service with similar durability" or "Given a smart grid reporting metrics from every home in the US how would you store this data for analysing both long-term trends and intra-day anomalies" yield by far the best signal to noise ratio.
- izacus 6y ago
  > It should be obvious from my Github and general OSS contributions I can code and do meaningful things but sometimes I just can't code on-demand. This isn't obvious at all - I've interviewed many people that have faked their GitHubs or were just completely incompetent at software development despite their amazing GH, OSS profiles or CVs. People lie, a lot. I'm sorry, but having "a profile" isn't a useful signal for an interviewer :( > However in my experience questions like "How would you architect a replacement of Amazons S3 service with similar durability" or "Given a smart grid reporting metrics from every home in the US how would you store this data for analysing both long-term trends and intra-day anomalies" yield by far the best signal to noise ratio. Agreed, in my experience these questions give by far the best signal for a good coworker in general. Sadly they're not appropriate to interview junior developers.
noodlesUK 6y ago
I was often shocked by this as well, until I did an interview where I was asked a similarly trivial question, and I became that person. I completely flubbed the interview, locked up, and, whilst I could write code that did things, I just couldn’t wrap my head around the question, and no amount of effort would chill me out. Obviously I didn’t land the thing. Some things like fizz buzz are gonna be so trivially easy that anyone should be able to do it, but try to understand where your candidate’s headspace is. (I was also a TA in a course that did these sorts of trivial challenges, and going through that experience really made me take a hard look at how I perceived those 1st year students)
- ALittleLight 6y ago
  I proposed to my manager (although this proposal was rejected) that we try something like putting our high performers through our interview loops. This would let us calibrate our questions and answers. If you're right, that intermittently otherwise good candidates flub simple questions, I feel like that would come up in the test interviews - and maybe there could be a good compromise that somehow takes this into account.
  - noodlesUK 6y ago
    Unfortunately, I think that whilst it's a good idea to run a few mock interviews with "known good" people who already work well within the company, I also think that you can't replicate the stress that a potential candidate might feel where the stakes are non-existent, and a rapport already exists between interviewer and interviewee.
    - mattm 6y ago
      A good rule of thumb I've heard is that for an hour interview, you should expect people that work for you to solve and complete it in about 20 minutes. If it takes them longer than that, the question will be too difficult for candidates once stress is factored in.
- dcolkitt 6y ago
valuearb 6y ago
I write code like this all day long and the way you phrase the question might have stumped me. First, I would feel like if I have to ask questions if you then I’m missing something obvious you want me to be able to deduce. And if I take too long I’d fail your test. So I’d jump in merrily and work up a quick and dirty version before even realizing that the output has ambiguities. Hopefully at that point I’d ask how you want them resolved, but maybe I decide you want to see me to make my own decisions and I’d come up with my own way to handle them.
- ajkjk 6y ago
  I dunno, I'm sympathetic to interview questions being weirdly hard cause of the stress, but that question would be something I could solve in less than 60 seconds in several languages. I think it's fair to expect people to ace it without difficulty.
RandoHolmes 6y ago
I once had someone ask me a question like this on the phone and I failed. Do you know why? Because they disqualified themselves from hiring me. What I remember from that phone screen was getting mentally _TIRED_, sighing, and then lying about not being able to do it. Seriously, don't fucking ask me to describe code or algorithms over the phone. The number of times I've had someone do some variation of this over my lifetime is such that I don't want to have you as a co-worker or a manager. Do you know why I have this attitude? Because the number of times I've seen people actively be wrong in what they're looking for, as in technically wrong and therefore I failed, is enough that I've decided if you think this is the right way to go about hiring, you're doing it wrong and I don't want to be in that hellhole.
- ALittleLight 6y ago
  That doesn't seem like a fair restriction to put on an interviewer to me. I'm just supposed to assume the candidate knows how to write code rather than ask them to demonstrate? I imagine if I was hiring someone to play in a band or sing in a choir it would probably be a good idea to ask them to play or sing a bit before extending an offer. If I was hiring someone to work at plumbing company, I'd probably ask them a "How would you fix..." type question or two. Saying that these questions are forbidden just because you are sometimes tired of doing them strikes me as unreasonable. While, of course, you get to decide what signals would make a company a bad fit for you - e.g. if I asked you my question you might think my company would be a bad fit for you, the interviewer decides which answers are a bad fit for the company. I would definitely take an answer like this as indicating a bad fit for the company. This line from your comment is interesting to me though: "I've seen people actively be wrong in what they're looking for, as in technically wrong and therefore I failed". I frequently ask questions where I expect the candidate to want to clarifications or challenge what I'm saying. That's part of my job, and I'm trying to test for it the best way I know how. If you're happy with your job interviewing performance, then more power to you, but if you aren't - you may consider changing how you think about instances where the interviewer is wrong. Perhaps they are presenting opportunities for you to engage with them in a productive way, and even if they aren't doing so intentionally, maybe they are doing so unintentionally.
random42_ 6y ago
A thing that happens to me is that, even though the problem is not hard, the interviewer attitude puts me off. More often than not the interviewers are arrogant and act like they don’t want to be there - and the make sure I am aware of that. That is enough to make me get things wrong and fail.

listenallyall 6y ago

"A list containing the most frequent character." There's only one (not counting ties), so you want a single-item list? Or if 's' is the most frequent, because there are 5 of them, do you want [s, s, s, s, s]? Or since the list just needs to contain the most frequent character, seems like [r, s, t] would be correct as well. Now that I think about it, just returning the original string would have to contain the most frequent character. Also, do capital and lowercase of the same letter count as different characters? Just seems like a rather unclear directive.

ALittleLight 6y ago
Yes, it's supposed to be unclear because I expect the candidate to clarify the requirements. Jumping in to implementing something would be a bad move. Asking questions like these would be a good first step. I think of it as the FizzBuzz version of getting requirements for the thing you're supposed to be doing.
- listenallyall 6y ago
  Alright so give me the damn job! Covid has screwed me over, I'll start Monday
- dakiol 6y ago
  Oh, I hate this. I get your point but as a potential new hire of your company I'm also interviewing you. This means that if you state a problem in a very ambiguous way (like you did in your first message) that's already a red flag for me. Sure, I don't expect 100% accuracy in your problem statement, but I don't expect either lazynnes for the sake of "let's see if the interviewer asks good questions before implementing anything". Expect professionalism from both parts.
  - ip26 6y ago
    Both sides have a point. Perhaps your parent runs a shop where ambiguous requirements are one of the biggest problems they face, whereas you prefer to work in roles where the requirements are already established and you focus on working within them.
  - ALittleLight 6y ago
    That's fine. I don't think every job is a fit for every person or vice versa. Your reaction is a positive one for my question - if you don't want to work where you have to clarify ambiguous requirements then you wouldn't want to work for the company I'm at, and it's best we figure that out as early as possible, like in the phone screen.
- lambdatronics 6y ago
  >Jumping in to implementing something would be a bad move. I would expect a skilled programmer to be be able to make intelligent inferences about the intended behavior in the face of ambiguous problem statements. FWIW, I would probably explain my reasoning as I went -- would you interrupt a candidate to say you'd rather see a different behavior (ex: my prototype would return a list with an empty string, but maybe you'd rather an empty list), or just silently judge them? Also, it look me about 2 minutes to produce a reasonable prototype -- maybe if the challenge were harder I'd expect someone to ask more questions up front, but in this case it's trivial to iterate. If the only thing you are testing for is the instinct to clarify unclear requirements, you'll surprise people who are used to the leetcode-style, thereby getting false negatives. It's just as much a trick question then, just in a different dimension.

returningfory2 6y ago

Earlier this year I had an experience where I was the interviewee in the situation you describe, and it was very humbling. I had just received offers from two FAANGs, and I was flown into the Bay Area to interview at a third. One of the interviews was mostly behavioral, with 20 mins at the end for an algorithms problem that I had done before on LeetCode. I did so badly that after 20 minutes the only thing on the whiteboard was the problem statement. I still remember the interviewer taking a picture of it, and me kind of cringing because of how bad it looked. I didn't get an offer, unsurprisingly.

jpgvm 6y ago

This happens to me in interviews when either I'm too exhausted to be interviewing or I'm just having a really off day. It should be obvious from my Github and general OSS contributions I can code and do meaningful things but sometimes I just can't code on-demand. Unfortunately people tire me very quickly, I have a limited budget of people time per-day and interviews frequently blow that budget early in the day yet continue into the afternoon (talking particulary onsites for bay area companies here). I would say 9/10 I manage fine but there have been occasions especially when I have been in between jobs and taking lots of interviews when I have just bombed because a particular company stacked all the code heavy interviews late into the panel. Separately from that speaking as a hiring manager for several roles I don't think coding on demand is a good metric. I don't expect people to do it once hired so it's not useful as a measurement of their fitness for the role either. Design heavy interview questions on the other hand I find very useful. They generally are less specific and speak more to experience, knowledge and taste. Things that are very relevant in an engineers real-world productivity. They are very punishing vs code on-demand interviews for new grads though so if your pipeline expects to take a lot of new grads you may need a different approach. However in my experience questions like "How would you architect a replacement of Amazons S3 service with similar durability" or "Given a smart grid reporting metrics from every home in the US how would you store this data for analysing both long-term trends and intra-day anomalies" yield by far the best signal to noise ratio.

izacus 6y ago
> It should be obvious from my Github and general OSS contributions I can code and do meaningful things but sometimes I just can't code on-demand. This isn't obvious at all - I've interviewed many people that have faked their GitHubs or were just completely incompetent at software development despite their amazing GH, OSS profiles or CVs. People lie, a lot. I'm sorry, but having "a profile" isn't a useful signal for an interviewer :( > However in my experience questions like "How would you architect a replacement of Amazons S3 service with similar durability" or "Given a smart grid reporting metrics from every home in the US how would you store this data for analysing both long-term trends and intra-day anomalies" yield by far the best signal to noise ratio. Agreed, in my experience these questions give by far the best signal for a good coworker in general. Sadly they're not appropriate to interview junior developers.

noodlesUK 6y ago

I was often shocked by this as well, until I did an interview where I was asked a similarly trivial question, and I became that person. I completely flubbed the interview, locked up, and, whilst I could write code that did things, I just couldn’t wrap my head around the question, and no amount of effort would chill me out. Obviously I didn’t land the thing. Some things like fizz buzz are gonna be so trivially easy that anyone should be able to do it, but try to understand where your candidate’s headspace is. (I was also a TA in a course that did these sorts of trivial challenges, and going through that experience really made me take a hard look at how I perceived those 1st year students)

ALittleLight 6y ago
I proposed to my manager (although this proposal was rejected) that we try something like putting our high performers through our interview loops. This would let us calibrate our questions and answers. If you're right, that intermittently otherwise good candidates flub simple questions, I feel like that would come up in the test interviews - and maybe there could be a good compromise that somehow takes this into account.
- noodlesUK 6y ago
  Unfortunately, I think that whilst it's a good idea to run a few mock interviews with "known good" people who already work well within the company, I also think that you can't replicate the stress that a potential candidate might feel where the stakes are non-existent, and a rapport already exists between interviewer and interviewee.
  - mattm 6y ago
    A good rule of thumb I've heard is that for an hour interview, you should expect people that work for you to solve and complete it in about 20 minutes. If it takes them longer than that, the question will be too difficult for candidates once stress is factored in.
dcolkitt 6y ago

valuearb 6y ago

I write code like this all day long and the way you phrase the question might have stumped me. First, I would feel like if I have to ask questions if you then I’m missing something obvious you want me to be able to deduce. And if I take too long I’d fail your test. So I’d jump in merrily and work up a quick and dirty version before even realizing that the output has ambiguities. Hopefully at that point I’d ask how you want them resolved, but maybe I decide you want to see me to make my own decisions and I’d come up with my own way to handle them.

ajkjk 6y ago
I dunno, I'm sympathetic to interview questions being weirdly hard cause of the stress, but that question would be something I could solve in less than 60 seconds in several languages. I think it's fair to expect people to ace it without difficulty.

RandoHolmes 6y ago

I once had someone ask me a question like this on the phone and I failed. Do you know why? Because they disqualified themselves from hiring me. What I remember from that phone screen was getting mentally _TIRED_, sighing, and then lying about not being able to do it. Seriously, don't fucking ask me to describe code or algorithms over the phone. The number of times I've had someone do some variation of this over my lifetime is such that I don't want to have you as a co-worker or a manager. Do you know why I have this attitude? Because the number of times I've seen people actively be wrong in what they're looking for, as in technically wrong and therefore I failed, is enough that I've decided if you think this is the right way to go about hiring, you're doing it wrong and I don't want to be in that hellhole.

ALittleLight 6y ago
That doesn't seem like a fair restriction to put on an interviewer to me. I'm just supposed to assume the candidate knows how to write code rather than ask them to demonstrate? I imagine if I was hiring someone to play in a band or sing in a choir it would probably be a good idea to ask them to play or sing a bit before extending an offer. If I was hiring someone to work at plumbing company, I'd probably ask them a "How would you fix..." type question or two. Saying that these questions are forbidden just because you are sometimes tired of doing them strikes me as unreasonable. While, of course, you get to decide what signals would make a company a bad fit for you - e.g. if I asked you my question you might think my company would be a bad fit for you, the interviewer decides which answers are a bad fit for the company. I would definitely take an answer like this as indicating a bad fit for the company. This line from your comment is interesting to me though: "I've seen people actively be wrong in what they're looking for, as in technically wrong and therefore I failed". I frequently ask questions where I expect the candidate to want to clarifications or challenge what I'm saying. That's part of my job, and I'm trying to test for it the best way I know how. If you're happy with your job interviewing performance, then more power to you, but if you aren't - you may consider changing how you think about instances where the interviewer is wrong. Perhaps they are presenting opportunities for you to engage with them in a productive way, and even if they aren't doing so intentionally, maybe they are doing so unintentionally.

random42_ 6y ago

A thing that happens to me is that, even though the problem is not hard, the interviewer attitude puts me off. More often than not the interviewers are arrogant and act like they don’t want to be there - and the make sure I am aware of that. That is enough to make me get things wrong and fail.