<story><title>On Being a Principal Engineer</title><url>https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-engineer.html</url></story><parent_chain><item><author>2muchcoffeeman</author><text>&amp;gt; &lt;i&gt;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’.&lt;/i&gt;&lt;p&gt;As you said, good outcomes are &lt;i&gt;team&lt;/i&gt; 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’?</text></item><item><author>jameshart</author><text>The challenge I have interviewing people for very senior engineering roles is how to tell the difference between somebody who was &lt;i&gt;nearby&lt;/i&gt; when some interesting work got done, and somebody who &lt;i&gt;made something interesting happen&lt;/i&gt;. 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.&lt;p&gt;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’.&lt;p&gt;When telling that story in an interview for a principal engineer role, make sure you clarify &lt;i&gt;your&lt;/i&gt; role. What was expected of you, and how did you knock it out of the park? What parts of the problem did &lt;i&gt;you&lt;/i&gt; have to take personal ownership of? Which decisions did &lt;i&gt;you&lt;/i&gt; 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.&lt;p&gt;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?)</text></item><item><author>ryanong</author><text>This rings true to my experience.
I&amp;#x27;m a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers.&lt;p&gt;I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech&amp;#x2F;feature work around the company, process strategy and such. I never expected this to be such a large part of my job, and how much value comes from it.&lt;p&gt;But I am also at this weird point where I am not sure if the title of &amp;quot;staff&amp;#x2F;principle&amp;quot; can be transferred to another company. A lot of the value that I add now is because of the historical knowledge I have. What we have tried as a company, what we haven&amp;#x27;t, why we built some things the way we did, how things work currently, how the politics works and the trust I have built.&lt;p&gt;In the past year, I have seen less than 5 job posting for a staff engineer.</text></item></parent_chain><comment><author>ryandrake</author><text>&amp;gt; Even your best developer is not going to do anything great if he’s fixing bugs.&lt;p&gt;Honestly, I wish this mentality would go away. Maybe software in general is so &amp;quot;barely shippable&amp;quot; shitty because 95% of everyone&amp;#x27;s engineering effort is spent on cranking out features rather than fixing bugs and improving stability&amp;#x2F;performance. Somehow, feature work is glamorous and gets you promoted and quality is seen as boring, dead-end work. This really needs to change.</text></comment>
<story><title>On Being a Principal Engineer</title><url>https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-engineer.html</url></story><parent_chain><item><author>2muchcoffeeman</author><text>&amp;gt; &lt;i&gt;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’.&lt;/i&gt;&lt;p&gt;As you said, good outcomes are &lt;i&gt;team&lt;/i&gt; 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’?</text></item><item><author>jameshart</author><text>The challenge I have interviewing people for very senior engineering roles is how to tell the difference between somebody who was &lt;i&gt;nearby&lt;/i&gt; when some interesting work got done, and somebody who &lt;i&gt;made something interesting happen&lt;/i&gt;. 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.&lt;p&gt;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’.&lt;p&gt;When telling that story in an interview for a principal engineer role, make sure you clarify &lt;i&gt;your&lt;/i&gt; role. What was expected of you, and how did you knock it out of the park? What parts of the problem did &lt;i&gt;you&lt;/i&gt; have to take personal ownership of? Which decisions did &lt;i&gt;you&lt;/i&gt; 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.&lt;p&gt;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?)</text></item><item><author>ryanong</author><text>This rings true to my experience.
I&amp;#x27;m a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers.&lt;p&gt;I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech&amp;#x2F;feature work around the company, process strategy and such. I never expected this to be such a large part of my job, and how much value comes from it.&lt;p&gt;But I am also at this weird point where I am not sure if the title of &amp;quot;staff&amp;#x2F;principle&amp;quot; can be transferred to another company. A lot of the value that I add now is because of the historical knowledge I have. What we have tried as a company, what we haven&amp;#x27;t, why we built some things the way we did, how things work currently, how the politics works and the trust I have built.&lt;p&gt;In the past year, I have seen less than 5 job posting for a staff engineer.</text></item></parent_chain><comment><author>Swizec</author><text>&amp;gt; So why would we talk as though our specific roles were ‘special’?&lt;p&gt;Because you’re selling yourself. Interviews are sales. You are the product. Not your team, not your boss, not your company. You.</text></comment>