>> How do you know? Every interview you conduct is for your team?
My apologies. I should have been more careful in making the claim. You are right in challenging me**.
>> What do you ask? If you want to challenge the status quo you have to offer a replicable alternative
I cannot share the specific problems publicly as then those become available for candidates to practice out, whereas the idea is to give them a fresh problem to think about. Further, the list of interviewers is often made available to the candidates ahead of the time, which can create a loophole as interviewers tend to have a relatively small set of problems they keep repeating for different candidates***.
In general however, I always use real-life problems. Similar examples from text books may perhaps be: (a) Find the day of the week for a given date, (b) Output a given number in textual form (e.g., 14630 -> Fourteen thousand, six hundred and thirty), (c) etc. Most of the problems I pose are motivated from actual use cases, while the remaining are taken from my own prior interviews as a candidate. As I noted before, each one is at best Big-O[N] in time complexity, just like the Fizz Buzz problem. I have brought in more complex ones only when testing for specialized skills for specialized positions.
I also focus a lot on fundamentals. There have been candidates hired for my own teams which could not fully solve the problem I posed, but who however were unambiguously going in the right direction and would not say anything wrong or stupid during their reasoning towards it. I chose to go ahead with them with some risks in my mind, however, these people proved to be stellar in performance. When fundamentals are understood well, gaps can be picked up on the job as well.
I still do stand by my original assertion that proxy problems can be avoided for interviewing. In general, the best method to solve a problem is to solve that problem itself and not another.
** Appendix: Here're the actual data points:
- For interviews within my own team where I have been an interviewer, my claim likely holds. However, this is a small number of hires (say around six-eight) so the error margins would be large. Also, I would not have information about false-rejects, hence '100% accuracy' cannot be claimed even in theory.
- I have been a interview 'bar raiser' at Amazon. Bar Raisers at Amazon are people highly trusted for interview outcome decisions and process control.
*** I have even had cases where (a) someone interviewed a candidate for a second time after a time gap and posed exactly the same problem, (b) a recruiter leaked out questions an interviewer asked frequently to the candidate.
My apologies. I should have been more careful in making the claim. You are right in challenging me**.
>> What do you ask? If you want to challenge the status quo you have to offer a replicable alternative
I cannot share the specific problems publicly as then those become available for candidates to practice out, whereas the idea is to give them a fresh problem to think about. Further, the list of interviewers is often made available to the candidates ahead of the time, which can create a loophole as interviewers tend to have a relatively small set of problems they keep repeating for different candidates***.
In general however, I always use real-life problems. Similar examples from text books may perhaps be: (a) Find the day of the week for a given date, (b) Output a given number in textual form (e.g., 14630 -> Fourteen thousand, six hundred and thirty), (c) etc. Most of the problems I pose are motivated from actual use cases, while the remaining are taken from my own prior interviews as a candidate. As I noted before, each one is at best Big-O[N] in time complexity, just like the Fizz Buzz problem. I have brought in more complex ones only when testing for specialized skills for specialized positions.
I also focus a lot on fundamentals. There have been candidates hired for my own teams which could not fully solve the problem I posed, but who however were unambiguously going in the right direction and would not say anything wrong or stupid during their reasoning towards it. I chose to go ahead with them with some risks in my mind, however, these people proved to be stellar in performance. When fundamentals are understood well, gaps can be picked up on the job as well.
I still do stand by my original assertion that proxy problems can be avoided for interviewing. In general, the best method to solve a problem is to solve that problem itself and not another.
** Appendix: Here're the actual data points:
- For interviews within my own team where I have been an interviewer, my claim likely holds. However, this is a small number of hires (say around six-eight) so the error margins would be large. Also, I would not have information about false-rejects, hence '100% accuracy' cannot be claimed even in theory.
- I have been a interview 'bar raiser' at Amazon. Bar Raisers at Amazon are people highly trusted for interview outcome decisions and process control.
*** I have even had cases where (a) someone interviewed a candidate for a second time after a time gap and posed exactly the same problem, (b) a recruiter leaked out questions an interviewer asked frequently to the candidate.