5 ms·

> We’ll ask you to solve some coding questions in a language and text editor of your choice. Feel free to bring your own laptop, or we’ll be happy to provide on

> We’ll ask you to solve some coding questions in a language and text editor of your choice. Feel free to bring your own laptop, or we’ll be happy to provide one. Notably, we ask candidates not to compile or run their code during this exercise, and not to refer to online resources. Every time interviewing comes up, I have this funny feeling about letting people look things up vs. whiteboarding them out. Reading this finally broke something loose: Coding in interviews should be as hard as the hardest coding you'll do on the job. Heck, anything in the interview should be about how you do things when the job is hard. Now, this doesn't mean under stress. That may come naturally. But the difference between good and great engineers is decided when the task is hard and information is sparse. Asana is explicitly selecting for people who are going to reason about things from first principles and try to get it right the first time. I admire that they're owning up to that. They'll pass over people who are exceptionally good at searching / synthesizing information. They'll ding people who focus on tightening the iteration time as a way of learning faster. But that's OK. They've probably built a culture where that kind of person thrives, and they're trying to find more engineers who will thrive at Asana.

vonmoltke 11y ago
> That may come naturally. But the difference between good and great engineers is decided when the task is hard and information is sparse. Asana is explicitly selecting for people who are going to reason about things from first principles and try to get it right the first time. I admire that they're owning up to that. > They'll pass over people who are exceptionally good at searching / synthesizing information. I also admire that they are upfront about this, but the attitude in general rubs my classical engineering self the wrong way. "[R]eason[ing] about things from first principles" is not the same thing as having those first principles memorized. That was one thing my undergrad taught me repeatedly. Engineering isn't about memorizing formulas, it is about learning what those formulas mean, how to use those formulas, and when to apply them to a task at hand. Software engineering should be no different. Expecting people to solve hard and novel problems with no resources whatsoever is ludicrous.
- thedufer 11y ago
  Much of the point of "first principles" is that there aren't very many of them. If you have any trouble at all remembering them, you can be fairly certain that you have not trimmed enough.
NhanH 11y ago
There is no such thing as "reasoning from first principle" for most of our engineering situations that can be described in an interview, regardless of whether it's hard or not. Because everything is based on tradeoff and very very specific scenarios. I will reason from first principles if the interviewer provide me with a 200 pages detail on the budget, timeframe, use cases, target users and all deployment constrains. Otherwise we all worked based on assumptions and experience we got, even if the interviewer don't want to acknowledge that.
hibikir 11y ago
No, they shouldn't be as hard as the hardest you'll do on the job, because what is hard on the job has nothing to do with the real issue with an interview: a 30-60 minute window between solution and problem statement. I have been programming professionally for about two decades. Algorithms? Easy, there are a lot of papers, and The Art of Programming for that. Designing something completely novel? I'll be looking at it for a long time before I can trust it. Performance optimizations? I'll count cycles if I have to. A little bit of time fixes all of it. So what is actually hard about programming? Making sure my system is observable, so that when there is a problem, I know what is going on within seconds, if not minutes. Building a system that self heals. Making API decisions that I will not rue in 6 months to a year. Helping a coworker figure out a more sensible architecture without turning it into a pissing contest, or having to pull rank. How can I actually show ANY of the hardest things I'll do on the job in that short amount of time? I can't. In practice, I get my best salaries, where I am the most valued, either the second time around in a place, or when, either through someone on the inside or well know third party references tell the prospective employer what I can actually do. I have worked with amazing people that I'd never refer to a company that is trying to do this google-derived interview style, because what really matters in that interview is first, the 10 second likeability, second, to read the cues on what the interviewer is thinking of what you are saying, so you can change course if he is not liking you, and third, the ability to think on your feet fast enough while you are getting the other two things done. Someone that takes 6 hours looking at a problem but comes back with an amazing, production-grade solution every time is not welcome there, because they will always get culled. So the problem of the interviews Asana is describing is that they can cull some people, but there is no proof whatsoever that anything they are doing correlates at all with the things that really make a good developer. This is great through, as anyone using a better interviewing system will be able to get far better developers on the cheap, as all this SV companies that copy each other just chase the same style of candidate.
ascorbic 11y ago
But which is more useful? On a day to day basis, programmers will usually have access to docs, Google and Stack Overflow, so surely it makes sense to select for people who are good in that situation rather than those who excel in the more unusual situation of having no information.

vonmoltke 11y ago

> That may come naturally. But the difference between good and great engineers is decided when the task is hard and information is sparse. Asana is explicitly selecting for people who are going to reason about things from first principles and try to get it right the first time. I admire that they're owning up to that. > They'll pass over people who are exceptionally good at searching / synthesizing information. I also admire that they are upfront about this, but the attitude in general rubs my classical engineering self the wrong way. "[R]eason[ing] about things from first principles" is not the same thing as having those first principles memorized. That was one thing my undergrad taught me repeatedly. Engineering isn't about memorizing formulas, it is about learning what those formulas mean, how to use those formulas, and when to apply them to a task at hand. Software engineering should be no different. Expecting people to solve hard and novel problems with no resources whatsoever is ludicrous.

thedufer 11y ago
Much of the point of "first principles" is that there aren't very many of them. If you have any trouble at all remembering them, you can be fairly certain that you have not trimmed enough.

NhanH 11y ago

There is no such thing as "reasoning from first principle" for most of our engineering situations that can be described in an interview, regardless of whether it's hard or not. Because everything is based on tradeoff and very very specific scenarios. I will reason from first principles if the interviewer provide me with a 200 pages detail on the budget, timeframe, use cases, target users and all deployment constrains. Otherwise we all worked based on assumptions and experience we got, even if the interviewer don't want to acknowledge that.

hibikir 11y ago

No, they shouldn't be as hard as the hardest you'll do on the job, because what is hard on the job has nothing to do with the real issue with an interview: a 30-60 minute window between solution and problem statement. I have been programming professionally for about two decades. Algorithms? Easy, there are a lot of papers, and The Art of Programming for that. Designing something completely novel? I'll be looking at it for a long time before I can trust it. Performance optimizations? I'll count cycles if I have to. A little bit of time fixes all of it. So what is actually hard about programming? Making sure my system is observable, so that when there is a problem, I know what is going on within seconds, if not minutes. Building a system that self heals. Making API decisions that I will not rue in 6 months to a year. Helping a coworker figure out a more sensible architecture without turning it into a pissing contest, or having to pull rank. How can I actually show ANY of the hardest things I'll do on the job in that short amount of time? I can't. In practice, I get my best salaries, where I am the most valued, either the second time around in a place, or when, either through someone on the inside or well know third party references tell the prospective employer what I can actually do. I have worked with amazing people that I'd never refer to a company that is trying to do this google-derived interview style, because what really matters in that interview is first, the 10 second likeability, second, to read the cues on what the interviewer is thinking of what you are saying, so you can change course if he is not liking you, and third, the ability to think on your feet fast enough while you are getting the other two things done. Someone that takes 6 hours looking at a problem but comes back with an amazing, production-grade solution every time is not welcome there, because they will always get culled. So the problem of the interviews Asana is describing is that they can cull some people, but there is no proof whatsoever that anything they are doing correlates at all with the things that really make a good developer. This is great through, as anyone using a better interviewing system will be able to get far better developers on the cheap, as all this SV companies that copy each other just chase the same style of candidate.

ascorbic 11y ago

But which is more useful? On a day to day basis, programmers will usually have access to docs, Google and Stack Overflow, so surely it makes sense to select for people who are good in that situation rather than those who excel in the more unusual situation of having no information.