Actually I think this is exactly what a software engineer is. Knowing what datastructure to use in which situation because of its implementation details is important! Yes, it's not the only aspect of the job, but it's hugely important.
It can be as simple as Arrays vs. LinkedLists; where Arrays have zero cost access and LinkedLists have high indexing costs, but low constant time insertion costs where you don't know the content length. This can have huge effects on the performance of an application.
This is important to applications, and no, you don't have to implement the datastructure, but knowing which to use when and why can save you the time later from having to find all your performance problems.
In the binary education system in The Netherlands there are two types of universities, that which prepare people for industry jobs and that which prepare people for research. I went to both, the former has only a small focus on algorithms, complexity and datastructures. The latter has specific courses about those topics.
I think in practice you can often reach good enough performance without worrying about which algorithm or datastructure to use or what the complexity of your code is. There are many exceptions where those kind of skills are actually required, but it's easy to forget that software is a huge market and that a large portion of that market is people developing fairly uncomplicated applications.
You can create an incredible amount of value in the software industry without knowing much of computer science, but you are dependent on people who actually have that knowledge to create your tools, dependent libraries, used services, etc.
If you don't know whether to do CS or business administration, you might be able to do something in between, e.g. business administration with a IT specialisation.
(I got master degrees in Computer Science and Business Information Technology from the University of Twente and am currently a PhD student in Empowerment Informatics at the University of Tsukuba in Japan)
It's far more important that the code be simple, readable, and integrate easily with other teams' work.
Yeah, sure, in some domains latency isn't terribly important, but there certainly are a number of domains where it is.
I didn't read it as derision. I read it as an indication of a different focus between two areas of development. Microseconds don't matter in most cases. Milliseconds matter more often. Something optimized for microsecond-ish timing will make a tradeoff somewhere else (like code readability, generalness, etc).
Are you sure you don't mean 10 microseconds?
[0] http://stackoverflow.com/questions/17256040/how-fast-is-stat...
But then in the real world, arrays can still be faster than lists even when you're inserting a lot...
My point was more that understanding the semantics of the two types is important to how the program will run.
Ah, if only we could know how well the people do at the jobs they are hired to do.
9 times out of 10 that requires gut feel, subjectivity, biases, etc. Inverting binary trees is measurable and objective.
I give 60 minute programming exercise in a language of choice as the first part of the interview.
I do that part first because it separates the doers from talkers quickly. Measurable and objective.
Yes. Definitely.
Depending on the nature of the work I could see expanding this statement to include writing any part of the software. In other words, "the time they will spend writing code is asymptotically close to zero". This, BTW, is also the reason I don't care for discussions about text editor efficiency. In certain domains these can be rounding errors in the accounting of the totality of the work surrounding the production of solid, reliable and well documented software and the tools required to test, deploy, support, configure and sometimes port it.
I can't remember the last time I asked a candidate how they would detect a palindrome or traverse a tree. I could not care less. There are books and google for that. I want to know how they think, how they organize projects, what they prioritize, how they approach new problems, etc. I also want to know they understand how business works. I prefer people with entrepreneurial experience, even if they failed...particularly if they failed.
Depending on project type a team can easily spend 10x more time doing things other than actually typing code. In fact, they should spend 10x more time doing those things, for example, architecture, design, documentation, testing, etc.
This is not to say that computer science (CS) skills aren't important -- they are! But far too many companies base their hiring process around "are you a recent graduate from a top-tier CS school" rather than "can you do the work that needs to be done here?"
Being a software engineer is about way more than just knowing what algorithm to apply to solve a clearly-stated problem. You need to know how to build automated test suites, how to make software which is easy to deploy and maintain, and how to deal with the real world, where Things Go Wrong All The Time.
Having worked as a consultant for many years, with a large number of teams, I can say with some certainty that I would rather hire a person that had mediocre-at-best CS skills, but was otherwise a rock-solid software engineer.
Because the amount of time they will spend implementing graph-traversal algorithms is asymptotically close to zero.
They will instead spend pretty much all of their time needing to write code that other people can maintain.
Why would I spend the majority of the interview process focused on the former, rather than the latter?
Admittedly, this has given me quite an edge as a manager when it comes to hiring.
Because my hiring process focuses on "can this person do real-world work in a real-world context", I usually manage to find rather excellent engineers that other companies overlook.