Hacker News Reader

Comment by nicksergeant | Hacker News Reader

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.

View on HN

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.

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.

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.

> 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.

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.

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.

What is your preferred interviewing method?

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.

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++)

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.

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

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'.

Reply on news.ycombinator.com