11 ms·

I've interviewed and been interviewing for over a decade. I have had the displeasure of interviewing many people who have very impressive resumes yet when asked

by kronin 8y ago

I've interviewed and been interviewing for over a decade. I have had the displeasure of interviewing many people who have very impressive resumes yet when asked how they would judge their skillset in an area, and being told from them that they would say "expert", being shown exactly the opposite when it came time to answer some questions in that area. One data point... Senior engineer that founded the local java user group and wrote a published book on the java language. Couldn't code a simple reverse string algorithm, nor explain whether, after with help devising an answer, the method was thread-safe. Another data point... A self-described expert in SQL with it all over their resume. Couldn't write a simple join, inner outer or other. Weed-out questions exist because our industry is flooded with people who don't know, nor care to know, their craft. And there are plenty of employers who continue to hire these people, and promote them. I interviewed numerous "architects" (with development experience all over their resume) who couldn't come up with a naive solution, let alone the optimal, to a very simple problem. Want to fix the interview process in our industry? Figure out a way to weed out the liars? I'm all for it. I would rather not have to do basic algorithm questions, but that's the current environment.

deleted 8y ago
[deleted]
dom96 8y ago
I have very little experience with interviewing candidates, but how can you be certain these people were liars? Maybe they simply were having a bad day, or got too much in their head with stress during the interview. There are many factors at play when it comes to a bad performance and it's not always simply that the engineer doesn't know the answer.
- kronin 8y ago
  I give them a chance to judge their own skillset. After looking at their resume, I have an idea based on the projects they take credit for, what their experience level should be. If what they state lines up with their resume, and they are unable to answer a simple question, with multiple hints and help, then I absolutely assume they are a liar (edit: or delusional, which is even worse. An expectation I have of seniors and above is to have some idea of knowing what they don't know). It would be unreasonable for me to pass them through an interview that the other members on the team passed through based on "oh, they had a bad day". Since you haven't been on the other side of the table, have you had coworkers who obviously were at a position above their skill level? Who allowed the rest of their team to carry them? I've had periods wherey personal life has affected my productivity. That doesn't preclude my ability to write an algorithm that reverses a string nor write a simple SQL join. I don't ask brain teasers. I ask questions related to what the engineers under me will be expected to solve every day.
  - deleted 8y ago
    [deleted]
  - a-dub 8y ago
    How do you know that you're not just crap at interviewing? Assuming people are lying is both extreme and presumptuous, no? Also, are your people actually reversing strings by hand every day? I sure hope not!
    - kronin 8y ago
      Since you're attacking me, do you have any experience screening resumes? Phone screens? In-person interviews? Have you had the experience of a candidate that has apparently "done it all" on their resume, and confirmed their skill level when asked in-person, only to see them struggle with the simplest question in an area they deem themself an "expert" in? I've interviewed well over 300 people, for positions from junior/entry-level to principal. If you read many of the comments to this article you'll hear other people with experience interviewing who also call out that candidates can and do lie. I don't like it, I'd rather it not be the case. I constrain the majority of my questioning to what a candidate claims to know on their resume. Here's a tip... If you don't know it (and I'm not talking about bullshit trivia questions), then don't put it on your resume.
      - a-dub 8y ago
        Yup... and I don't know, for someone who has "300 people" worth of interview experience, you sure don't seem to be demonstrating in this thread the sort of level headed temperance and soft skills I would expect. I'm joking. (sorta) I'm glad to hear that you tailor to the resume, that's actually better than most and my favorite approach. But if I had a dollar for every time someone walked out of an interview with a braggadocious claim like "they couldn't even do X, they must be lying" but then answer "no" to "did you ask them anything else?". I'd be rich. Reversing a string is a bad example, it is dead easy. But it seems a lot of people have random substitutions for it of varying obscurity and difficulty.
        8y ago
- h1d 8y ago
  Handling their mental stability should be part of their skill. "Having a bad day" on a scheduled day sounds like almost bad management of ones self.
- rwmj 8y ago
  Back when I worked in an office and conducted interviews, I made a point of always having the candidate sit in front of a computer and solve some very simple problems. It's amazing the number of candidates with apparently strong CVs who simply did not know how to use a computer. I mean, people claiming Linux experience who didn't know how to type commands at the prompt, not even "ls". How were they expecting to get a Linux developer role?? Unfortunately you have to weed these people out, and this was the only way I found.
0x445442 8y ago
> Couldn't code a simple reverse string algorithm You were interviewing senior engineers with Java experience and they couldn't come up with Assert.assertEquals("radar",StringUtils.reverse("radar")); I suspect you were actually looking for the implementation of StringUtils.reverse() and if that's the case then you were focused on the wrong skills.
- kronin 8y ago
  It's the start of the coding interview. It moves on from there. This candidate didn't even ask if he could use Apache commons, and I hadn't yet specified that he couldn't use a 3rd party library. So yes. He failed on many counts. 1) not asking clarifying questions 2) not being familiar with some well-known libraries 3) not being able to implement a basic reverse string 4) not being able to explain whether or not a simple method was thread safe (with multi-threading experience all over his resume) I expect engineers, senior or otherwise, to be able to write code. If you can't do that, don't put it on your resume. If you honestly think implementing a reverse string method is "too complicated"... Edit: sorry, leaving the response as-is, but I recognize you didn't state "too complicated". You stated "focused on the wrong skills". I posit that an engineer that can't reverse a string, as a litmus test, will be likely unable to solve a more complicated problem.
  - 0x445442 8y ago
    If you're interviewing for some core, low level algorithm development then fair enough but I suspect if that's the case you could come up with something a little closer to the real life domain. It's not that I think the question is too complicated, just not the best marker. In my mind, more relevant questions are ones that demonstrate real life experience in the field. For example, populating a tree of objects in a high level language like Java from a DB where the tree of objects are stored as many to many relationships. You'd be surprised how many times I've run across production code which does this via SQL calls inside nested loops. This whole infatuation with algorithm questions like you'd find in SICP might be good for new grads but misses the mark for Senior level engineers.
    - 8y ago
borgfriend 8y ago
Why do you assume that the person is lying? Why do you start your relationship with your new co-worker on distrust? There is a way to weed out the liars - you hire them and then when it does not work out you fire them. You would be astonished how little people lie on their CV. They may exaggerate claims - yes, that is why you gave them a call in the first place. But then again you exaggerated your claims in the job posting of which skills are required for the job. The one thing that I noticed is that only the US companies have this awkward parallel reality 'technical-interview' hiring process. In other countries like Germany or France the interview process is mostly focused on the person and the desire to work for the company and the willingness to learn the skills needed for the job. Just because you fail to answer immediately to a random question it does not mean you are unqualified for the job. When I conduct an interview I try to only ask open questions like: * What is your favorite IDE? - Whatever the person answers, tells a lot about how he works, what tools he uses, and if he is aware of the common tools * What feature of the new Version of <Programming Language> do you like the most? - A) you may learn about some weird feature, b) you can discuss how that feature will improve code * Do you prefer JavaScript or TypeScript (dynamic vs typed language)? There is no right answer. It is all about how the candidate argues his answer. You learn more about the person and if you can deal with him on a day to day basis (and if he has the brains to think about things).
- yks 8y ago
  > Why do you assume that the person is lying? There was a blog post "Adventure in the Low Status of Software Engineers" by Michael Church (apparently taken down now), basically if you're interviewing for "low status" positions you're assumed to be a fraud but for "high status" positions (VP-level) you're assumed to be a great candidate even if your resumes are almost identical in both cases.
- kronin 8y ago
  > There is a way to weed out the liars - you hire them and then when it does not work out you fire them. In my experience, firing someone takes multiple months. Months in which they are mutating the codebase (with review, but it's a time sink that shouldn't exist for a decent senior), influencing other engineers, etc. Passing on a good candidate is cheaper in the long run than hiring a bad candidate. Or said another way, false negatives are preferred over false positives. > You would be astonished how little people lie on their CV. This has not been my experience. From something as white-lieish as "I designed and implemented" vs. "I was a peer on the team that did it" to flat out fabrications. You learn alot by simply asking "what was your role on the project" and asking follow-ups to dig into their contributions.
geebee 8y ago
Totally reasonable response. However, it seems like we're on an endless loop with this discussion. People talk about how they need technical interviews because someone who looks good on paper can't code reverse string, or write a basic join. But here's the thing, absolutely none of my technical interviews have involved anything remotely this simple. They are "find all matching matching subtrees in a binary search tree", or "find all possible matrices with a negative determinant within an NxM matrix of arbitrary size", and it's supposed to be done in about 45 minutes, at the whiteboard. Really, it's not fizz buzz or string reversal that causes people to re-study for their algorithms and data structures exam before an interview. In many ways, I think this is similar to requiring that senior actuaries re-study integration by parts prior to every interview. They don't have to, because they have a proper exam that is widely accepted in their field. We don't. So instead, we are taken through full day whiteboard exams, under conditions of great secrecy, over and over, every time we interview.
- linkregister 8y ago
  This is an excellent analogy. I've found that ability to complete esoteric algorithms problems has little relation to productivity in specialized subjects, as in network security.
- james_s_tayler 8y ago
  Did anyone stop to think that maybe, just maybe, in the allotted time there simply isn't enough bandwidth to accurately answer the question of whether the candidate can do the job and will be a good fit and that no matter what strategy you try that perhaps this is an optimization problem for which there is no good solution. Like this is it. As good as it gets. I actually think all this back and forth, chopping and changing, people arbitrarily weeding companies out, companies arbitrarily weeding people out is providing just the right amount of randomness for everyone to wind up somewhere. Hiring is mostly random.
cwyers 8y ago
So, I agree you want to see evidence of what's on the resume. But why isn't an actual work project of some sort better than whiteboard coding exercises?
sgustard 8y ago
As a hiring manager, I agree 100%. These people are everywhere. I've also given someone the benefit of the doubt -- he wrote a Java book! once we hire him, I'm sure it will work out -- only to find, nope, he can't code on the job either. Other hand, I'd suggest instead of "lying" that people are just myopic about their skill sets. I'd been writing JavaScript code for years, for example, but on an interview learned about a whole world of "modern" JavaScript that I didn't know existed. Clearly they thought I was a fraud. But I'd just been living on the 3rd floor without ever visiting the basement where all the pipes and boilers were.
jeklj 8y ago
It’s really incredible how common those people are, and how they’ve managed to eke out a living. The thing that has surprised me most is that there is no predictability to how a candidate will perform on a simple programming exercise, new grads are equally likely to pass as people with 15 years’ experience. (The failure modes are different though, new grads spend lots of time talking through every variable assignment etc; experienced people tend to throw every technique at the wall when they encounter an issue instead of slowing down and thinking through what they’re doing)

by kronin 8y ago

deleted 8y ago

[deleted]

dom96 8y ago

I have very little experience with interviewing candidates, but how can you be certain these people were liars? Maybe they simply were having a bad day, or got too much in their head with stress during the interview. There are many factors at play when it comes to a bad performance and it's not always simply that the engineer doesn't know the answer.

kronin 8y ago
I give them a chance to judge their own skillset. After looking at their resume, I have an idea based on the projects they take credit for, what their experience level should be. If what they state lines up with their resume, and they are unable to answer a simple question, with multiple hints and help, then I absolutely assume they are a liar (edit: or delusional, which is even worse. An expectation I have of seniors and above is to have some idea of knowing what they don't know). It would be unreasonable for me to pass them through an interview that the other members on the team passed through based on "oh, they had a bad day". Since you haven't been on the other side of the table, have you had coworkers who obviously were at a position above their skill level? Who allowed the rest of their team to carry them? I've had periods wherey personal life has affected my productivity. That doesn't preclude my ability to write an algorithm that reverses a string nor write a simple SQL join. I don't ask brain teasers. I ask questions related to what the engineers under me will be expected to solve every day.
- deleted 8y ago
  [deleted]
- a-dub 8y ago
  How do you know that you're not just crap at interviewing? Assuming people are lying is both extreme and presumptuous, no? Also, are your people actually reversing strings by hand every day? I sure hope not!
  - kronin 8y ago
    Since you're attacking me, do you have any experience screening resumes? Phone screens? In-person interviews? Have you had the experience of a candidate that has apparently "done it all" on their resume, and confirmed their skill level when asked in-person, only to see them struggle with the simplest question in an area they deem themself an "expert" in? I've interviewed well over 300 people, for positions from junior/entry-level to principal. If you read many of the comments to this article you'll hear other people with experience interviewing who also call out that candidates can and do lie. I don't like it, I'd rather it not be the case. I constrain the majority of my questioning to what a candidate claims to know on their resume. Here's a tip... If you don't know it (and I'm not talking about bullshit trivia questions), then don't put it on your resume.
    - a-dub 8y ago
      Yup... and I don't know, for someone who has "300 people" worth of interview experience, you sure don't seem to be demonstrating in this thread the sort of level headed temperance and soft skills I would expect. I'm joking. (sorta) I'm glad to hear that you tailor to the resume, that's actually better than most and my favorite approach. But if I had a dollar for every time someone walked out of an interview with a braggadocious claim like "they couldn't even do X, they must be lying" but then answer "no" to "did you ask them anything else?". I'd be rich. Reversing a string is a bad example, it is dead easy. But it seems a lot of people have random substitutions for it of varying obscurity and difficulty.
      - 8y ago
h1d 8y ago
Handling their mental stability should be part of their skill. "Having a bad day" on a scheduled day sounds like almost bad management of ones self.
rwmj 8y ago
Back when I worked in an office and conducted interviews, I made a point of always having the candidate sit in front of a computer and solve some very simple problems. It's amazing the number of candidates with apparently strong CVs who simply did not know how to use a computer. I mean, people claiming Linux experience who didn't know how to type commands at the prompt, not even "ls". How were they expecting to get a Linux developer role?? Unfortunately you have to weed these people out, and this was the only way I found.

0x445442 8y ago

> Couldn't code a simple reverse string algorithm You were interviewing senior engineers with Java experience and they couldn't come up with Assert.assertEquals("radar",StringUtils.reverse("radar")); I suspect you were actually looking for the implementation of StringUtils.reverse() and if that's the case then you were focused on the wrong skills.

kronin 8y ago
It's the start of the coding interview. It moves on from there. This candidate didn't even ask if he could use Apache commons, and I hadn't yet specified that he couldn't use a 3rd party library. So yes. He failed on many counts. 1) not asking clarifying questions 2) not being familiar with some well-known libraries 3) not being able to implement a basic reverse string 4) not being able to explain whether or not a simple method was thread safe (with multi-threading experience all over his resume) I expect engineers, senior or otherwise, to be able to write code. If you can't do that, don't put it on your resume. If you honestly think implementing a reverse string method is "too complicated"... Edit: sorry, leaving the response as-is, but I recognize you didn't state "too complicated". You stated "focused on the wrong skills". I posit that an engineer that can't reverse a string, as a litmus test, will be likely unable to solve a more complicated problem.
- 0x445442 8y ago
  If you're interviewing for some core, low level algorithm development then fair enough but I suspect if that's the case you could come up with something a little closer to the real life domain. It's not that I think the question is too complicated, just not the best marker. In my mind, more relevant questions are ones that demonstrate real life experience in the field. For example, populating a tree of objects in a high level language like Java from a DB where the tree of objects are stored as many to many relationships. You'd be surprised how many times I've run across production code which does this via SQL calls inside nested loops. This whole infatuation with algorithm questions like you'd find in SICP might be good for new grads but misses the mark for Senior level engineers.
  - 8y ago

borgfriend 8y ago

Why do you assume that the person is lying? Why do you start your relationship with your new co-worker on distrust? There is a way to weed out the liars - you hire them and then when it does not work out you fire them. You would be astonished how little people lie on their CV. They may exaggerate claims - yes, that is why you gave them a call in the first place. But then again you exaggerated your claims in the job posting of which skills are required for the job. The one thing that I noticed is that only the US companies have this awkward parallel reality 'technical-interview' hiring process. In other countries like Germany or France the interview process is mostly focused on the person and the desire to work for the company and the willingness to learn the skills needed for the job. Just because you fail to answer immediately to a random question it does not mean you are unqualified for the job. When I conduct an interview I try to only ask open questions like: * What is your favorite IDE? - Whatever the person answers, tells a lot about how he works, what tools he uses, and if he is aware of the common tools * What feature of the new Version of <Programming Language> do you like the most? - A) you may learn about some weird feature, b) you can discuss how that feature will improve code * Do you prefer JavaScript or TypeScript (dynamic vs typed language)? There is no right answer. It is all about how the candidate argues his answer. You learn more about the person and if you can deal with him on a day to day basis (and if he has the brains to think about things).

yks 8y ago
> Why do you assume that the person is lying? There was a blog post "Adventure in the Low Status of Software Engineers" by Michael Church (apparently taken down now), basically if you're interviewing for "low status" positions you're assumed to be a fraud but for "high status" positions (VP-level) you're assumed to be a great candidate even if your resumes are almost identical in both cases.
kronin 8y ago
> There is a way to weed out the liars - you hire them and then when it does not work out you fire them. In my experience, firing someone takes multiple months. Months in which they are mutating the codebase (with review, but it's a time sink that shouldn't exist for a decent senior), influencing other engineers, etc. Passing on a good candidate is cheaper in the long run than hiring a bad candidate. Or said another way, false negatives are preferred over false positives. > You would be astonished how little people lie on their CV. This has not been my experience. From something as white-lieish as "I designed and implemented" vs. "I was a peer on the team that did it" to flat out fabrications. You learn alot by simply asking "what was your role on the project" and asking follow-ups to dig into their contributions.

geebee 8y ago

Totally reasonable response. However, it seems like we're on an endless loop with this discussion. People talk about how they need technical interviews because someone who looks good on paper can't code reverse string, or write a basic join. But here's the thing, absolutely none of my technical interviews have involved anything remotely this simple. They are "find all matching matching subtrees in a binary search tree", or "find all possible matrices with a negative determinant within an NxM matrix of arbitrary size", and it's supposed to be done in about 45 minutes, at the whiteboard. Really, it's not fizz buzz or string reversal that causes people to re-study for their algorithms and data structures exam before an interview. In many ways, I think this is similar to requiring that senior actuaries re-study integration by parts prior to every interview. They don't have to, because they have a proper exam that is widely accepted in their field. We don't. So instead, we are taken through full day whiteboard exams, under conditions of great secrecy, over and over, every time we interview.

linkregister 8y ago
This is an excellent analogy. I've found that ability to complete esoteric algorithms problems has little relation to productivity in specialized subjects, as in network security.
james_s_tayler 8y ago
Did anyone stop to think that maybe, just maybe, in the allotted time there simply isn't enough bandwidth to accurately answer the question of whether the candidate can do the job and will be a good fit and that no matter what strategy you try that perhaps this is an optimization problem for which there is no good solution. Like this is it. As good as it gets. I actually think all this back and forth, chopping and changing, people arbitrarily weeding companies out, companies arbitrarily weeding people out is providing just the right amount of randomness for everyone to wind up somewhere. Hiring is mostly random.

cwyers 8y ago

So, I agree you want to see evidence of what's on the resume. But why isn't an actual work project of some sort better than whiteboard coding exercises?

sgustard 8y ago

As a hiring manager, I agree 100%. These people are everywhere. I've also given someone the benefit of the doubt -- he wrote a Java book! once we hire him, I'm sure it will work out -- only to find, nope, he can't code on the job either. Other hand, I'd suggest instead of "lying" that people are just myopic about their skill sets. I'd been writing JavaScript code for years, for example, but on an interview learned about a whole world of "modern" JavaScript that I didn't know existed. Clearly they thought I was a fraud. But I'd just been living on the 3rd floor without ever visiting the basement where all the pipes and boilers were.

jeklj 8y ago

It’s really incredible how common those people are, and how they’ve managed to eke out a living. The thing that has surprised me most is that there is no predictability to how a candidate will perform on a simple programming exercise, new grads are equally likely to pass as people with 15 years’ experience. (The failure modes are different though, new grads spend lots of time talking through every variable assignment etc; experienced people tend to throw every technique at the wall when they encounter an issue instead of slowing down and thinking through what they’re doing)