4 ms·

> The expectation in the industry is that Senior people would be even better at it, because of their years of experience. The fact that a person with years of

by pault 8y ago

> The expectation in the industry is that Senior people would be even better at it, because of their years of experience. The fact that a person with years of experience solves an interview question more slowly than a fresh out of college grad should be a huge red flag that our interview questions are bullshit and don't reflect real world challenges.

hellllllllooo 8y ago
Right. Maybe it just shows that the interviewer is too inexperienced to ask questions that are relevant.
whatshisface 8y ago
In one hour, you are supposed to determine what will happen if they are left alone in their office to work for a year. How can you do it?
- hellllllllooo 8y ago
  Exactly. So the arbitrary line drawn by leetcode interviews filters in one particular way and benefits people closer to colleges age where these kinds of problems are fresher in the mind. As you get older the number of leetcode style problems you actually encounter in real engineering is pretty low. Have a chat, discuss experience and see how well they actually understand the things they have put on their resume. Dig as deep as you can and see if they actually understand what they say they have done. Also, references are at least as important as the interview.
- pault 8y ago
  I can only speak for myself, but hires on my team are usually based on my recommendation and I mainly try to tease out whether the candidate has enthusiasm and strong opinions about the languages and frameworks we work with. If I ask what their favorite stack is, or how they prefer to organize a project, and they just mumble their way through the answer, I think they are probably not a good fit.
- burnallofit 8y ago
  Depends on the experience level of the interviewee. If they are fresh out of school I expect them to know algorithms and data structures and maybe some specific topic they studied at an advanced level (like compilers, db, graphics, etc). If they are 5-10 years into a career, they should have a lot of knowledge about whatever it is they've been doing. If someone says they have 5 years of Android programming, I'm going to ask them a lot of Android API questions as well as Java. In either case, there are questions that have multiple difficulties of responses. The more experienced/capable they are, the more nuanced and complete their answers will be. For example, ask a Java person how GC actually works. Most people have very little idea, but the best talent knows a good bit more. But there are other variables. I've known perfectly intelligent and productive coders who took months to build a really complex well architected system that didn't solve the business problem and hence were a bad hire.
  - whatshisface 8y ago
    >I've known perfectly intelligent and productive coders who took months to build a really complex well architected system that didn't solve the business problem and hence were a bad hire. That's an interesting statement. Isn't it usually the job of product managers (or someone in management) to determine whether or not what's being done is actually wanted? It is not typical for developers to be brought on under the broad banner of "make us money please" and then set loose to email users and determine 100% of their own direction. Wouldn't the fact that the wrong program was being built have been caught in an informal "let me see how it's going" sort of status update?

by pault 8y ago

hellllllllooo 8y ago

Right. Maybe it just shows that the interviewer is too inexperienced to ask questions that are relevant.

whatshisface 8y ago

In one hour, you are supposed to determine what will happen if they are left alone in their office to work for a year. How can you do it?

hellllllllooo 8y ago
Exactly. So the arbitrary line drawn by leetcode interviews filters in one particular way and benefits people closer to colleges age where these kinds of problems are fresher in the mind. As you get older the number of leetcode style problems you actually encounter in real engineering is pretty low. Have a chat, discuss experience and see how well they actually understand the things they have put on their resume. Dig as deep as you can and see if they actually understand what they say they have done. Also, references are at least as important as the interview.
pault 8y ago
I can only speak for myself, but hires on my team are usually based on my recommendation and I mainly try to tease out whether the candidate has enthusiasm and strong opinions about the languages and frameworks we work with. If I ask what their favorite stack is, or how they prefer to organize a project, and they just mumble their way through the answer, I think they are probably not a good fit.
burnallofit 8y ago
Depends on the experience level of the interviewee. If they are fresh out of school I expect them to know algorithms and data structures and maybe some specific topic they studied at an advanced level (like compilers, db, graphics, etc). If they are 5-10 years into a career, they should have a lot of knowledge about whatever it is they've been doing. If someone says they have 5 years of Android programming, I'm going to ask them a lot of Android API questions as well as Java. In either case, there are questions that have multiple difficulties of responses. The more experienced/capable they are, the more nuanced and complete their answers will be. For example, ask a Java person how GC actually works. Most people have very little idea, but the best talent knows a good bit more. But there are other variables. I've known perfectly intelligent and productive coders who took months to build a really complex well architected system that didn't solve the business problem and hence were a bad hire.
- whatshisface 8y ago
  >I've known perfectly intelligent and productive coders who took months to build a really complex well architected system that didn't solve the business problem and hence were a bad hire. That's an interesting statement. Isn't it usually the job of product managers (or someone in management) to determine whether or not what's being done is actually wanted? It is not typical for developers to be brought on under the broad banner of "make us money please" and then set loose to email users and determine 100% of their own direction. Wouldn't the fact that the wrong program was being built have been caught in an informal "let me see how it's going" sort of status update?