Live data from Hacker News

On Being a Principal Engineer

blog.dbsmasher.com

331–337 of 337 posts

Re: On Being a Principal Engineer

#331

Earlier quoted context omitted.

> convincing people I thought you didn't want to be burdened with selling ideas, but just wanted authority to implement them without convincing people.

“Selling ideas” is not related at all to demonstrating the technical merit of ideas. They are completely unrelated things.

It might be just me but I think a lot of people read "Selling ideas" as "demonstrating the technical merit of ideas".

Unless the requirements are brain-dead simple, you'll need to sell at the very least the criteria on which you're measuring technical merit: is a latency number a hard requirement, will it scale for x of years, will it be buildable in y months or years.

At least some of that is going to come to convincing someone you've done your homework even if they couldn't make a better decision right?

Re: On Being a Principal Engineer

#332

Earlier quoted context omitted.

I'd rather have a developer with a solid understanding of FP, CI, integration testing, good programming practices, structure, refactoring ect., than one that knows the tools and tooling inside out. Ideally I want both, but if I have to choose it's the former. We have other developers that can get them up to speed relatively quickly, and they'll start with established projects anyway.

So now you’re wasting money on not only the new hire, but also taking time away from your existing employees. 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.

If I had to choose, the former is more important to me, and it works for us, I've not had a bad hire yet in a market where getting new developers is difficult.

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.

Re: On Being a Principal Engineer

#333

Earlier quoted context omitted.

“The other thing that might be fascinating is that the technical portion of interviews seem to be where things stall out for me. I would never claim to be an incredible programmer, ” The interview process filters for coming up with solutions quickly. My strength has always been that I worked through a situation even after the initial or obvious approach(es) didn’t work. A lot of people give up quickly but I keep goin…

Yes we probably are. I don't usually walk away lightly from a problem that initially gives me difficulty, but the speed with which I can execute just doesn't seem to satisfy the hiring process. It is frustrating.

Try interviewing for senior SRE positions, if you would like that quality to become an asset towards being hired.

Re: On Being a Principal Engineer

#334
post #236

Earlier quoted context omitted.

As an example, I recently got offered a Senior Software Engineer position with 6 months experience @ Zendesk.

my whole dept seems to be filled with seniors younger then me, except my manager thinks the title still means something at this point so i'm not being considered for senior for years. im asking to be senior because i just want the money fuck the titles...

Time to leave I guess?

Re: On Being a Principal Engineer

#335
post #179

Earlier quoted context omitted.

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.

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.

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.

Re: On Being a Principal Engineer

#336

Earlier quoted context omitted.

This sounds like a great guy. Can you give some concrete examples of various techniques and technologies that he brought to the table?

Few places are hitting 12 on the Joel Test twenty years on. That, unit/integration tests, and a "message bus" with metrics dashboards and you're above average.

If you need a principal engineer to tell you to write unit/integration tests, that speaks volumes about the quality of engineering below him.

Re: On Being a Principal Engineer

#337
post #247

Earlier quoted context omitted.

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…

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

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.

Post reply on HN