Why do interviewers stress a lot on the knowledge of Data Structures and Algorithms for positions which don’t require a deep knowledge of them? | Hashnode
Recruiting is hard. If you don't have a yardstick by which to judge candidates then you are just taking them at their word that they know anything at all about anything that they say they do. Some people / organisations use the chalk'n'talk, solve this problem approach just to weed out the people that talk a good game but don't really understand shit about shit. No one, no organisation worth their salt is using it as the prime measure by which they will choose to make you an offer or not, as software engineers and their skills and experiences cover a far wider gamut and are far more complex than these kinds of tests / approaches uncover. After all, how can you be sure that they are not just simply incredibly nervous? You might be casting out a very fine engineer just because she or he finds it much, much harder to think about code without a keyboard and a computer - not that they need the internet or anything like that but simply that they think better with a console open in front of them.
When I recruit I DON'T use whiteboard algorithm tests, mostly because they overly favour recent graduates of "hard" computer science courses, and I have worked with far more software engineers who did not study CS than those that did, and because they can be prepared for in a superficial manner that does not necessarily show understanding. There are loads of books on "Cram for Whiteboard Questions" etc. - go and look on Amazon - there is little or no point using them, there are methods to get ready for them.
I get candidates to carry out a hypothetical coding task, one that should take no more than 4-6 hours, before I see them in person, and if their code is not up to scratch they don't get the face to face interview. That way the interview can be about their values, their understanding of best practice, their thoughts on the industry, new innovations, etc., rather than an on the spot explanation of a / the "knapsack problem" or Djikstra's Algorithm.
What I would say is that you would be surprised the number of uses that Data Structures and Algorithms can and will be put to use in the roles that you think don't need them, and if recruiting for a more senior role I will try to gauge the level of understanding amongst the candidates that I choose to see face to face on some of these issues, because a shared understanding of the CS domain, and a common lexicon about things is part of a team / organisation fit, if nothing else. If you can't explain to me the difference between an Array and a Hash (Associative Array in PHP, Dictionary in Python, Hash in Ruby, Map in Clojure etc.) then I am likely to make some not unreasonable assumptions about the depth to which you have considered your craft. More to the point, why have you not spent a couple of hours on finding this shit out, seeing as you make your living out of it.
General rule of thumb, if you don't get a job because of a bungled whiteboard exercise, make sure that you learn from it, there are plenty of companies that still recruit this way, but try to work for people who've realised that there is more to it than that. :-)
Oliver Godby
Professional Nerfherder and Code Wrangler
OK, here is the honest truth...
Recruiting is hard. If you don't have a yardstick by which to judge candidates then you are just taking them at their word that they know anything at all about anything that they say they do. Some people / organisations use the chalk'n'talk, solve this problem approach just to weed out the people that talk a good game but don't really understand shit about shit. No one, no organisation worth their salt is using it as the prime measure by which they will choose to make you an offer or not, as software engineers and their skills and experiences cover a far wider gamut and are far more complex than these kinds of tests / approaches uncover. After all, how can you be sure that they are not just simply incredibly nervous? You might be casting out a very fine engineer just because she or he finds it much, much harder to think about code without a keyboard and a computer - not that they need the internet or anything like that but simply that they think better with a console open in front of them.
When I recruit I DON'T use whiteboard algorithm tests, mostly because they overly favour recent graduates of "hard" computer science courses, and I have worked with far more software engineers who did not study CS than those that did, and because they can be prepared for in a superficial manner that does not necessarily show understanding. There are loads of books on "Cram for Whiteboard Questions" etc. - go and look on Amazon - there is little or no point using them, there are methods to get ready for them.
I get candidates to carry out a hypothetical coding task, one that should take no more than 4-6 hours, before I see them in person, and if their code is not up to scratch they don't get the face to face interview. That way the interview can be about their values, their understanding of best practice, their thoughts on the industry, new innovations, etc., rather than an on the spot explanation of a / the "knapsack problem" or Djikstra's Algorithm.
What I would say is that you would be surprised the number of uses that Data Structures and Algorithms can and will be put to use in the roles that you think don't need them, and if recruiting for a more senior role I will try to gauge the level of understanding amongst the candidates that I choose to see face to face on some of these issues, because a shared understanding of the CS domain, and a common lexicon about things is part of a team / organisation fit, if nothing else. If you can't explain to me the difference between an Array and a Hash (Associative Array in PHP, Dictionary in Python, Hash in Ruby, Map in Clojure etc.) then I am likely to make some not unreasonable assumptions about the depth to which you have considered your craft. More to the point, why have you not spent a couple of hours on finding this shit out, seeing as you make your living out of it.
General rule of thumb, if you don't get a job because of a bungled whiteboard exercise, make sure that you learn from it, there are plenty of companies that still recruit this way, but try to work for people who've realised that there is more to it than that. :-)