[orsenthil]

> Are we now at a point where an engineer should at all times be intimately familiar with competitive programming and codegolf techniques?

Yes, we are. Accepting that trend seems to be better than ignoring it.

There is one not-so-bad way to look at these programming challenges. In silicon valley, we live in a condition wherein the company could fail at any time. As a developer, most often, we have to learn something entirely new and ship the code for the business. Those challenges are quite enormous with lots of unknowns compared to these programming contest problems where it is just preparation. The general idea is, if a developer is diligent enough to prepare for these programming contest problems and delivers when required, he is probably going to be helpful as well when the business has a dire need.

[nicksergeant]

On the flip side, now you have no idea if a developer is any good, because all they have to do is memorize a bunch of garbage interview algo techniques / questions.

[banachtarski1]

I think this mentality is actually wrong. I've definitely met good engineers who were rejected for jobs they were qualified for because of these questions, but I've never met someone who was extremely good at these questions who turned out to be a dud after hiring.

I don't disagree with the hate towards the current interview process at larger companies, preferring take homes myself, but I think it's harmful to say that all they have to do is "memorize a bunch of ... techniques" - they're going to have memorize a whole lot to get through the interview process. In the process of memorizing (learning) those techniques, you're likely to learn a lot about the foundations of mathematical problem solving.

I guess I'm biased because I studied math in college, but I think we can both criticize the current interview process without taking away from the hard work of people who are actually passionate about algorithms.

[h43k3r]

I have met many people in my life who are/were way better than me in chalking out algorithmic solutions but didn't even had a single bit of knowledge how computers and real softwares work. Many of these people are not good team players, don't understand the importance of delivering things, or simply aren't interested in the work they are doing.

On other side, I have also met many people who are extremely good at competitive programming and extremely good at their workplaces also.

So taking these two as suppositions, I have concluded that competitive programming skill is not something which can't be relied upon as a judgement factor for a good candidate.

Note- I once used to be a good competitive programmer during my college so I have seen both sides of it.

[banachtarski1]

I agree - I don't think competitive programming should be used as an interview tactic. That being said, if you look at the rating distribution of TopCoder/Codeforces problems, most interview problems (even at Google) tend to be around the 1500 Elo level. Around the 1900 Elo level and above, I think it's an extremely strong signal for a very talented thinker.

I'd much rather prefer a discussion about a previous project (open source or at work) with pointed questions about the code/design choices, a take home, etc.

[iiiggglll]

> I've never met someone who was extremely good at these questions who turned out to be a dud after hiring.

I have. More than once I've brought on folks who aced algorithm questions but turned out couldn't handle complex business logic. They could basically only understand code that fit on a page / screenful. Anything beyond that and they floundered.

[dilap]

Dunno about hackerrank, but if you can consistently do well on topcoder algo or codeforces competitions, that's beyond having memorized stuff -- that's being genuinely good at problem solving, and having a broad base of knowledge about important algorithms. I'd be happy to work with you.

[banachtarski1]

Ditto on this. Someone who is passionate about algorithms outside of just memorizing interview problems i.e - they find problems like this - http://codeforces.com/contest/724/problem/G - interesting, usually have high problem solving and mathematical aptitude.

Perhaps I'd like to draw a distinction between genuine algorithms problems that you haven't seen before, and the really bad interview questions like "Find a cycle in a linked list". You'd be really hard pressed to find anyone who could solve the problem above.

Edit: To clarify, I would not remotely consider the linked Codeforces problem as a good interview problem.

[tspike]

What is your preferred interviewing method?

[MaulingMonkey]

Part of the interview for my last job involved interviewing me about debugging, which I thought was neat. "What's wrong with this code?" All the samples were relatively simple - less than 30 lines each?

- Double delete, caused by not following the rule of 3 in C++, which would likely crash - Multithreading code missing volatile or memory barriers (which segued into a discussion of it's disassembly) - Nonvirtual delete through base pointer

Extremely realistic - it's all stuff I've seen and fixed in the wild (this was for a non-entry gamedev job involving plenty of C++)

[ori_b]

Note that unless you are coding in Java, volatile is not a memory barrier, and both the CPU and compiler may reorder things around them.

[MaulingMonkey]

Yes - perhaps I should have written that as "volatile AND memory barriers". Either way, worth mentioning, as it's a common misunderstanding.

Further complicating matters is the fact that Microsoft's compilers will treat volatile as a memory barrier - for x86 code. But not for ARM! https://msdn.microsoft.com/en-us/library/jj204392.aspx

[jedmeyers]

Same thing might be with jvm. On x86 'concrete machine' volatile might be a memory barrier, but this behavior is not guaranteed by the definitions of Java 'abstract machine'.

[tluyben2]

For people with 5+ years of experience (like OP), I look at and talk about their portfolio; he did actually built stuff that runs in production, so let's see how that came to be. And show parts you have written and are proud of. We are probably in that interview because your skill set matches (somewhat) the problems we are trying to solve, hence your past projects will have similarities with our projects. That interests me. I can find out if you are a self starter, if you have any business sense by chance, management/tutor potential etc. That you can solve some complex thing in 5 minutes is of no interest to me at all, ever.

[falcolas]

> The general idea is, if a developer is diligent enough to prepare for these programming contest problems and delivers when required, he is probably going to be helpful as well when the business has a dire need.

How? It's not like the applicant can study for the "dire need" like they can algorithmic interviews. I mean, sure, such an employee can attack the problem with fervor and hours of time, but that doesn't mean that they'll come up with the right solution to the problem.

The ability to choose the "right" algorithm has no correlation the ability to solve problems: The ability to associate pathfinding problems with the proper variant of Dijkstra's algorithm won't help when troubleshooting why customers are getting intermittent 403 errors.

[pvg]

In silicon valley, we live in a condition wherein the company could fail at any time. As a developer, most often, we have to learn something entirely new and ship the code for the business. Those challenges are quite enormous with lots of unknowns

I don't think any of these are true. Companies do not fail 'at any time' because of their programmers nor are they saved by them in the nick of time. If there's something you should be prepared to for it's writing code that's less prone to catastrophic failure rather than coding your way out of some disaster. It's not ER Medicine.

[qznc]

I accept the trend. If you ask me to invert a linked list, I will also mentally note a big fat minus for company culture. I assume others do as well. So bad interview practice will lead to worse hires in the long term.

[twic]

This makes no sense at all. The skills needed to diligently revise algorithms from a book are completely different to the skills needed to keep a startup afloat.

[walshemj]

Absolutely all the textbook q in the world wont help you when your the person keeping the company's billing system running correctly.

[rimantas]

Why mot just require to be able to juggle 7 balls? About as relevant and as good for showing diligence.

[orsenthil]

If the job is in a circus, certainly!