4 ms·

The article makes it seem like they were asking those questions, he was just missing it. To your blaming the interviewers, part of being VP level is being able

The article makes it seem like they were asking those questions, he was just missing it. To your blaming the interviewers, part of being VP level is being able to pick up on stuff like that. He admits he missed it. They may be concerned, as a result, that he'll "miss it" in other ways too. Very humble article, and great lesson learned by the author.

braythwayt 11y ago
I interview candidates a lot, and I see this pattern many times. I can't remember how aggressively those particular people followed up with me, but I can tell you that I have had conversations like this: --- Tell me about something specific you did to improve the productivity/velocity of your colleagues. "I'm a big believer in unit tests. When you have a lot of code coverage, other people can make changes without worrying they'll break things." Ok, I get that, we write tests too. But what, specifically, did you do with respect to testing? And what, specifically was the result? "Well, I write tests for all my code first. TDD leads to better designs, and that's better for everyone." I know what TDD is, and I admire people with the discipline to practice it consistently. Now tell mw what, specifically, you did with TDD to improve the productivity of the team. Did you introduce the idea? Did you introduce some process around TDD? Did you introduce some TDD tooling? "I use Mock Objects."
- xigency 11y ago
  That's a great point. I think a mistake a number of interviewers make, and maybe they aren't used to the idea of interviewing for a position, is that they aren't interactive enough in their questions. In this case, it sounds like the founders made a bit of a mistake. Even if they were able to find someone who could explain things to them more directly, like they wanted, during the interview, it doesn't mean that the candidate is more qualified for the job. In general, communicating with management or founders won't necessarily be the same as communicating with engineers. For me, I had an interview about a year ago with Google and they were basically so uninterested in asking questions that they didn't learn anything useful about me, so it wasn't surprising that I was rejected. Sometimes interviewers don't realize that it's a two-way street, and that they need to be just as interested in hiring a candidate as an interviewee is excited about working for them. And I think if you're serious about hiring someone that you should be excited no matter what, especially if you know they're qualified.
  - rogerbinns 11y ago
    When I am an interviewer, I do sometimes just shut up and see what the interviewee does answering a question. One pattern I see is that people who are uncertain (or outright lying) about something tend to keep embellishing when you give them the space to do so. You then need to circle back to see if they were nervous etc and do have a reasonable grasp, or are misrepresenting themselves (eg doesn't match the resume claims). Doing it for everything is not useful or productive. Interviewers also need to realise they are selling the company, and while they may not hire the candidate, that candidate will have a career, colleagues, influence etc in the future. I am very wary of some companies and their products (and former employees for that matter) because of the interviewing experience.
- johnrob 11y ago
  Your question seems unexpected, and not necessarily in the charter of every programming gig. I happen to have a great answer to it, after making big improvements to build times, but that is pure chance. The comment at the top of this whole thread has the right idea: sometimes candidates randomly meet unknown expectations, and sometimes the opposite happens.
  - mason55 11y ago
    I don't think his question is unexpected at all for any kind of candidate that is going to have a leadership component. There are a hundred different answers that you can give to his initial question (how did you increase velocity of your teammates). TDD, improved requirements process, improved deployment process, improved monitoring, improved mentoring process, whatever. I actually think this is a great way to figure out whether someone has actually done what they are talking about and done it successfully or if it's just something they have read about or halfheartedly/unsuccessfully tried to implement. It's easy to say "agile is good" or "continuous integration is good" or "TDD is good". If you're going to claim one of those things as a big accomplishment then you should be able to talk about the specifics of how you implemented it. I don't even care if I agree with all your decisions. What I do care about is why you made your decisions. If you made some decision that caused the company to go bankrupt but at the time it was the most sensible decision then lets talk about it. If all you can say is "testing is good because it prevents bugs" then I would be concerned that you either hadn't implemented a comprehensive testing program or you didn't understand why you were making the decisions you made.
  - braythwayt 11y ago
    It's not a question I would ask every time, but it is one I ask sometimes. I just picked it to give an example of trying to get a specific answer but failing. I might ask this question of an engineer who is interviewing for a lead position. These days, an answer could be as simple as, "I paired with a colleague yesterday," or, "I gave thorough feedback on a pull request." I would then follow up with "Tell me more," and a candidate might talk about a recent PR where they pointed out a vulnerability, or an optimization opportunity, &c.
- deleted 11y ago
  [deleted]

braythwayt 11y ago

I interview candidates a lot, and I see this pattern many times. I can't remember how aggressively those particular people followed up with me, but I can tell you that I have had conversations like this: --- Tell me about something specific you did to improve the productivity/velocity of your colleagues. "I'm a big believer in unit tests. When you have a lot of code coverage, other people can make changes without worrying they'll break things." Ok, I get that, we write tests too. But what, specifically, did you do with respect to testing? And what, specifically was the result? "Well, I write tests for all my code first. TDD leads to better designs, and that's better for everyone." I know what TDD is, and I admire people with the discipline to practice it consistently. Now tell mw what, specifically, you did with TDD to improve the productivity of the team. Did you introduce the idea? Did you introduce some process around TDD? Did you introduce some TDD tooling? "I use Mock Objects."

xigency 11y ago
That's a great point. I think a mistake a number of interviewers make, and maybe they aren't used to the idea of interviewing for a position, is that they aren't interactive enough in their questions. In this case, it sounds like the founders made a bit of a mistake. Even if they were able to find someone who could explain things to them more directly, like they wanted, during the interview, it doesn't mean that the candidate is more qualified for the job. In general, communicating with management or founders won't necessarily be the same as communicating with engineers. For me, I had an interview about a year ago with Google and they were basically so uninterested in asking questions that they didn't learn anything useful about me, so it wasn't surprising that I was rejected. Sometimes interviewers don't realize that it's a two-way street, and that they need to be just as interested in hiring a candidate as an interviewee is excited about working for them. And I think if you're serious about hiring someone that you should be excited no matter what, especially if you know they're qualified.
- rogerbinns 11y ago
  When I am an interviewer, I do sometimes just shut up and see what the interviewee does answering a question. One pattern I see is that people who are uncertain (or outright lying) about something tend to keep embellishing when you give them the space to do so. You then need to circle back to see if they were nervous etc and do have a reasonable grasp, or are misrepresenting themselves (eg doesn't match the resume claims). Doing it for everything is not useful or productive. Interviewers also need to realise they are selling the company, and while they may not hire the candidate, that candidate will have a career, colleagues, influence etc in the future. I am very wary of some companies and their products (and former employees for that matter) because of the interviewing experience.
johnrob 11y ago
Your question seems unexpected, and not necessarily in the charter of every programming gig. I happen to have a great answer to it, after making big improvements to build times, but that is pure chance. The comment at the top of this whole thread has the right idea: sometimes candidates randomly meet unknown expectations, and sometimes the opposite happens.
- mason55 11y ago
  I don't think his question is unexpected at all for any kind of candidate that is going to have a leadership component. There are a hundred different answers that you can give to his initial question (how did you increase velocity of your teammates). TDD, improved requirements process, improved deployment process, improved monitoring, improved mentoring process, whatever. I actually think this is a great way to figure out whether someone has actually done what they are talking about and done it successfully or if it's just something they have read about or halfheartedly/unsuccessfully tried to implement. It's easy to say "agile is good" or "continuous integration is good" or "TDD is good". If you're going to claim one of those things as a big accomplishment then you should be able to talk about the specifics of how you implemented it. I don't even care if I agree with all your decisions. What I do care about is why you made your decisions. If you made some decision that caused the company to go bankrupt but at the time it was the most sensible decision then lets talk about it. If all you can say is "testing is good because it prevents bugs" then I would be concerned that you either hadn't implemented a comprehensive testing program or you didn't understand why you were making the decisions you made.
- braythwayt 11y ago
  It's not a question I would ask every time, but it is one I ask sometimes. I just picked it to give an example of trying to get a specific answer but failing. I might ask this question of an engineer who is interviewing for a lead position. These days, an answer could be as simple as, "I paired with a colleague yesterday," or, "I gave thorough feedback on a pull request." I would then follow up with "Tell me more," and a candidate might talk about a recent PR where they pointed out a vulnerability, or an optimization opportunity, &c.
deleted 11y ago
[deleted]