12 ms·

The challenge I have interviewing people for very senior engineering roles is how to tell the difference between somebody who was nearby when some interesting w

The challenge I have interviewing people for very senior engineering roles is how to tell the difference between somebody who was nearby when some interesting work got done, and somebody who made something interesting happen. What I’m looking for in a principal engineer is someone who turns good teams into great teams; who steers the organization away from disastrous mistakes; who enables the business to accomplish things that, without them, would not have been done. It’s something that comes hard to senior developers, because we’re all aware that every result is a team win. So when you’re asked about a project you worked on, you’ll tell the story all in first person plural: ‘we had to solve this problem, so we decided to use this approach’. When telling that story in an interview for a principal engineer role, make sure you clarify your role. What was expected of you, and how did you knock it out of the park? What parts of the problem did you have to take personal ownership of? Which decisions did you have to go to the mat for, and why were you right? Convince me you are a differentiating factor in successful projects and we’re going to be interested in hiring you. As an interviewer I try to dig towards these things but it is hard and honestly I need some help from the candidate - and at this seniority level I don’t think that’s unreasonable (the candidate should know how interviews work because they’ll have been in the interview chair themselves, right?)

dcosson 8y ago
Just curious, in addition to looking for those things do you do all of the same types of technical interviews for a principal engineer as for other engineer roles? I would imagine a lot of principal candidates are older, maybe a little rustier at the rote algorithm type questions than a sharp new college grad. Do you expect a principal engineer to be along the lines of the best you've ever seen in every category, or do they just need a passing score in the various technical sessions and the differentiating factor is more of these leadership type questions and convincing you about their past successes?
- scarface74 8y ago
  I’ve been working 20+ years and have been on the job market 7 times and dozens of interviews. I’ve only been asked algorithm type questions twice. The first was back in 1999 at my second job where I would be doing a lot of complex cross platform C and the second in 2016 when I was asked to write a merge sort. I turned down the offer in 2016 to work as a dev lead at another company even though the company doing the algorithm interview both paid slightly more and was a permanent position and the other was contract to perm. It told me a lot about the maturity level of the company that they would ask a senior developer algorithm questions and not architectural questions. I’ve had my share of pair programming interviews and online multiple choice assessments but I’m okay with those.
  - hvidgaard 8y ago
    I'm on the fence about that. Interviewing a senior developer, my experience is that it's still necessary to gauge their ability to code. Some can barely do it, I kid you not! An if you claim seniority, I expect you, if not to know merge sort, then to understand it quickly and make a simple implementation and assume boring stuff like the length of the array ect. It is not difficult. It would be a great example to demonstrate programming proficiency and if you didn't know merge sort, how you grasp new problems. I would put more weight on architectural discussion though.
    - scarface74 8y ago
      Notice I said I have no problem with pair programming type interviews. When I interview developers, I have a simple skeletal class based on a real world problem we’ve had with failing unit tests. They have to make the unit tests pass. Then I give them another set of requirements and unit tests they need to make pass without breaking the first set. When I interview QA people, I give them a version of the FizzBuzz test. I tell them they have a website that implements FizzBuzz. How would they test it. I want to see answers like this: https://twitter.com/sempf/status/514473420277694465 https://twitter.com/sempf/status/514473420277694465
      - hvidgaard 8y ago
        That works too, but the means to the end is less important than the result. I'm sure I would get the same from your approach, as I would with a simple programming problem question - algorithmic or not. Most of all it's a litmus test to see that they in fact know how to think in code. I really don't care if it's in C#, Haskell, or pseudo code - that's their tool of choice as long as they show the ability to solve a problem logically in code. I purposely try to make it less dependent on environment and syntax because it's not important for the candidate to show that they can. I always interact with the candidate and try to get them to implement enhancements or edge case handling that's missing. It's a minor part of the interview we get over with in the first round. But if they asked you that and nothing else I would've walked away too - no one with a clue have been involved in that process anyway.
- ghevshoo 8y ago
  Would love an answer to this question too. I effectively find myself in the role of a “principle engineer”. That’s exactly the reason why I was hired - with the expectations to be a “force multiplier” in the organization, which means I end up getting involved in many non-technical activities. My actual job title is just “software engineer”, but title’s don’t mean too much where I work (a mid-size bank in Europe). If I had my choice I would be spending 80% of my time writing and reviewing code, not just because I enjoy it but I feel like my coding skills are below what they should be and I want to spend more time improving them. I struggle in programming tests. I find them pretty daunting. The value I can bring to a company is well known within the circle of people who have previously worked with me. From job to job, as long as I am touching that circle I can charge a premium. But the skills and experience I have are ones that rarely appear in a job description, and if they do they are usually under valued or the interviewers have no idea how to interview for such a position. It’s a continual dilemma for me in my career now as I hit the big four-oh this year, and trying to figure if there is some way to be just a regular “software engineer” without taking a big pay-cut. Even though I still have plenty of interests and drive to learn, the normal situation 10 minutes into any discussion with a recruiter is “here is a technical/programming test...” at which point I get defensive and say “I’ll only do it if I think your test is interesting.” But I’m half covering up for my terrible ability for performing tests like what you see on hackerrank.
  - scarface74 8y ago
    It’s a continual dilemma for me in my career now as I hit the big four-oh this year, and trying to figure if there is some way to be just a regular “software engineer” without taking a big pay-cut. Not that I’m looking to leave the company I’m working for now anytime soon, but I’m in my mid 40s and I think whenever I do leave, this may be my last full time software development job unless I find another small company I like as much. My next job will either be an overpriced “digital transformation consultant”/“cloud consultant” or just a W2/1099 contractor where I come to work get paid and move on when the contract is over. Luckily, I never have to worry about health care coverage again in 6 years since my wife will have guaranteed life long health insurance with her job after 10 years.
billti 8y ago
In a similar vein: As a principle engineering manager, I feel awkward doing my “what did you achieve” write-up come review time, as it feels like I’m taking too much credit for what my team did - even though probably the biggest part of my job is defining the work and making the team productive.
2muchcoffeeman 8y ago
> It’s something that comes hard to senior developers, because we’re all aware that every result is a team win. So when you’re asked about a project you worked on, you’ll tell the story all in first person plural: ‘we had to solve this problem, so we decided to use this approach’. As you said, good outcomes are team efforts. Even your best developer is not going to do anything great if he’s fixing bugs. Less senior developers prop up the senior ones. So why would we talk as though our specific roles were ‘special’?
- Swizec 8y ago
  > So why would we talk as though our specific roles were ‘special’? Because you’re selling yourself. Interviews are sales. You are the product. Not your team, not your boss, not your company. You.
  - chii 8y ago
    Wouldn't that be just a round about way to lie about yourself?
    - Swizec 8y ago
      No, don’t lie. Highlight your accomplishments. Yes they wouldn’t be possible without the inputs of others and yet you still did something. What was it? If you can’t answer that question then this project shouldn’t be on your resume and you shouldn’t bring it up in interviews.
- beaner 8y ago
  Why do you have that in quotes? They did not say senior roles are special. They're just saying: acknowledge team wins, but you still did something individually, be able to explain what that thing was in detail.
  - 2muchcoffeeman 8y ago
    The OP was frustrated about having to prompt interviewees to talk about their accomplishments and how they always talk in first person plural. I am in support of this being the natural way of thinking. No one could do what they did without support. I am also vaguely suggesting that maybe every company’s process of promoting, hiring or giving out bonuses is wrong.
scarface74 8y ago
I was asked a few question when I interview for my job as a dev lead: The one I remembered most was after he told me the current sad state of the department he inherited (not the people, the process) he asked me what was my 90 day plan if so sdrs hired. He also asked me about my thoughts on hiring, mentoring, and testing strategies.
phkahler 8y ago
That's the challenge in all engineering interviews - determining weather they did anything useful or were just on the team. I've had to tell people to stop telling me about "we" and tell me what "you" did. Some people are so caught up in trying to be a team player that they hide their contributions. Others use it to hide their lack of contribution. It's not hard to separate these once you're aware of the issue and start asking the right question "what did you do?"
- Klathmon 8y ago
  I personally always talk about what "we" did because it helps me get out of my own way. I worked at a company for like 6 years, and for almost 4 of them i was the sole engineer tasked with designing a database for the data, creating and deploying/maintaining an API server, and creating a handful of react frontend applications. The last 3 years we expanded into a "team" that I led and scaled it up from there. I never talk about what "I" did because I'm always afraid it will come across as lying or exaggerating, and at the same time I know that I didn't do all that alone even if I was the sole contributor for the vast majority of it. I had managers that helped carve out time and lay out requirements, I had executives that were willing to let me make multiple mistakes as I found my footing, I had devs focused on other areas at the company that I could bounce ideas off of and learn new skills from. And to be honest there were some months that I was SO productive that I genuinely don't think I could ever do it again, and I don't know exactly why it happened. I'm currently looking for a senior/lead job, and writing about what "I" did and what I feel i'm capable of is by far the hardest part of it. I feel like I flip flop between basically saying "I was part of a team that did awesome things" and "I did all this awesome shit all on my own", and in both cases it feels like i'm lying. Once I'm talking to someone I feel i'm really good at talking through the choices and tradeoffs made, the mistakes I made, the parts of the job I'm good at and the parts I feel I'm not. But I can't seem to write that down well, and I think i'm throwing away chances because of it.
  - tfigment 8y ago
    Frankly, what you just wrote is what I want to hear in an interview. That you were first and the team grew around you and if mistakes were made how what would you do differently. To me, the company/team talk eats away at the limited time in the interview and doesn't generally matter since we are not hiring your company but how you helped is very relevant. I will slightly demerit people if I have to resort to asking what they individually did as opposed to the team and a lot if I still don't get a good feel for it. I realize at large companies it can be hard since you might be the guy that maintains a small section of a website but I prefer upfront honesty to having to sort it out with more questions.
PopeDotNinja 8y ago
> The challenge I have interviewing people for very senior engineering roles is how to tell the difference between somebody who was nearby when some interesting work got done When I was a technical recruiter, I could probably have faked my way through some technical interviews without much understanding of how to code. Now as a senior level engineer, I could probably do a pretty good job of sounding like I was the one who did the work that I saw someone else do. > When telling that story in an interview for a principal engineer role, make sure you clarify your role. > Convince me you are a differentiating factor in successful projects and we’re going to be interested in hiring you. > As an interviewer I try to dig towards these things but it is hard and honestly I haven't tried to hire a principal engineer, and I don't consider myself to be one, but if I had to guess how to interview one, I'd probably try something like this... - prior to the interview, prepare specific reasons why we need a principal engineer in the first place, including answers to questions like "what do we expect from a principal engineer that we don't expect from a merely senior engineer?" - I'd budget enough to time candidly talk with the principal engineer about what we're trying to accomplish, especially getting into details about what sucks & where we're lacking principal level help - I'd ask the principal engineer for their thoughts on how they might be able to help, including how they'd go about establishing themselves as someone who could be successful in the role, asking them to go into as much detail as possible - After that, I'd ask them whether they'd even enjoy doing that kind of work, to share some examples about having done similar work previously, and ask what they'd need to be set up for success - I'd ask them to think about the position I'm in, and whether or not they'd recommend I hire them, and why they feel that way Basically, I wouldn't try act like I know how to spot a good principal engineer. I'd do the work to communicate my needs for one, and let the principal engineer candidates help me understand what I'm looking for. If I didn't find a principal engineer amongst the people I'd interviewed, I'd have to trust that I'd have a way to feel that.
- hadsed 8y ago
  I think this is a great comment. The most critical aspect is understanding the risks and mitigating them (which is your question about how to get set up for success).

dcosson 8y ago

Just curious, in addition to looking for those things do you do all of the same types of technical interviews for a principal engineer as for other engineer roles? I would imagine a lot of principal candidates are older, maybe a little rustier at the rote algorithm type questions than a sharp new college grad. Do you expect a principal engineer to be along the lines of the best you've ever seen in every category, or do they just need a passing score in the various technical sessions and the differentiating factor is more of these leadership type questions and convincing you about their past successes?

scarface74 8y ago
I’ve been working 20+ years and have been on the job market 7 times and dozens of interviews. I’ve only been asked algorithm type questions twice. The first was back in 1999 at my second job where I would be doing a lot of complex cross platform C and the second in 2016 when I was asked to write a merge sort. I turned down the offer in 2016 to work as a dev lead at another company even though the company doing the algorithm interview both paid slightly more and was a permanent position and the other was contract to perm. It told me a lot about the maturity level of the company that they would ask a senior developer algorithm questions and not architectural questions. I’ve had my share of pair programming interviews and online multiple choice assessments but I’m okay with those.
- hvidgaard 8y ago
  I'm on the fence about that. Interviewing a senior developer, my experience is that it's still necessary to gauge their ability to code. Some can barely do it, I kid you not! An if you claim seniority, I expect you, if not to know merge sort, then to understand it quickly and make a simple implementation and assume boring stuff like the length of the array ect. It is not difficult. It would be a great example to demonstrate programming proficiency and if you didn't know merge sort, how you grasp new problems. I would put more weight on architectural discussion though.
  - scarface74 8y ago
    Notice I said I have no problem with pair programming type interviews. When I interview developers, I have a simple skeletal class based on a real world problem we’ve had with failing unit tests. They have to make the unit tests pass. Then I give them another set of requirements and unit tests they need to make pass without breaking the first set. When I interview QA people, I give them a version of the FizzBuzz test. I tell them they have a website that implements FizzBuzz. How would they test it. I want to see answers like this: https://twitter.com/sempf/status/514473420277694465 https://twitter.com/sempf/status/514473420277694465
    - hvidgaard 8y ago
      That works too, but the means to the end is less important than the result. I'm sure I would get the same from your approach, as I would with a simple programming problem question - algorithmic or not. Most of all it's a litmus test to see that they in fact know how to think in code. I really don't care if it's in C#, Haskell, or pseudo code - that's their tool of choice as long as they show the ability to solve a problem logically in code. I purposely try to make it less dependent on environment and syntax because it's not important for the candidate to show that they can. I always interact with the candidate and try to get them to implement enhancements or edge case handling that's missing. It's a minor part of the interview we get over with in the first round. But if they asked you that and nothing else I would've walked away too - no one with a clue have been involved in that process anyway.
ghevshoo 8y ago
Would love an answer to this question too. I effectively find myself in the role of a “principle engineer”. That’s exactly the reason why I was hired - with the expectations to be a “force multiplier” in the organization, which means I end up getting involved in many non-technical activities. My actual job title is just “software engineer”, but title’s don’t mean too much where I work (a mid-size bank in Europe). If I had my choice I would be spending 80% of my time writing and reviewing code, not just because I enjoy it but I feel like my coding skills are below what they should be and I want to spend more time improving them. I struggle in programming tests. I find them pretty daunting. The value I can bring to a company is well known within the circle of people who have previously worked with me. From job to job, as long as I am touching that circle I can charge a premium. But the skills and experience I have are ones that rarely appear in a job description, and if they do they are usually under valued or the interviewers have no idea how to interview for such a position. It’s a continual dilemma for me in my career now as I hit the big four-oh this year, and trying to figure if there is some way to be just a regular “software engineer” without taking a big pay-cut. Even though I still have plenty of interests and drive to learn, the normal situation 10 minutes into any discussion with a recruiter is “here is a technical/programming test...” at which point I get defensive and say “I’ll only do it if I think your test is interesting.” But I’m half covering up for my terrible ability for performing tests like what you see on hackerrank.
- scarface74 8y ago
  It’s a continual dilemma for me in my career now as I hit the big four-oh this year, and trying to figure if there is some way to be just a regular “software engineer” without taking a big pay-cut. Not that I’m looking to leave the company I’m working for now anytime soon, but I’m in my mid 40s and I think whenever I do leave, this may be my last full time software development job unless I find another small company I like as much. My next job will either be an overpriced “digital transformation consultant”/“cloud consultant” or just a W2/1099 contractor where I come to work get paid and move on when the contract is over. Luckily, I never have to worry about health care coverage again in 6 years since my wife will have guaranteed life long health insurance with her job after 10 years.

billti 8y ago

In a similar vein: As a principle engineering manager, I feel awkward doing my “what did you achieve” write-up come review time, as it feels like I’m taking too much credit for what my team did - even though probably the biggest part of my job is defining the work and making the team productive.

2muchcoffeeman 8y ago

> It’s something that comes hard to senior developers, because we’re all aware that every result is a team win. So when you’re asked about a project you worked on, you’ll tell the story all in first person plural: ‘we had to solve this problem, so we decided to use this approach’. As you said, good outcomes are team efforts. Even your best developer is not going to do anything great if he’s fixing bugs. Less senior developers prop up the senior ones. So why would we talk as though our specific roles were ‘special’?

Swizec 8y ago
> So why would we talk as though our specific roles were ‘special’? Because you’re selling yourself. Interviews are sales. You are the product. Not your team, not your boss, not your company. You.
- chii 8y ago
  Wouldn't that be just a round about way to lie about yourself?
  - Swizec 8y ago
    No, don’t lie. Highlight your accomplishments. Yes they wouldn’t be possible without the inputs of others and yet you still did something. What was it? If you can’t answer that question then this project shouldn’t be on your resume and you shouldn’t bring it up in interviews.
beaner 8y ago
Why do you have that in quotes? They did not say senior roles are special. They're just saying: acknowledge team wins, but you still did something individually, be able to explain what that thing was in detail.
- 2muchcoffeeman 8y ago
  The OP was frustrated about having to prompt interviewees to talk about their accomplishments and how they always talk in first person plural. I am in support of this being the natural way of thinking. No one could do what they did without support. I am also vaguely suggesting that maybe every company’s process of promoting, hiring or giving out bonuses is wrong.

scarface74 8y ago

I was asked a few question when I interview for my job as a dev lead: The one I remembered most was after he told me the current sad state of the department he inherited (not the people, the process) he asked me what was my 90 day plan if so sdrs hired. He also asked me about my thoughts on hiring, mentoring, and testing strategies.

phkahler 8y ago

That's the challenge in all engineering interviews - determining weather they did anything useful or were just on the team. I've had to tell people to stop telling me about "we" and tell me what "you" did. Some people are so caught up in trying to be a team player that they hide their contributions. Others use it to hide their lack of contribution. It's not hard to separate these once you're aware of the issue and start asking the right question "what did you do?"

Klathmon 8y ago
I personally always talk about what "we" did because it helps me get out of my own way. I worked at a company for like 6 years, and for almost 4 of them i was the sole engineer tasked with designing a database for the data, creating and deploying/maintaining an API server, and creating a handful of react frontend applications. The last 3 years we expanded into a "team" that I led and scaled it up from there. I never talk about what "I" did because I'm always afraid it will come across as lying or exaggerating, and at the same time I know that I didn't do all that alone even if I was the sole contributor for the vast majority of it. I had managers that helped carve out time and lay out requirements, I had executives that were willing to let me make multiple mistakes as I found my footing, I had devs focused on other areas at the company that I could bounce ideas off of and learn new skills from. And to be honest there were some months that I was SO productive that I genuinely don't think I could ever do it again, and I don't know exactly why it happened. I'm currently looking for a senior/lead job, and writing about what "I" did and what I feel i'm capable of is by far the hardest part of it. I feel like I flip flop between basically saying "I was part of a team that did awesome things" and "I did all this awesome shit all on my own", and in both cases it feels like i'm lying. Once I'm talking to someone I feel i'm really good at talking through the choices and tradeoffs made, the mistakes I made, the parts of the job I'm good at and the parts I feel I'm not. But I can't seem to write that down well, and I think i'm throwing away chances because of it.
- tfigment 8y ago
  Frankly, what you just wrote is what I want to hear in an interview. That you were first and the team grew around you and if mistakes were made how what would you do differently. To me, the company/team talk eats away at the limited time in the interview and doesn't generally matter since we are not hiring your company but how you helped is very relevant. I will slightly demerit people if I have to resort to asking what they individually did as opposed to the team and a lot if I still don't get a good feel for it. I realize at large companies it can be hard since you might be the guy that maintains a small section of a website but I prefer upfront honesty to having to sort it out with more questions.

PopeDotNinja 8y ago

> The challenge I have interviewing people for very senior engineering roles is how to tell the difference between somebody who was nearby when some interesting work got done When I was a technical recruiter, I could probably have faked my way through some technical interviews without much understanding of how to code. Now as a senior level engineer, I could probably do a pretty good job of sounding like I was the one who did the work that I saw someone else do. > When telling that story in an interview for a principal engineer role, make sure you clarify your role. > Convince me you are a differentiating factor in successful projects and we’re going to be interested in hiring you. > As an interviewer I try to dig towards these things but it is hard and honestly I haven't tried to hire a principal engineer, and I don't consider myself to be one, but if I had to guess how to interview one, I'd probably try something like this... - prior to the interview, prepare specific reasons why we need a principal engineer in the first place, including answers to questions like "what do we expect from a principal engineer that we don't expect from a merely senior engineer?" - I'd budget enough to time candidly talk with the principal engineer about what we're trying to accomplish, especially getting into details about what sucks & where we're lacking principal level help - I'd ask the principal engineer for their thoughts on how they might be able to help, including how they'd go about establishing themselves as someone who could be successful in the role, asking them to go into as much detail as possible - After that, I'd ask them whether they'd even enjoy doing that kind of work, to share some examples about having done similar work previously, and ask what they'd need to be set up for success - I'd ask them to think about the position I'm in, and whether or not they'd recommend I hire them, and why they feel that way Basically, I wouldn't try act like I know how to spot a good principal engineer. I'd do the work to communicate my needs for one, and let the principal engineer candidates help me understand what I'm looking for. If I didn't find a principal engineer amongst the people I'd interviewed, I'd have to trust that I'd have a way to feel that.

hadsed 8y ago
I think this is a great comment. The most critical aspect is understanding the risks and mitigating them (which is your question about how to get set up for success).