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?)
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.
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.
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.
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.
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.
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.
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.
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.
>> 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).
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.
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.
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’?
Because you’re selling yourself. Interviews are sales. You are the product. Not your team, not your boss, not your company. You.
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.
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.
They're just saying: acknowledge team wins, but you still did something individually, be able to explain what that thing was in detail.
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.
If you think team dynamics just magically emerge that way around a complex technical project, you weren’t as senior as you thought.
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.
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?
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.
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.
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.
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.
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:
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.
If they struggle writing code and don't know the syntax when given an IDE, why would I hire them?
Besides refactoring is a lot different and the tooling better for statically type languages. Good programming practices is also about idiomatic programming that comes with experience in the chosen language.
Refactoring with or without tooling in static or dynamic languages, is about recognizing a piece of the code base that should be refactored and what the goal is. Tool and language can make this easier or harder, but that is again, something you can train them in and all new developers get a mentor for as long as they need, even senior developers.
He also asked me about my thoughts on hiring, mentoring, and testing strategies.