4 ms·

In terms of simply getting hired/passed the interview, yes, either a recent grad or someone having studied the algorithms prior to the interviews will probably

In terms of simply getting hired/passed the interview, yes, either a recent grad or someone having studied the algorithms prior to the interviews will probably do best. I won't argue it's annoying to study for an interview. I still think someone who understands these and has studied them will be in better shape to understand when/how to use such things in situations on the job (even if they can't be reproduced in a pop quiz scenario by the person). Maybe those situations will matter to the company, and maybe they won't.

ubernostrum 10y ago
Except you know this isn't how algorithm/data structure questions are used in interviews. What you're talking about is primarily a function of experience: seeing various situations over time and learning what works well and what doesn't. But these questions are used, quiz-style, as a barrier to even entry-level positions. So even if I grant you the possibility of some effective criterion being developed from algorithm and data-structure questions, the fact would remain that hardly anyone (and more likely no-one) uses them as you advocate. Getting these questions out of interviews and replacing them with metrics tailored to the desired job skills and responsibilities (rather than proxies for them, or even proxies for proxies for them, as is unfortunately usual in the industry), would be far more effective. Or perhaps more bluntly: I know of no other field which A) drills students on low-level fundamental techniques in school/training, and B) largely replaces them with higher-level techniques on the job which discourage use and thus continued top-of-mind retention of the low-level techniques, and C) nonetheless requires instantaneous unassisted perfect recall of all details of any arbitrarily-chosen low-level technique as a mandatory qualification for employment even into late stages of the career. Lawyers learn a lot about the law and its history and important cases, but they don't sit through pop quizzes of 15th-century English common-law rulings on every job interview for the rest of their lives, even though there probably are some such cases that would on occasion be useful to know. Doctors learn a lot of biology and chemistry, but if passing a closed-book organic-chem exam was a prerequisite for every job they'd take after med school we'd have a lot fewer employed doctors. Only programmers do this to themselves. Only programmers relentlessly demand that it be preserved as a gatekeeping ritual. Only programmers insist that "well, it's fundamental so it must be useful sooner or later" is a sufficient justification for doing this. It's time to stop doing this. It's time to stop supporting this. It's time to stop perpetuating this. (and getting back to my initial comment: there's a reason why bootcamps now have a "how to pass code interviews" unit, and a reason why Cracking the Coding Interview sells so well, and it's because these things have stopped having any useful purpose -- if indeed they ever had useful purpose -- and now serve as artificial barriers and ways to perpetuate biases about background while claiming objective grounds to disqualify people the interviewer doesn't want to hire, thus making life miserable for both the hired, who are likely to be inexperienced and easy to take advantage of, and the unhired, who have to try again or give up and find another way to make a living)
- jupiter90000 10y ago
  You're right, and I totally agree with you on what you're saying about the interview/job obtaining process, and that replacing the way this is done with something far more effective for interviews would be ideal. I also agree that actual experience using these types of things seems much more important than seeing if someone has drilled on quiz questions. The question then for me is, how does one assess if someone can use these things in practice to make a difference for the business? I don't have a good answer for that right now. If anyone here knows a nice approach to use to assess this type of skill, I'd like to know more (to stop perpetuating the usual 'algorithms gauntlet' approach).
  - sudshekhar 10y ago
    As somebody who passed out of university last year, I remember how we had to mug up most of the questions on this website (and practice topcoder + codeforces), so that interviewers could consider us smart. IMO, algorithmic interviews are maybe a good way to filter for motivation rather than anything else. Candidates who are likely to learn all this are more hardworking and career-consciuos (placements correlated pretty strongly with how much you 'knew'). That said, there was this one interview I had where the interviewer asked me how to design a distributed log collection service. Basically you have GBs of log files being generated on hundreds of servers and you want them sorted and stored on a single central database. What sort algo will you use, why? How to reduce transmitted over the network etc. It was a fun round and tested a lot of disparate concepts. To my inexperienced self, this seems like a good format: - First round: Ask stuff like fizz-buzz, trees, file I/O or string processing stuff. Basically ensure that they know how to code. Another way could be asking them to code the same question in functional, OOP and procedural styles - Second round: Discuss some project done by the candidate or ask them to design something from scratch. URL shorteners, databases, REST apis are normal candidates. Spreadsheets, DSLs etc might be good to make things harder. - Third round (If applicable) : Dig into any one specific domain most relevant to your company/team and make them architect* the whole thing. Ofcourse, any system, once its established and well-known, can be gamed. Banking on open source projects or past achievements is then what remains. * Very few entry levels jobs really require such skills but (IMO) it will help you get better engineers instead of coders.

ubernostrum 10y ago

Except you know this isn't how algorithm/data structure questions are used in interviews. What you're talking about is primarily a function of experience: seeing various situations over time and learning what works well and what doesn't. But these questions are used, quiz-style, as a barrier to even entry-level positions. So even if I grant you the possibility of some effective criterion being developed from algorithm and data-structure questions, the fact would remain that hardly anyone (and more likely no-one) uses them as you advocate. Getting these questions out of interviews and replacing them with metrics tailored to the desired job skills and responsibilities (rather than proxies for them, or even proxies for proxies for them, as is unfortunately usual in the industry), would be far more effective. Or perhaps more bluntly: I know of no other field which A) drills students on low-level fundamental techniques in school/training, and B) largely replaces them with higher-level techniques on the job which discourage use and thus continued top-of-mind retention of the low-level techniques, and C) nonetheless requires instantaneous unassisted perfect recall of all details of any arbitrarily-chosen low-level technique as a mandatory qualification for employment even into late stages of the career. Lawyers learn a lot about the law and its history and important cases, but they don't sit through pop quizzes of 15th-century English common-law rulings on every job interview for the rest of their lives, even though there probably are some such cases that would on occasion be useful to know. Doctors learn a lot of biology and chemistry, but if passing a closed-book organic-chem exam was a prerequisite for every job they'd take after med school we'd have a lot fewer employed doctors. Only programmers do this to themselves. Only programmers relentlessly demand that it be preserved as a gatekeeping ritual. Only programmers insist that "well, it's fundamental so it must be useful sooner or later" is a sufficient justification for doing this. It's time to stop doing this. It's time to stop supporting this. It's time to stop perpetuating this. (and getting back to my initial comment: there's a reason why bootcamps now have a "how to pass code interviews" unit, and a reason why Cracking the Coding Interview sells so well, and it's because these things have stopped having any useful purpose -- if indeed they ever had useful purpose -- and now serve as artificial barriers and ways to perpetuate biases about background while claiming objective grounds to disqualify people the interviewer doesn't want to hire, thus making life miserable for both the hired, who are likely to be inexperienced and easy to take advantage of, and the unhired, who have to try again or give up and find another way to make a living)

jupiter90000 10y ago
You're right, and I totally agree with you on what you're saying about the interview/job obtaining process, and that replacing the way this is done with something far more effective for interviews would be ideal. I also agree that actual experience using these types of things seems much more important than seeing if someone has drilled on quiz questions. The question then for me is, how does one assess if someone can use these things in practice to make a difference for the business? I don't have a good answer for that right now. If anyone here knows a nice approach to use to assess this type of skill, I'd like to know more (to stop perpetuating the usual 'algorithms gauntlet' approach).
- sudshekhar 10y ago
  As somebody who passed out of university last year, I remember how we had to mug up most of the questions on this website (and practice topcoder + codeforces), so that interviewers could consider us smart. IMO, algorithmic interviews are maybe a good way to filter for motivation rather than anything else. Candidates who are likely to learn all this are more hardworking and career-consciuos (placements correlated pretty strongly with how much you 'knew'). That said, there was this one interview I had where the interviewer asked me how to design a distributed log collection service. Basically you have GBs of log files being generated on hundreds of servers and you want them sorted and stored on a single central database. What sort algo will you use, why? How to reduce transmitted over the network etc. It was a fun round and tested a lot of disparate concepts. To my inexperienced self, this seems like a good format: - First round: Ask stuff like fizz-buzz, trees, file I/O or string processing stuff. Basically ensure that they know how to code. Another way could be asking them to code the same question in functional, OOP and procedural styles - Second round: Discuss some project done by the candidate or ask them to design something from scratch. URL shorteners, databases, REST apis are normal candidates. Spreadsheets, DSLs etc might be good to make things harder. - Third round (If applicable) : Dig into any one specific domain most relevant to your company/team and make them architect* the whole thing. Ofcourse, any system, once its established and well-known, can be gamed. Banking on open source projects or past achievements is then what remains. * Very few entry levels jobs really require such skills but (IMO) it will help you get better engineers instead of coders.