4 ms·

The problem as I see it with focusing on history & people skills too much is a lot of the weak candidates are flat out lying about those kind of things. I've i

The problem as I see it with focusing on history & people skills too much is a lot of the weak candidates are flat out lying about those kind of things. I've interviewed more people in the last year than any previous year of my career. We found numerous candidates cheating on online coding tests. Weak candidates that fall flat on their face when asked to do something super simple like a FizzBuzz problem list massive accomplishments on their resumes. Often it seems like they are listing everything the team they worked on accomplished, not what they accomplished. And the weak candidates frequently list things like "Expert at Spring Framework" or "Expert at J2EE". To be an expert on those things is very rare since they are enormous frameworks. Not many strong candidates will list themselves as experts on giant projects unless they were one of the founders of the project. He is talking about filtering out developers with good technical skills who have other aspects of their personality/behavior that don't mesh with his business. But the bigger problem seems to be finding people who actually have real technical skills. The things he's worrying about are easier for management to correct/control.

yellowstuff 7y ago
Ability to invert a binary tree is not what you actually want to measure, but you can't bluff your way through it, so it's an attractive target to measure, especially at a large company trying to have standardized practices. Professional accomplishments is much closer to what you care about, but you can bluff. But it's still possible to give a good subjective interview. Good interviewers will find a area on someone's resume that they have deep knowledge of and drill deep. It takes longer to sniff out a complete fraud than FizzBuzz, but it can still be an effective approach.
- ben7799 7y ago
  Inverting a binary tree is actually something that weak candidates seem to find a way to cheat on though. Same thing with Fizzbuzz, so it was an artificial example in my post. The best thing for us seems to be relatively simple coding questions that are domain specific problems. My go-to the last year or so has been an interview like this: 1) Give a demo of the product 2) Explain a problem the product has/had to solve 3) Go over the entities/objects involved in the problem 4) Present this as a simplified whiteboard problem 5) Candidate needs to write some code on the board to solve the issue (Typical solutions < 20 lines of code) 6) Discuss scalability of the solution 7) Discuss alternate ways to refactor the larger code base to avoid having to write the algorithm that was written on the whiteboard at all The process of having to take a problem that comes from a specific product & translate that into code seems to catch the weak candidates that cheated on the online coding tests and bluffed the recruiter nearly every time. This is as opposed to places like Google that just constantly try to ramp up the difficulty of the non real-world coding questions they're asking the interviewee.

yellowstuff 7y ago

Ability to invert a binary tree is not what you actually want to measure, but you can't bluff your way through it, so it's an attractive target to measure, especially at a large company trying to have standardized practices. Professional accomplishments is much closer to what you care about, but you can bluff. But it's still possible to give a good subjective interview. Good interviewers will find a area on someone's resume that they have deep knowledge of and drill deep. It takes longer to sniff out a complete fraud than FizzBuzz, but it can still be an effective approach.

ben7799 7y ago
Inverting a binary tree is actually something that weak candidates seem to find a way to cheat on though. Same thing with Fizzbuzz, so it was an artificial example in my post. The best thing for us seems to be relatively simple coding questions that are domain specific problems. My go-to the last year or so has been an interview like this: 1) Give a demo of the product 2) Explain a problem the product has/had to solve 3) Go over the entities/objects involved in the problem 4) Present this as a simplified whiteboard problem 5) Candidate needs to write some code on the board to solve the issue (Typical solutions < 20 lines of code) 6) Discuss scalability of the solution 7) Discuss alternate ways to refactor the larger code base to avoid having to write the algorithm that was written on the whiteboard at all The process of having to take a problem that comes from a specific product & translate that into code seems to catch the weak candidates that cheated on the online coding tests and bluffed the recruiter nearly every time. This is as opposed to places like Google that just constantly try to ramp up the difficulty of the non real-world coding questions they're asking the interviewee.