4 ms·

Recall when you first learned how to program. Something as trivial as iterating through a list requires some thought. What is the syntax for a "for" loop? Do yo

by zawerf 8y ago

Recall when you first learned how to program. Something as trivial as iterating through a list requires some thought. What is the syntax for a "for" loop? Do you start with i = 0 or i = 1? Should you end at i < n or i <= n? At some point you stop thinking about it and write "for (int i = 0; i < n; i++)" instinctively. You can now solve harder problems that require iterating through a list without thinking about it. All of algorithms and programming is like this. You unlock harder problems as you learn more problem solving building blocks (whether it's an algorithm, a software design pattern, or some API call). A programmer is someone who can learn these on the fly for any problem of any domain. An effective programmer is someone who has a large cache preloaded with these building blocks already. In that sense I find leetcode style problems to be very fair. They are meant to be solvable in under an hour without thinking once cached into muscle memory. All it is testing is whether you're capable of becoming an effective programmer in some agnostic domain. All you need to do is warm your cache with a small number of standard patterns (which might even be useful for real work). It does suck that even the good programmers need a few weeks to warm their cache. But it weeds out the fakers who can't do it given any amount of time.

deleted 8y ago
[deleted]
phkahler 8y ago
It's an aggressive filter. We sometimes give a post-interview take home programming problem that involves no trickery or algorithm Discovery/invention. It's just to verify they can code and see their style. You should be able to determine if a person can code from resume and interview alone, but sometimes I can't tell until the exercise. People suck at interviews so they fall back on hard problems. I suppose that works for big companies with lots of applicants.
pavlov 8y ago
> In that sense I find leetcode style problems to be very fair. [...] It does suck that even the good programmers need a few weeks to warm their cache. But it weeds out the fakers who can't do it given any amount of time. It also weeds out people who have better things to do than cram two weeks for your pretend-meritocratic little exam. How about requiring that candidates comment their code using quotes from Classical Chinese poetry? They are proven timeless classics that an intelligent person can apply to any situation. This test would weed out the fakers who can't refresh their caches while also honoring an ancient tradition of stupid job interviews, the Chinese imperial examination.
- jaredklewis 8y ago
  > It also weeds out people who have better things to do than cram two weeks for your pretend-meritocratic little exam. All interviewing techniques have to make precision-recall style trade offs. The mere fact that an interview method has false negatives surely doesn't disqualify it. It has to be compared against the available alternatives. What are the alternatives? - White boarding? Algorithmic knowledge is often tangential to the actual job. - Take home assignments/mini projects? High relevance to job, but in my experience takes the most time for the candidate. - Trial period? Most people can't just drop everything they are doing to come hang out at your company. - Conversational interview. Like white-boarding, tangential to actual job. My experience on the interviewing side is that it is often hard to learn much about the candidate. - Read their code on github / blog. Lots of candidates don't have the time or inclination to code outside of work. - Something else? So what's your preference? I've done them all and find them all to be lacking in different ways. > How about requiring that candiates comment their code using quotes from Classical Chinese poetry? They are proven timeless classics that an intelligent person can apply to any situation. This test would weed out the fakers who can't refresh their caches while also honoring an ancient tradition of stupid job interviews, the Chinese imperial examination. This seems like the fallacy of grey to me [1]. When hiring, for example, a web developer, yes, algorithmic knowledge is a somewhat arbitrary indicator to use, but it is not completely arbitrary. Not all things are equally unlike. If I were hiring for a basketball team, and had to choose between two candidates neither of whom had experience playing basketball and were alike in all ways except that one was an avid soccer player and one was equally fervent about pottery, I would choose the soccer player. The logic of course being basketball and soccer have more in common (athleticism at the least) than basketball and pottery. Likewise, algorithmic thinking shares some common points with almost any kind of engineering task. Interviewing is just a hard problem where you are trying to predict future performance based on a few hours worth of data. I don't think most of the popular the techniques we have are obviously stupid. Companies have strong incentives to make hiring efficient, but there just isn't a lot of low hanging fruit. Of course there are the occasional ego maniac interviewers, but an ego-maniac is going to be able to ruin any type of interview. Let't not throw out the baby with the bathwater. 1. https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallacy-of-gray https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallac...
aprdm 8y ago
> A programmer is someone who can learn these on the fly for any problem of any domain Do you really believe in this? I would maybe call it an Ex Machina droid...
kelnos 8y ago
> which might even be useful for real work In my experience, this is where the house of cards collapses. For most programming jobs, none of that will ever be useful. And on the rare occasion that it is, you'll have gotten by without needing it for so long that you'll have to look it up and more or less learn it again from scratch anyway. I find these sorts of things to give far too little useful information during a developer interview.

by zawerf 8y ago

deleted 8y ago

[deleted]

phkahler 8y ago

It's an aggressive filter. We sometimes give a post-interview take home programming problem that involves no trickery or algorithm Discovery/invention. It's just to verify they can code and see their style. You should be able to determine if a person can code from resume and interview alone, but sometimes I can't tell until the exercise. People suck at interviews so they fall back on hard problems. I suppose that works for big companies with lots of applicants.

pavlov 8y ago

> In that sense I find leetcode style problems to be very fair. [...] It does suck that even the good programmers need a few weeks to warm their cache. But it weeds out the fakers who can't do it given any amount of time. It also weeds out people who have better things to do than cram two weeks for your pretend-meritocratic little exam. How about requiring that candidates comment their code using quotes from Classical Chinese poetry? They are proven timeless classics that an intelligent person can apply to any situation. This test would weed out the fakers who can't refresh their caches while also honoring an ancient tradition of stupid job interviews, the Chinese imperial examination.

jaredklewis 8y ago
> It also weeds out people who have better things to do than cram two weeks for your pretend-meritocratic little exam. All interviewing techniques have to make precision-recall style trade offs. The mere fact that an interview method has false negatives surely doesn't disqualify it. It has to be compared against the available alternatives. What are the alternatives? - White boarding? Algorithmic knowledge is often tangential to the actual job. - Take home assignments/mini projects? High relevance to job, but in my experience takes the most time for the candidate. - Trial period? Most people can't just drop everything they are doing to come hang out at your company. - Conversational interview. Like white-boarding, tangential to actual job. My experience on the interviewing side is that it is often hard to learn much about the candidate. - Read their code on github / blog. Lots of candidates don't have the time or inclination to code outside of work. - Something else? So what's your preference? I've done them all and find them all to be lacking in different ways. > How about requiring that candiates comment their code using quotes from Classical Chinese poetry? They are proven timeless classics that an intelligent person can apply to any situation. This test would weed out the fakers who can't refresh their caches while also honoring an ancient tradition of stupid job interviews, the Chinese imperial examination. This seems like the fallacy of grey to me [1]. When hiring, for example, a web developer, yes, algorithmic knowledge is a somewhat arbitrary indicator to use, but it is not completely arbitrary. Not all things are equally unlike. If I were hiring for a basketball team, and had to choose between two candidates neither of whom had experience playing basketball and were alike in all ways except that one was an avid soccer player and one was equally fervent about pottery, I would choose the soccer player. The logic of course being basketball and soccer have more in common (athleticism at the least) than basketball and pottery. Likewise, algorithmic thinking shares some common points with almost any kind of engineering task. Interviewing is just a hard problem where you are trying to predict future performance based on a few hours worth of data. I don't think most of the popular the techniques we have are obviously stupid. Companies have strong incentives to make hiring efficient, but there just isn't a lot of low hanging fruit. Of course there are the occasional ego maniac interviewers, but an ego-maniac is going to be able to ruin any type of interview. Let't not throw out the baby with the bathwater. 1. https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallacy-of-gray https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallac...

aprdm 8y ago

> A programmer is someone who can learn these on the fly for any problem of any domain Do you really believe in this? I would maybe call it an Ex Machina droid...

kelnos 8y ago

> which might even be useful for real work In my experience, this is where the house of cards collapses. For most programming jobs, none of that will ever be useful. And on the rare occasion that it is, you'll have gotten by without needing it for so long that you'll have to look it up and more or less learn it again from scratch anyway. I find these sorts of things to give far too little useful information during a developer interview.