Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Being a Principal Engineer

blog.dbsmasher.com

Post reply on HN
Print view View original

321–330 of 337 posts

Re: On Being a Principal Engineer

#321

Post by mlthoughts2018 »

brlewis wrote: post #320
mlthoughts2018 wrote: post #316

Earlier quoted context omitted.

That makes no sense at all. Pre-existing political barriers are the primary obstacle to convincing people in most business settings. The actual technical merit or cost effectiveness usually has utterly no correlation at all to how the business decision is made.

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

Re: On Being a Principal Engineer

#322

Post by imetatroll »

maxxxxx wrote: post #294
imetatroll wrote: post #181

Earlier quoted context omitted.

I think you are wise to worry. Last year I was laid off from a company whose technology I helped build for years. I was promoted up to the position of "CTO"... with no team below me. It was a very small company working on email archiving and encryption that still runs today. As the system admin and solo developer I was spread thin, working on a system that now processes anywhere from 80 to 120 (150?) million emails a…

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

Re: On Being a Principal Engineer

#323

Post by imetatroll »

D-Coder wrote: post #189
imetatroll wrote: post #181

Earlier quoted context omitted.

I think you are wise to worry. Last year I was laid off from a company whose technology I helped build for years. I was promoted up to the position of "CTO"... with no team below me. It was a very small company working on email archiving and encryption that still runs today. As the system admin and solo developer I was spread thin, working on a system that now processes anywhere from 80 to 120 (150?) million emails a…

"I find the question "what was your biggest accomplishment?" to be a frustrating one during interviews because I did so much for that previous company that I almost don't remember any of the subtle details." I've kept a daily work log at my last few jobs -- just a line about each significant thing I made progress on, so usually one sentence a day (and often the same sentence for several days). This could be helpful.

Thanks for the suggestion I will keep it in mind once I find another job.

Re: On Being a Principal Engineer

#324

Post by hvidgaard »

scarface74 wrote: post #313
hvidgaard wrote: post #287

Earlier quoted context omitted.

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

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

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.

Re: On Being a Principal Engineer

#325

Post by scarface74 »

hvidgaard wrote: post #324
scarface74 wrote: post #313

Earlier quoted context omitted.

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

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.

Re: On Being a Principal Engineer

#326

Post by Tcepsa »

prirun wrote: post #305
2muchcoffeeman wrote: post #144

Earlier quoted context omitted.

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

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

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)

Re: On Being a Principal Engineer

#327

Post by skj »

mlthoughts2018 wrote: post #321
brlewis wrote: post #320

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.

That's an odd distinction and almost certainly not one that was made by anyone else in this conversation.

Re: On Being a Principal Engineer

#328

Post by benc666 »

maxxxxx wrote: post #132
majormajor wrote: post #52

Earlier quoted context omitted.

> The next time I will require the role to be some type of director or IC/distinguished engineer hybrid that is operating with an authority level above that. I've seen this go roughly. A director who brings in a lot of new technical views, challenging the perspectives and opinions held by the team, might not have an easier time than a staff engineer. The director was largely right, but dealt not just with technical r…

Authority certainly helps. It's not everything but without authority you almost have no chance.

There's kinds of authority. "personal authority" can easily work better than "org chart" authority since it usually has respect and trust attached - which no mere org chart can grant.

Admittedly some org charts do grant "respect" - the same sort you give a rattlesnake.

Re: On Being a Principal Engineer

#329

Post by mlthoughts2018 »

skj wrote: post #327
mlthoughts2018 wrote: post #321

Earlier quoted context omitted.

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

That's an odd distinction and almost certainly not one that was made by anyone else in this conversation.

I disagree. It is a basic and ubiquitous distinction in any corporation, because the distinction between appraising the technical merit of a proposal and assessing the political implications, who gets credit, bonuses, etc. etc. is so vast.

The connotation of “selling your vision/plan” is obviously political, getting buy-in from a political / authority sense, unrelated to any technical specifics.

This is just corporate day-to-day 101 stuff. My use of this distinction is not unique in any way, it is the obvious interpretation that would be used anywhere someone is discussing any type of business project.

Re: On Being a Principal Engineer

#330

Post by maxxxxx »

benc666 wrote: post #328
maxxxxx wrote: post #132

Earlier quoted context omitted.

Authority certainly helps. It's not everything but without authority you almost have no chance.

There's kinds of authority. "personal authority" can easily work better than "org chart" authority since it usually has respect and trust attached - which no mere org chart can grant. Admittedly some org charts do grant "respect" - the same sort you give a rattlesnake.

There is the saying “always speak softly but carry a big stick”. It’s good to build up personal author but in the end it’s good to have the final say. Hopefully with buyin from everybody else.
Post reply on HN