13 ms·

"Whether passing an algorithmic technical phone screen means you’re a great engineer is another matter entirely and hopefully the subject of a future post." Th

by graffic 10y ago

"Whether passing an algorithmic technical phone screen means you’re a great engineer is another matter entirely and hopefully the subject of a future post." This sentence plus the inverse correlation between experience and "interview performance" shown there. Makes a big smell about how biased are those interviews to themselves and not to real technical interviews. From the data it looks like the questions asked using that service are the ones you might learn in university and after many years not using them, that knowledge fades away because you're not using it. This is reinforced by MOOCs being the 101 of the subject they're dealing with. It would be interesting to see if there are trivia questions from 101 courses. The most obvious bias is in the clickbait title. Those 3K interviews are in a specific platform, meaning they're done in a specific way. So after checking their results it seems that interviews done using that service benefit people with fresh university or 101 lessons knowledge. What worries me more is the lack of improvement and perhaps the moral superiority of ending the article with a "these findings have done nothing to change interviewing.io’s core mission". It feels like the entire statistics game shown there was to feed back what they already knew.

wheaties 10y ago
Yes, because we all know that your ability to implement a red-black tree from memory has a direct correlation with your ability to implement some random business logic or CRUD app. Oh wait, they don't.
- blindhippo 10y ago
  I used to think along these lines. Then I started doing 10+ interviews a month and realized a very clear reality: basic CS knowledge and problem skills is far more important to me and my team then knowing how to slap together some semblance of a working CRUD system. I ask "algorithmic" questions, normally expressed as a legitimate business case (invent a real world problem, solution is implement some algorithm or use specific data structure). My warm up question typically is a simplistic "find the subset in a given collection that matches this specific criteria" (with a subtle implication of "do it efficiently"). The average coder should be able to solve this type of thing, on their own, in about 10 minutes max, 15 with some feedback on improvements. Yet, 80% of my candidates take nearly 45 minutes and cannot deliver a workable solution without massive handholding, and I don't even get to my higher order, "real questions". The scenario of a coder who can't solve my warm-up being let loose on code I actively maintain makes my stomach churn. Until I see the average bar for problem solving go up, I'm going to keep asking basic CS questions in my coding interviews. The job is to solve complex, typically ambiguous problems. Coding is one of the tools - and I want peers who understand the theory behind using those tools. (I should note, I tend not to pay attention to credentials on a resume. I care more about ability to do the job then past history - though if a candidate has a masters in some field of CS, I might delve into it a bit out of curiosity... they are an expert afterall)
  - FLUX-YOU 10y ago
    >The average coder should be able to solve this type of thing, on their own, in about 10 minutes max, 15 with some feedback on improvements. >Yet, 80% of my candidates take nearly 45 minutes and cannot deliver a workable solution without massive handholding, and I don't even get to my higher order, "real questions". You need to ask yourself why you believe the "average coder" should be able to solve that because clearly your beliefs are not founded in reality. This is what I cannot understand about interviewers who are constantly frustrated with the population's skillset: You obviously have higher skill standards than the average. That is fine. Just accept you will have less hires because none of you are capable of fixing the entire population's skill levels.
    - timr 10y ago
      "You need to ask yourself why you believe the "average coder" should be able to solve that because clearly your beliefs are not founded in reality." Oh, stop. The problem he describes is trivial, and something that you'll encounter as an entry-level web developer on a regular basis. If you can't solve it, you're absolutely not up to the job. In fact, I'll go further: if you literally cannot find an efficient way to filter a list of stuff based on a criteria, you're not even a programmer yet. It doesn't matter if you've "written" a dozen toy webapps by stringing together NPM modules -- not knowing these basic things makes you a danger to any team that hires you. You can't judge the quality of a test exclusively by the number of people who fail it. If you resume screen for "has written code before" and 80% of your applicants fail that test, is your standard set too high? (In case you're wondering, that's not a hypothetical example.)
      - FLUX-YOU 10y ago
        Is he talking about this problem (with a filter at the end)? http://www.geeksforgeeks.org/finding-all-subsets-of-a-given-set-in-java/ http://www.geeksforgeeks.org/finding-all-subsets-of-a-given-... Because I have never done that. That's different than just running through a list and picking out items that meet a criteria.
- bmay 10y ago
  > implement a red-black tree from memory Can we quit using this ridiculous example? I'd be willing to bet that less than 1 in 100,000 technical interviews have asked someone to implement an r-b tree considering a full implementation is 100s of lines of code.

by graffic 10y ago

wheaties 10y ago

Yes, because we all know that your ability to implement a red-black tree from memory has a direct correlation with your ability to implement some random business logic or CRUD app. Oh wait, they don't.

blindhippo 10y ago
I used to think along these lines. Then I started doing 10+ interviews a month and realized a very clear reality: basic CS knowledge and problem skills is far more important to me and my team then knowing how to slap together some semblance of a working CRUD system. I ask "algorithmic" questions, normally expressed as a legitimate business case (invent a real world problem, solution is implement some algorithm or use specific data structure). My warm up question typically is a simplistic "find the subset in a given collection that matches this specific criteria" (with a subtle implication of "do it efficiently"). The average coder should be able to solve this type of thing, on their own, in about 10 minutes max, 15 with some feedback on improvements. Yet, 80% of my candidates take nearly 45 minutes and cannot deliver a workable solution without massive handholding, and I don't even get to my higher order, "real questions". The scenario of a coder who can't solve my warm-up being let loose on code I actively maintain makes my stomach churn. Until I see the average bar for problem solving go up, I'm going to keep asking basic CS questions in my coding interviews. The job is to solve complex, typically ambiguous problems. Coding is one of the tools - and I want peers who understand the theory behind using those tools. (I should note, I tend not to pay attention to credentials on a resume. I care more about ability to do the job then past history - though if a candidate has a masters in some field of CS, I might delve into it a bit out of curiosity... they are an expert afterall)
- FLUX-YOU 10y ago
  >The average coder should be able to solve this type of thing, on their own, in about 10 minutes max, 15 with some feedback on improvements. >Yet, 80% of my candidates take nearly 45 minutes and cannot deliver a workable solution without massive handholding, and I don't even get to my higher order, "real questions". You need to ask yourself why you believe the "average coder" should be able to solve that because clearly your beliefs are not founded in reality. This is what I cannot understand about interviewers who are constantly frustrated with the population's skillset: You obviously have higher skill standards than the average. That is fine. Just accept you will have less hires because none of you are capable of fixing the entire population's skill levels.
  - timr 10y ago
    "You need to ask yourself why you believe the "average coder" should be able to solve that because clearly your beliefs are not founded in reality." Oh, stop. The problem he describes is trivial, and something that you'll encounter as an entry-level web developer on a regular basis. If you can't solve it, you're absolutely not up to the job. In fact, I'll go further: if you literally cannot find an efficient way to filter a list of stuff based on a criteria, you're not even a programmer yet. It doesn't matter if you've "written" a dozen toy webapps by stringing together NPM modules -- not knowing these basic things makes you a danger to any team that hires you. You can't judge the quality of a test exclusively by the number of people who fail it. If you resume screen for "has written code before" and 80% of your applicants fail that test, is your standard set too high? (In case you're wondering, that's not a hypothetical example.)
    - FLUX-YOU 10y ago
      Is he talking about this problem (with a filter at the end)? http://www.geeksforgeeks.org/finding-all-subsets-of-a-given-set-in-java/ http://www.geeksforgeeks.org/finding-all-subsets-of-a-given-... Because I have never done that. That's different than just running through a list and picking out items that meet a criteria.
bmay 10y ago
> implement a red-black tree from memory Can we quit using this ridiculous example? I'd be willing to bet that less than 1 in 100,000 technical interviews have asked someone to implement an r-b tree considering a full implementation is 100s of lines of code.