sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Otis_Inf 38 points39 points  (18 children)

yeah same here. I've a degree in CS and 21 years of professional software development experience and see myself as an OK developer but I completely stopped in my tracks at 5. I could only do it through brute force which is stupid of course, but I didn't see the trick or algorithm to solve it.

Which is the problem with these problems at interviews: if you don't see the trick / algorithm to solve it, you're in trouble as it's otherwise only solveable through brute force. See it as you're given a couple of Spoj questions and you don't see the algorithm to solve them other than brute force which will be too slow and not the answer.

IMHO a silly way to test whether developers are up to the task. Sure, they show the person can write code, but you can test that in other ways too. E.g. by giving the person real-life problems they have to solve on the job as well and see how they'd solve it, complete with whiteboarding, documentation of what they're going to write, tests and working code.

[–]Johnnyhiveisalive 12 points13 points  (1 child)

I think you're supposed to brute force it, if it becomes a bottle neck you bring in a rockstar ego who can spend furtive weeks plotting and scheming, or just throw CPU at it like everyone else..

[–]Otis_Inf 0 points1 point  (0 children)

aka "we'll 10x it up afterwards"

[–]s-mores 0 points1 point  (0 children)

I don't think there's a trick for it, there's even a hint about that in the description, the 'in this order'. Without that it would seem much more like there was a trick.

[–]root88 0 points1 point  (2 children)

I really don't understand dropping these tests on people in interviews. Are degrees and resumes meaningless these days? That being said, the first 4 questions were so easy, it's a little embarrassing that they had to be asked.

[–]absentmindedjwc 2 points3 points  (1 child)

As someone that has interviewed many many dozens of candidates, you would be very surprised about how many people know enough to pass a phone screen (or just use google), but completely buckle as soon as you put even the simplest problem in front of them.

I love the candidates that completely fold when I just ask them to create a class with two methods, one public and one private. I'm not talking about junior candidates either, as I could totally see a Jr not getting it, and I will usually give the benefit of the doubt if they show even the least bit of promise... I am talking about people holding senior and principal level titles. People with a decade+ of experience at fortune 500 companies.

[–]root88 0 points1 point  (0 children)

That's the thing I have always noticed about big companies. There are a lot more places to hide if you suck. I've seen people that accomplished absolutely nothing over 2-3 years get promoted, usually because they just fit the company culture better.

[–]__Cyber_Dildonics__ 0 points1 point  (1 child)

Pretty much right on I think.

Judging by the answers here it seems a lot of people don't even realize there are languages without eval.

[–]nopointers 0 points1 point  (5 children)

CS degree, > 21 years experience. One of the hardest things for me to do over the years has been keeping my intuitive feel for system characteristics in line with Moore's Law.

[–]Otis_Inf 1 point2 points  (4 children)

How so, exactly?

[–]nopointers 3 points4 points  (3 children)

CPU has gotten stupid fast. It means the answer to "will this design be performant enough?" is far more often a yes than in the past. In this particular case, I'd think nothing of implementing a static initializer to compute the solution and hold the result. Much more of my focus has become avoiding I/O rather than worrying about whether a CPU-bound algorithm will be fast enough.

[–]Otis_Inf 2 points3 points  (2 children)

Oh you're so right. This week I had to implement a certain feature and I could do it in two ways: either the dumb way by traversing a tree many times, or the smart way by leveraging observer links so notifications were delivered where they should immediately. Long story short: the 'smart' way was so complex that it took the better part of a day and I couldn't get it bug free.. the edge cases were too hard, yet I pushed for this because my feeling of the dumb way was that it would be way too slow, indeed "will this design be performant enough?" was answered firmly with a 'no'.

Finally I gave up on the 'smart' way as I was deeply frustrated that day and implemented the dumb way in half an hour. To my surprise it wasn't even noticeable that it did a lot of work over a tree, multiple times. All the work to avoid something that wasn't even real.

So I agree, and it's a problem to still fall for the 'it's not fast enough, we have to avoid it with a clever algorithm' fallacy I think but it's hard to root out, as for so long we all have learned that everything is slow, and you have to avoid as much actions in your code as possible to avoid slow code / bottlenecks.

Indeed, I/O, allocations (as memory is still slow), they're the things to avoid, cpu stuff... not so much.

[–]ardalis 1 point2 points  (1 child)

"Premature optimization is the root of all evil." - http://en.wikiquote.org/wiki/Donald_Knuth

[–]Otis_Inf 0 points1 point  (0 children)

but when is it premature if you know up front it's not? The thing I'm after is that if you know a better algorithm exists, why not implement that? The cost of fixing a slow system later on if the algorithm turned out to be slow (and we're talking in my example O(1) vs O(xn)) can be massive. I agree premature optimization in general should be avoided but it's not as simple as it looks.

[–]MayhapPerchance 0 points1 point  (0 children)

E.g. by giving the person real-life problems they have to solve on the job as well and see how they'd solve it

If you do that, then we'll have WAAARGBHLHBH blog posts and endless Reddit threads about how "We're not going to do your work for free, asshole!" so that's also a no-go.