[jameshart]

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?)

[PopeDotNinja]

> 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]

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).

[phkahler]

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]

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]

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.

[Klathmon]

I feel I do great during the interview, it's just getting to that point is where I'm struggling. Writing that out seems to really bring out a part of my brain that makes it always feel braggy. (I really think it's the fact that during a conversation I have realtime feedback on what the interviewer wants and what parts I should focus on)

I'm "full time" looking for a job at the moment, and it's rough with how much of "nothing" you get back. A lot of no responses, no way to gauge how i'm doing, and even when rejections come in there's no information along with them to help me understand why or how to improve.

I'm trying to learn to write about myself more and feel more confident in writing about what i've done and that I really feel I was an integral part of the success of the things i've been a part of, but without any kind of feedback I'm constantly second (and third!) guessing literally every word.

[devonkim]

A recruiter I respect said that the interview process is the most egotistical, selfish thing we do as professionals and it does the process a disservice if you do not follow it as such. Selling yourself to your peers and to those that want to hire you is important for the accuracy and precision of the hiring process if your contributions are not self-evident.

Getting good feedback is definitely one of the hardest parts though and thus makes getting better at interviews tough without good mentorship / network. Heard of a guy that was one of the top n TopCoder engineers and was having trouble landing a solid gig. Turns out he’d just zoom through the whiteboard problems, hardly talk, and interviewers were just weirded out. When he started slowing down and explaining his thoughts better to the panels he finally got the offers he deserved.

[lugg]

> A lot of no responses, no way to gauge how i'm doing, and even when rejections come in there's no information along with them to help me understand why or how to improve

If you don't come out of an interview and know you have an offer coming your way: assume you have no offer coming your way. It's usually very obvious and both parties are trying to say your hired without actually showing your cards. It's kind of a funny dance.

Your problem, where you feel you have no feedback is a problem but it's most likely a problem with you.

You need to be asking for feedback if you're not getting it. Get blatant if you have to.

What do I need to show you to get an offer today? What are you looking for? Your job ad didn't clarify on this this and this, can you spell out exactly what you're looking for in me today?

You're not really responding to my answers, is there something I'm not explaining well enough? Feel free to interrupt and get me to clarify, this point is important to me because it illustrates this skill which I think is important as a developer, do you agree, disagree or don't believe me? Why? What facts do you need me to spell out?

If you think it's on them to figure out how to be good at interviewing, you're right, it is, but that doesn't help you get a job offer today.

[Klathmon]

I just wanted to follow up and let you know that I really took this advice to heart while applying to a few companies after reading it.

I just accepted an offer at a great company, and I do think that it was in part because of the advice you gave me here, so I wanted to say thank you.

[tbomb]

One of my go-to closing questions in interviews is to ask them if they have any concerns/doubts about hiring me for the role.

So far I've gotten pretty good and honest feedback from it. It also gives me an opportunity to explain myself and/or try to turn around any doubts.

[Klathmon]

I appreciate the advice, and i'm going to try taking this to heart.

It's funny how i've been on the other side of the interview many times, and all the advice I'm hearing here rings true, and I know it is, but I just seem to have this blocker where I'm judging myself too harshly in all the wrong areas.

Regardless, I really do appreciate it, and i'm going to try and be more blatant and firm in this process.

[blattimwind]

> You need to be asking for feedback if you're not getting it. Get blatant if you have to.

Also consider that at that point it's completely risk-free. If you just leave, you're not hired anyway, so regardless their response, you can only win from there.

[phkahler]

One of the other posters here responded to you with:

>> Frankly, what you just wrote is what I want to hear in an interview.

I completely agree. Look back at what you wrote here. The word "I" appears plenty of times in your post and is very appropriate. You're talking about your experience so it makes perfect sense to mention yourself in that. You also mentioned the team and "we" a bit. Good. There is a lot of space between talking about your experience and being an egotistical jerk. Talk about your experience just like your post here and you should be fine.

When I interview I'm primarily looking for 3 things on the technical side:

1) Can this person DO things?

2) Can they learn things?

3) Are the interested in doing and learning the kind things we need done?

In that short post you've demonstrated #1 and #2. You also covered some of the non-technical stuff. If you showed experience or interest in embedded C on micro controllers I'd be telling you to apply here (Detroit area).

[fatnoah]

>It's not hard to separate these once you're aware of the issue and start asking the right question "what did you do?"

Another useful technique I've developed for interviewing senior folks is to probe them for details about important technical or other decisions that were made related to the things they say they did. I'll then challenge those decisions and make them justify and explain.

[2muchcoffeeman]

> 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’?

[ryandrake]

> Even your best developer is not going to do anything great if he’s fixing bugs.

Honestly, I wish this mentality would go away. Maybe software in general is so "barely shippable" shitty because 95% of everyone's engineering effort is spent on cranking out features rather than fixing bugs and improving stability/performance. Somehow, feature work is glamorous and gets you promoted and quality is seen as boring, dead-end work. This really needs to change.

[bluGill]

The best developers are the ones you can give the hardest bugs to and trust they get them done. The ones where the principal engineers see someone heading for your desk and jumps up to figure out why - stopping your interruptions is far more important than anything else! (You can't give these to the principal engineer because his job is to be interrupted)

[Swizec]

> 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]

Wouldn't that be just a round about way to lie about yourself?

[Swizec]

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]

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]

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.

[beaner]

I don't think many people are opposed to that way of thinking. But as a responsible team member you still have individual duties and you need to be able to explain them.

[kortilla]

Right, a staff level engineer would have been the one to organize the team so the junior developers are picking up the easier stuff and learning the system.

If you think team dynamics just magically emerge that way around a complex technical project, you weren’t as senior as you thought.

[prirun]

I sort of hate the idea that senior people design and write stuff, while junior people fix bugs. In my experience this leads to developing code where "someone else will fix it up if there are problems" and in the long-run, is not good for the senior people (they get sloppy) or the junior people (they're not happy fixing others' crappy code).

I think a lot better model is ownership of code. If you write something, it's yours. If it breaks, it's yours to fix. If someone wants to change the design of it, they go through you first. Maybe eventually someone changes it so much that they own it.

[Tcepsa]

What about the idea that senior people design stuff but then hand it off to junior people to write and then coach them through the bug fixing and refinement? (Honest question; doesn't seem like there's much of this where I work and I'm considering trying to introduce it because it seems to me like a good way to leverage the senior folks' skills while also transferring them to more junior folks, but I'm wondering whether there is some kind of taboo against it or something else that I'm missing)

[dcosson]

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?

[ghevshoo]

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]

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.

[scarface74]

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]

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]

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

[hvidgaard]

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.

[scarface74]

I very much care that they know the tools and are not just a good developer. I need someone who can hit the ground running using our choice of language. Learning a language is easy. Learning to use the tooling efficiently and learning the ecosystem takes time. I'm not hiring developers to write algorithms. I'm hiring developers who know whatever language we are working in. I'm not going to hire a PHP developer no matter how good they are if I'm running a C# shop. Why would I? I can easily find C# developers.

If they struggle writing code and don't know the syntax when given an IDE, why would I hire them?

[billti]

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.

[scarface74]

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.