Hacker Newsnew | comments | show | ask | jobs | submit | dpritchett's comments login

Don't get too caught up on which job role has more risk, responsibility, or communication skills.

Salaries are apportioned based on how close a job role is to the company's revenue stream. Executives come out on top because they control the money and payscales. Sales is often second because they can very easily point to new revenues and say "I brought that in". Profit center staff (most Valley engineers) would be somewhere up there because they are at least creating the actual product that the business sells. Support staff - cleaning, office managers, accounting - bring up the rear because they have the hardest time claiming responsibility for a share of the pie.

Within each of those groups you'll see normal salary dynamics based on wider market forces and hierarchy. Engineering manager's gonna make more than most of the line engineers. Comptroller will probably make more than a line engineer too even if she's considered a cost center because she's in a position of relative authority and individual responsibility.

Study questions:

- How close are you to the money?

- How legible are your contributions to the bottom line?

- Could you get significantly more elsewhere for the same role?

- Is management incentivized to retain top-shelf people for your job role?

-----


I'm so glad this post is at the top vs. the other "it seems fair to me" replies.

I also find it illuminating to compare to three other careers that I consider intellectually similar to engineering in that they are not "management", and yet they capture way more of their value in their corporate zenith (or did at some point in time when their reputations as careers were made).

- Lawyers: Lawyers aim to make partner. They become owners. None of this "engineers are afraid of risk" stuff.

- Doctors: Doctors control supply. I have met many socially odd doctors, without "negotiation skills" or "business acumen", but they don't worry about their salary precisely because this "union-like" aspect to their profession.

- Finance people: a.k.a "bankers". Most people have no better proxy for their "value" than what they agree on a job interview ("the value of your work is what people are willing to pay for it"). But "bankers" do know what their work is worth, outside of this exchange. And they know how much their peers are making, and are basically immune to the collective cluelessness that is "I don't need to know how much my peer and my boss make to be satisfied with my salary".

Engineers? No union. Meek personality and culture plus cluelessness about labor economics means they are ecstatic making 200k even if their company is making 1M+ for their work.

Some scattered thoughts here, but thank you for your post.

-----


Ok, so I've spent my career as a "line engineer" (aka programmer), but in my previous job we were heading for a crisis. I stepped up to manage because there was only so much I could do to avert the crisis by typing code. I (we) needed something done that was wider in scope than that role. I got a raise as part of that. We made things work and met our deadlines and obligations. I deserved that raise.

Now I'm back in the trenches (and happy about it), but I have a somewhat different take on management than I did before. I'm more sympathetic to management concerns, and that much more appreciative of managers who do their job well.

OTOH, I may be even more unhappy than before with managers who don't do their jobs well.

-----


Salaries don't get apportioned. You either bring value, or you don't.

If you can make a company £1m by yourself, you should have no problem getting a £500k salary.

If you and your team of nine programmers can bring in £1m then it's reasonable to pay them £48k and pay yourself £66k.

If you want to make more money, just make more money.

-----


I have never messed with panic, I read that code and I think I'd make a function that takes functions - the error handling response is the same every time. Maybe even put the list of calls in an actual list and invoke them with an iterator.

-----


The goimports tool can be used to automagically add and remove imports to your .go source files as you work. This streamlines the casual weekend hacking use case without compromising on the benefits of disallowing unused imports.

-----


It's not a silver bullet but it's definitely helped our company. We are a mostly-remote Rails-focused company with tens of people throughout the Western hemisphere. I've found my communications with clients and teammates got a lot better once we added Slack to the Google Apps + Skype setup we already had in place.

-----


I wish they'd gotten Jo's name right. Luckily her work speaks for itself.

-----


Does HN still have those frustrating title renaming rules? If so this would be a good time to insist on using them.

-----


What's wrong with the title? (Genuinely would like to do better next time.)

-----


Your title is fine, SwellJoe. I was being petty and pointing out a case where a descriptive title that didn't match the HTML <TITLE> dramatically improved the submission. I have long felt HN's title renaming policies were a bit too aggressive and I'd like to see 'em go away.

This wasn't the right venue for me to bring that up though - things have improved a good bit under dang's tenure already.

As a reference for my outdated and inappropriate axe grinding see this 2013 thread: https://news.ycombinator.com/item?id=5142851

Mea culpa.

-----


Second that - what's wrong with the title? It's descriptive, neutral, factual.

-----


It's missing an indication that she is tweeting via an intermediary.

-----


I think the important part is that she has a Twitter account, and is using it.

-----


If you propose a better title and an admin sees your comment, they'll change it if they agree it is called for.

-----


> Does HN still have

You could always check the guidelines... https://news.ycombinator.com/newsguidelines.html

> Otherwise please use the original title, unless it is misleading or linkbait.

-----


This is what adjuncting is supposed to be for - folks with industry experience moonlight as professors. The benefit is not primarily salary but networking, knowledge sharing, and helping the next generation of industry professionals.

Now it's more of a way to have 2/3 or more of the department work for unliveable wages which allows for an ever-growing administrative overhead in colleges while tuitions double every decade.

-----


As far as I know, not true at MIT, teaching is done by tenured or tenture track professors, with exceptions like this, or SF author Joe Haldeman, that prove the rule.

But, yeah, I hear from lots of sources that adjuncts making peanuts have become the rule rather than the exception in general US academia, and there's no disputing how administrators are taking over higher education, now even desiring to wrest little the faculty still control from them.

-----


Management in all organizations should be automated by AI, with copious amounts of override buttons sprinkled throughout.

Education administration is a like a thorn stuck in my mind, they make _more_ than everyone else and for the most part only act as a gas to support their own structure.

-----


This is how every bureaucracy works, whether government, commercial or academic. Once the institution has enough income/cash flow for momentum, then it attract people who are expert at operating the machine itself, rather than expert in what the machine is supposed to be accomplishing. After the first one lands, they continue to accrete.

It's hard to recognize when it starts, but you'll know it's happened once you see a lot of people who are not connected with the apparent goal of the machine, and there are posters all over the place touting whatever programs the administrators have created to justify their existence, as well as packaged training programs from motivational/educational consultants (think Franklin Covey).

-----


Ha, A fork bomb of Agent Smith crossed with Nancy in Program Outreach.

The accretion or calcification model of bureaucratic formation is compelling, something like how a coral reef grows. The randomized surface provides eddies and pockets of protection for other life to flourish, RFPs and SBIRs can nestle in a protected arena with low local competition.

I just realized that large, messy codebases also follow the reef model of bureaucracy. Hadoop is like that coral reef, providing nooks and crannies for optimizations and integrations to take hold. I used to imagine Hadoop as Whale fall [0], but it is more of a mandlebulb. Had Hadoop not provided such a rich environment the secondary ecosystem wouldn't be as vibrant. Fail to Win?

I find management structures fascinating. Whenever I interact with one I probe it to see how much autonomy each individual in it has, what rules they can bend or not follow. Once the agents participating in the bureaucracy cannot bend the rules I think it will tend towards dystopia. Maybe 1984 isn't a warning against fascism, but the natural tendency of all bureaucracies to only support them selves.

[0] http://en.wikipedia.org/wiki/Whale_fall

note: I might sound like the stereo type of a hackernews-bitcoin-libertarian, but I assure you my politics are much more nuanced than that. I don't think that bureaucracy as a structure is bad, but it needs to be managed with something akin to the voting logic in a triple redundant control circuit [1] [2]. Most bureaucracies exist within a positive feedback loop, which rewards them for growth instead of efficiency. It is like getting paid by LOC instead of 1/LOC or 1/runtime.

[1] ftp://ftp.unicauca.edu.co/Facultades/FIET/DEIC/Materias/Instrumentacion%20Industrial/Instrument_Engineers__Handbook_-_Process_Measurement_and_Analysis/Instrument%20Engineers'%20Handbook%20-%20Process%20Measurement%20and%20Analysis/1083ch1_10.pdf

[2] http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/1985002...

-----


Bummer. Her career seems to be predicated on a correlation between algorithm tests and performance. Can't expect her to seriously entertain disagreement as long as the current model is profitable for her.

Google is no more a proof of the value of algorithm tests than Github proves the value of manager-free organizations.

I was a bit horrified at the acquisition coaching comment. I did not realize that happened but of course it makes sense. Can't manage an acquihire if your devs can't pass the algorithm tests at the big acquirers. Shame.

-----


Your assumptions are false.

It is actually more profitable for me if I say that these algorithm tests are BS and completely study-able, and even the worst engineer can pass them. That easily translates into "here! buy my book and even YOU can get a job at Google!"

It's actually a much harder sell when, really, it's more like studying helps someone perform better, but only to an extent.

Oh, and the acquirers encourage studying and prep, just as most of the top tech companies do for their normal dev (and non-dev) candidates.

To be clear: my experience is that the algorithm interviews, when done properly, work reasonably well to identify intelligence/problem solving and coding skills. Those are more important at some places than others. They can work well for certain places -- but not at all. I do not think that all companies should use this process. It's not right for all places, but it's reasonably good for some.

As for Google being proof of the value of algorithm test: I think you're pulling that from a twitter conversation very much out of context.

Context: Some people were arguing that the algorithm interviews offer zero value - that you'd be at least as well off, if not better off, hiring at random.

If they truly believe that (and they appeared to be sticking to this argument), then it's absolutely relevant that not just Google, but basically all the top tech companies, use this hiring process. Could a randomly selected group of engineers build the technology at companies like Google, Facebook, Amazon, etc? I suppose that's what they must believe, and I find that pretty absurd.

If they had argued that these interviews sort of work, but aren't nearly as good as some other interview processes, then you're right that the company about Google and other companies wouldn't be relevant. And I also wouldn't have brought it up.

-----


"To be clear: my experience is that the algorithm interviews, when done properly, work reasonably well to identify intelligence/problem solving and coding skills."

Given that there is no correlation between job performance and interview score, are you saying this based on your gut instinct, or do you have objective data somewhere?

My best estimation is that the Google interview process is just a glorified fizzbuzz presentation, and that the hiring decisions are more or less made by arbitrary factors, including the nebulous "culture fit".

While it may be amusing to work through the details of doing a merge sort on a linked list in 30 minutes, it's certainly not germaine to the quotidian experience of an SWE at Google.

-----


>> Given that there is no correlation between job performance and interview score, are you saying this based on your gut instinct, or do you have objective data somewhere?

That's not a correct assumption. I suspect that you are referring to the (infamous) Google studies on this that were alleged to show this. The articles about this got many details wrong, and the study was fundamentally flawed. Remember: they only studied the people who did very well. That's like finding no link between exercise and health when you only study people who run regular marathons.

Merge sort on a linked list is a bad interview question, so I agree with you there. Good questions are problem that actually make you design a new algorithm.

-----


It may be that the studies were flawed, and that the reporting was bad, but that flavor of study has been replicated in other venues besides Google. Given that, it essentially comes down to culture being the deciding factor in these interviews. Given the stark cultural skew at Google, it's possible that the pseudo-analytic SWE interview is actually masking systematic bias in the hiring process.

-----


The question for Google is whether Page, Brin, Bak, Buchheit, and Dean passed an algorithm interview before building Google's core technologies. Hiring doctrine after the fact does not ensure a billion dollar company.

I disagree with your assertion that lambasting Google's hiring practices is an easy sell in the market. The last time I tried I was dismissed out of hand by a talent consultant.

-----


> I disagree with your assertion that lambasting Google's hiring practices is an easy sell in the market. The last time I tried I was dismissed out of hand by a talent consultant.

That... wasn't my assertion at all.

-----


How does this compare with "Did you win the Putnam?"

https://news.ycombinator.com/item?id=35079

-----


If comprehension and spelling were decoupled but still equally weighted then the aggregate score would've been significantly higher. Let's split the difference and say that 20-30% on the set of [all answers simultaneously spelled correctly AND comprehended] becomes a 25% on the "spells things correctly" axis. If we weight that equally against the "comprehension" axis then you get

  let R = 25   # reading
  let C = ?    # comprehension
  let M = 40   # reported mean

  (R  + C) / 2 == M
  (25 + C) / 2 == 40
  (25 + C)     == 80

  C == 55      # implied comprehension grade from a 40% average
If comprehension was any higher than 55% - which this anecdote certainly suggests - then the 40% aggregate score awarded is an ineffective assessment of the holistic learning picture.

This is the grade school equivalent of tossing out resumes over a single copy editing mistake.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: