[BoiledCabbage]

And I hate to say it, but this right here is the problem with the industry.

You're expecting a junior dev to know and apply details of edge cases, complex character sets, runtime and space complexity, parallel processing and behavior of caching.

This is not junior level knowledge. You're looking for a mid-level to senior developer with zero experience. Yes it's possible to find, but that's not junior level knowledge. But most of them all things that are easily learn-able on the job. You're expecting a junior dev to be familiar with and easily able to apply all aspects of software development but just not have done it. This is absurd.

A junior dev should be able to handle bug fixes, well scoped and defined features, and have a small area of ownership. Guess what, they're working for you, they need to find the 5 largest elements in an array. The sort the entire thing and then take the top 5. They send their code for code review. You have a 5 min conversation with them on how you don't need to sort the full thing. They say "ah that's cool, hadn't seen that trick before". They now implement it and know it for life.

This absurd idea that you wouldn't hire this person instead of investing in a 5 min conversation with them is a large part of the problem with the industry.

[JCSato]

My thoughts kinda echo this, but I don't think it's outlandish for a junior dev to know a lot of this - what's less reasonable is knowing it with enough depth that they can bring it all to bear without prep in an interview. They've had fewer opportunities to put these things into practice, so I'd only expect them to demonstrate proficiency if they knew ahead of time to study those fairly specifically.

[jfasi]

Exactly. In junior interview I accept passing mentions and hand-wavey verbal solutions. What I'm referring to here is a complete absence of awareness of these things.

[jfasi]

I should be clear, I'm not expecting someone to write up a bulletproof solution to every possible edge case on a whiteboard in 35 minutes. I expect them simply to be familiar with the things that can go wrong. Add a check at the beginning to return false if the array is empty. Tell me your solution will get hairy if I expect you to handle Unicode, have a three-sentence exchange with me as to why, and implement an ASCII-only solution as a first pass.

My time, and the time of everyone on my team, is far too valuable to be spent on teaching new hires things they should have learned on their own in junior year of college. Onboarding people means bringing them up to speed on the complexities and specifics of our own systems. We're not in the business of hiring people and holding their hand for a year until they know enough CS to be useful.

Also:

> This is not junior level knowledge. You're looking for a mid-level to senior developer with zero experience.

Zero professional experience, maybe. Zero experience period, no. This stuff is offered in almost all undergrad CS programs. If you didn't go to college or have a degree in a different field you can find tons of lists of topics for self-study. If you've ever done any project on the side, you're bound to have encountered or at least imagined a couple of these issues. Something as basic as finding the largest N elements in a array isn't a trick, it's something that should be painfully obvious to anyone who's coded for more than a month.

[thaumasiotes]

> Something as basic as finding the largest N elements in a array isn't a trick, it's something that should be painfully obvious to anyone who's coded for more than a month.

Not a trick? Of course it's a trick.

The efficient way to do it is to heapsort the array, but just stop after you've popped N elements from the heap.

You can do much worse and still stay in pure linear time (though as I noted in another response to you, the difference in polynomial order between O(n) and the O(n log n) that would be required to finish your heapsort is ε, where ε is larger than zero but smaller than any real number): just scan the array N times, looking for the largest element that's smaller than your shrinking upper bound. I'd rather see a solution that sorted than one that took N passes to pull N elements -- sorting will be faster -- but the N passes approach is pure linear time.

Then again, naive N passes will fail when the array contains duplicates. To avoid that, you'll need to allocate a data structure to hold your N answers, and implement a way of adding values in and having it appropriately discard the lowest value when you add to it while it's full. That's starting to look like a trick. It also cuts you down to one pass.

Is the "not a trick" answer you're looking for implementing an N-running-maxes data structure, or remembering how to heapsort? Do you really care about getting your results in slow linear time instead of fast "so close to linear you can't even tell the difference" time?

[violinist]

I see where you're coming from on some points, such as complex character sets and caching. But runtime and spacetime complexity are basic concepts which should be taught in any respectable CS degree program. Looking for edge cases and writing good tests ought to be taught as well. Also I'd hope parallel algorithms would get some time in a CS degree, but that one could be somewhat negotiable.

[whb07]

Can you define what a 'respectable' CS program is? I'm currently taking a core CS class online for fun at a major public university and its nothing earth shattering. In fact, I'd go as far as saying that I get more out of blogs and study aides like 'cracking the coding interview' than this class.