Live data from Hacker News

Dropbox Engineering Career Framework

dropbox.github.io

101–110 of 136 posts

Re: Dropbox Engineering Career Framework

#101

Earlier quoted context omitted.

Do you think that's a bad thing? writing code != building things. In my org, seniors spend a lot less time building things: writing components, etc. They do spend a lot of time navigating office politics. But they are engineering specific office politics: how does system A interact with system B? What are the architectural implications? Ownership of long term data and technical and business strategies? The "art" of n…

In the orgs that I have worked in, there were very few developers who could actually handle coding complex features and applications. The people navigating the office politics are important, but let's not pretend they are actually capable of pulling off the work. They can understand that "system A interacts with system B" at a high conceptual level, but are not capable of digging down at the detailed level necessary…

They don't need to. It's "very few developers who could actually handle coding complex features and applications" job.

Re: Dropbox Engineering Career Framework

#102
post #80

Earlier quoted context omitted.

I never said anything about not being responsible for my own career. There was a previous implication that we need to help the boss look good, which is BS. If I want to develop myself because I want to explore different options or expand my skill set, I am free to and generally opt to do so. If a manager wants to develop my skills, then that is their responsibility. Again, let's not shift all the accountability to th…

I’m super curious how old you are. I’m about to hit 37, so 40 is marching closer. Love your email by the way.

Mid-40's, and many lessons learned by paying attention to those who paved the way ahead of me. Don't get me wrong, I'm a hard worker with a reputation for keeping my promises in an industry that is infamous for the opposite (manufacturing, without getting too deep into my role in that sector for the sake of keeping this brief), so I can't really complain about my wages or the recognition I have gotten in the past. But it's still just a job. My real life is my family, my hobbies and my adventures. When strangers ask me what I "do," I generally like to reply with those things rather than talking about work.

As for the email, it was part of a now-dead idea that grew out of boredom one evening while chatting with some old computer friends, and definitely involved different sounding farts. Never really got past a few lines of code, but I have been thinking about using the domain for a cranky old git blog or something.

Re: Dropbox Engineering Career Framework

#103

Earlier quoted context omitted.

Senior who doesn't deliver (write code) is not a senior. Beating about the bush in meetings is easy, executing the stuff isn't.

Writing code is easy when you have a spec to work to. It more or less writes itself - see Getting that spec is damned hard. What do i mean by spec? Basically are you going to build the right thing. A hard problem - if you think it’s easy, it more than likely means you didn’t understand the problem. The reason pinning down a spec is so hard is because at the macro level, there are very few actual solutions - mostly on…

> Writing code is easy when you have a spec to work to. It more or less writes itself - see I'm sorry, but it's hard to take your comment seriously when your definition of "spec" is AoC puzzle.

Re: Dropbox Engineering Career Framework

#104

Earlier quoted context omitted.

One way to stand out is to be nice, funny, and make a genuine personal connection with whoever the decision makers are. It sounds cheesy but it’s worked for me back when I didn’t particularly stand out. I was competent though, which is always a requirement; this won’t work for smooth talkers only.

First you got to get through the HR process. Now when I interview you, I’m not going to ask you to reverse a btree on the whiteboard. I’m going to ask you questions to see if you can “handle ambiguity” and work at the scope I need you to work at. I’ve spent the last decade mostly as one of the early technical hires for a major new initiative and then leading cloud consulting projects (3.5 years at Amazon and now at a…

> First you got to get through the HR process.

You don’t, actually. People love to be flattered, and the trick is to go find whoever is making the decisions and to flatter them.

You’re not immune to this either. No one is. Again, competence is a requirement, but flattery plus competence is a very powerful way to distinguish yourself.

Re: Dropbox Engineering Career Framework

#105
post #80

Earlier quoted context omitted.

> If the manager wants to develop my talent, then they need to get off their over-priced rear ends and do so. You are responsible for your own career. When (hypothetical) you get ready to look for another job, do you really want to only be able to say that you were a ticket taker or do you want to be able to say you led initiatives? Even if you don’t really care about getting ahead, you still have to be able to stand…

I never said anything about not being responsible for my own career. There was a previous implication that we need to help the boss look good, which is BS. If I want to develop myself because I want to explore different options or expand my skill set, I am free to and generally opt to do so. If a manager wants to develop my skills, then that is their responsibility. Again, let's not shift all the accountability to th…

I don’t define myself by my career. But I do make damn sure I stay competitive. I’ve had 10 jobs in 28 years and 8 since 2008. I stay prepared to look for another job at a moments notice.

The “team” doesn’t care about you being competitive when you are looking for your next job.

Re: Dropbox Engineering Career Framework

#106
post #98

Earlier quoted context omitted.

> If the manager wants to develop my talent, then they need to get off their over-priced rear ends and do so. You are responsible for your own career. When (hypothetical) you get ready to look for another job, do you really want to only be able to say that you were a ticket taker or do you want to be able to say you led initiatives? Even if you don’t really care about getting ahead, you still have to be able to stand…

My main motivation for impactfulness is just making my job more pleasant: Nothing is more soul-sucking than fixing the same kinds of issues over and over because the powers that be are convinced they're doing it right, and you're the one stuck fixing the issues they create.

My main motivation is for my resume to look good for my n+1 job. I don’t always know when I’m going to be looking or whether it’s by force or by choice. But I always want to be prepared

Re: Dropbox Engineering Career Framework

#107

Earlier quoted context omitted.

First you got to get through the HR process. Now when I interview you, I’m not going to ask you to reverse a btree on the whiteboard. I’m going to ask you questions to see if you can “handle ambiguity” and work at the scope I need you to work at. I’ve spent the last decade mostly as one of the early technical hires for a major new initiative and then leading cloud consulting projects (3.5 years at Amazon and now at a…

> First you got to get through the HR process. You don’t, actually. People love to be flattered, and the trick is to go find whoever is making the decisions and to flatter them. You’re not immune to this either. No one is. Again, competence is a requirement, but flattery plus competence is a very powerful way to distinguish yourself.

I am very immune to flattery at 50 years old. While like I said I don’t do coding interviews, I am asking behavioral questions to assess whether you are “smart and gets things done”.

I don’t hire ticket takers for the most part.

Re: Dropbox Engineering Career Framework

#108
post #41

When reading BigTech career ladders like this one, I immediately fall into the trap of projecting myself onto the ladder, and getting upset when the level I've chosen for myself is described as something that sounds far removed from what I want to do. I must remind myself to frame this as how Dropbox describes the things that they value in each position. An L7 SWE is the most valuable SWE in Dropbox, as measured by t…

> instead should attend a lot of meetings, craft long-term visions, influence strategies, and probably cross-functionally synergize paradigms or something I never understand how this is supposed to happen. As an employee of a company, no matter the level, don't I need to do the tasks that are assigned to me by the higher level? Be they "write code" or "attend meetings" or "write an architecture document" or whatever?…

It's your manager's job to navigate you to a higher level.

Re: Dropbox Engineering Career Framework

#109
There is not much insight to glean from these career framework docs. The high level takeaway is roughly that a junior engineer should own a feature, a mid-level should own a collection of features and a senior engineer should own a product or a significant chunk of a product and so on.

The docs are frequently developed by the HR function with only incidental input from the actual professionals who are on these career ladders. The input is usually given only by senior executives who have not actually performed the roles that represent 80% of the company by headcount in a decade.

You may notice that the descriptions of responsibilities are both extremely vague and quite expansive. This is by design. The purpose of these frameworks are as follows:

1. To provide maximum flexibility in termination of an employee: Since the framework is essentially impossible to comply with in its entirety, if the manager or management chain of an employee wants to fire them, they can readily develop a plausible sounding justification. 0% of the employees of the company always do all the things listed on in the career framework, so there's always a justification to fire someone. This takes the form of something like "Your performance did not meet XYZ Inc's high standards. You did not complete framework section 6, bullet 3 when you were running project ABC. You aren't meeting the expectations for your job and level, so you are terminated effective immediately."

2. To provide flexibility for justifying promotions or lack thereof: Despite ostensibly having a rigorous process with checks and balances and extensive discussion, the promotion process at large tech companies is largely a subjective discussion that may or may not take into account the contribution impact of the employee. The discussions fall prey to anchoring, herding, and perhaps most importantly lack of blinding (e.g. I can see who is making what arguments, so I can tailor my position to them). Having a broad and vague role description lets the final decision maker justify a positive promotion outcome ("well, X did ABC and that's right here in the L5 description") in almost all cases. At the same time, it lets managers who fail to get their reports promoted say "feedback was that you didn't do Y, which is clearly listed in the L5 role profile."

Re: Dropbox Engineering Career Framework

#110
post #62

Earlier quoted context omitted.

Writing code is easy when you have a spec to work to. It more or less writes itself - see Getting that spec is damned hard. What do i mean by spec? Basically are you going to build the right thing. A hard problem - if you think it’s easy, it more than likely means you didn’t understand the problem. The reason pinning down a spec is so hard is because at the macro level, there are very few actual solutions - mostly on…

Mostly the spec is crap and must be rewritten so…

Planning is very useful even though things never go according to plan, honest.
Post reply on HN