[oriolid]

It is widely believed that if you are able to do deep engineering you should also be able to get the basics right. It takes a lot of time evaluate a real world project and most of applicants would not agree to do one anyway, so basic CS is the easy approximation.

[eiopa]

What makes implementing qsort/bsearch/etc "the basics"? It seems rather arbitrary, and it mostly measures how well you are able to recite from CS books.

[mattkrause]

The weird thing is that some of the "basics" aren't even particularly basic. Finding cycles in a linked list was an open research problem for a while. One can argue that interviewees need to know about the Tortise and Hare algorithm, but it's crazy to think that someone who hasn't should be able to come up with it on the spot.

[oriolid]

They are the stuff you should understand anyway if you build software and are easy enough to figure out in an interview session if you have any analytical skill.

On the other hand, many so-called real world questions measure only how well you are able to recite from API documentation of interviewer's favourite framework or at best the language specification.

[sratner]

Yet it is certainly false that if you are able to get CS basics right, you will be any good at deep engineering.

[braythwayt]

I hope you mean that:

It is certainly false that if you are able to get CS basics right, you will NECESSARILY be any good at deep engineering.

There are people who get the basics right and are good at deep engineering. The question is whether one predicts the other.

[oriolid]

Just out of curiosity, can you give examples of people who have done so-called deep software engineering but stumble at the basic CS concepts?

[sratner]

Right; my "false" applies to the entire statement (if p then q).