Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Jaded Burnout
Jul 10, 2004


Zamujasa posted:

.. 18 months ..
.. Arbitration ..

Is there a :ripcord: smilie?

Adbot
ADBOT LOVES YOU

mrmcd
Feb 22, 2003

Pictured: The only good cop (a fictional one).

lifg posted:

Well now I'm becoming convinced to apply for Google. And speaking as someone with a CS degree, it spooks me too. Gotta get reacquainted with B-trees.

The things I think helped me the most in my Google interviews:

1. Doing several rounds of similar whiteboard interviews at other companies. Everyone is aping the "6 hours of marathon whiteboard coding sessions solving CS problems" style now, so going through that whole process a few times helped me not be intimidated by it and know how to work that format well. Doing practice or mock interviews with a friend and sample problems is probably also a decent​ substitute.

2. Spending a few hours each night review data structure and algorithm basics. This was literally nothing more sophisticated than reading through the Wikipedia article and then implementing my own quicksort and red-black tree, using the Java standard library source to check my work. None of this is super advanced stuff you wouldn't do as a freshman or sophomore in an undergrad CS course, but it gets really rusty after so many years doing regular jobs. The interviews are way heavy on theory versus "did you use my favorite pet nosql db?" so clearing the cobwebs out is important.

3. Recruiter sent me links to several of their published research papers, so I spent a weekend reading through them. Even on relatively old tech like Map Reduce, spending the time to grasp how that worked helped me be able to think about problems on a larger scale, and discuss them intelligently in the interview. Also after solving a game of Life type of problem, I briefly mentioned how I read the MR paper and how I might be able to adapt my solution to run that way on a massive game board. My hunch is that almost no candidates bother to do this so it plays well in committee reports.

About the only thing that you can't​ prep for is the systems design interview. That's where they drop a problem like "I want to collect location pings for every cellphone in a country. How would you design the infrastructure for this? What's the expected QPS? How much storage do we need? How could we shard it? What kind of engineering do we need to do for privacy requirements? Etc." So much of that is based on practical engineering experience, but the good news it's more important in higher levels (and candidate levelling in general) than lower ones.

Also strongly encourage everyone to look into a SRE position if you get asked about it. The interviews for a SWE-SRE ladder hire are pretty much the same, and you can transfer to regular SWE later on without any extra requirements. Plus lots of SRE work can be really interesting​, and for some reason regular SWEs think we're dark and terrifying wizards that will curse their children and cause crop failure if they cross us.

Che Delilas
Nov 23, 2009
FREE TIBET WEED

Arachnamus posted:

Is there a :ripcord: smilie?

It's not a smiley but I always think of this guy:



Edit: Though "ripcord" refers to the thing that disconnects a parachute, so I guess my pic isn't accurate. But I always like excuses to post it, heh.

Che Delilas fucked around with this message at 19:27 on Mar 23, 2017

Hughlander
May 11, 2005

Zamujasa posted:

One of the other developers is talking with a lawyer, but I'm told they won't be able to review it until Monday, and the boss wants this signed by Friday.

I believe the answer to that is, "I've retained counsel and request that your lawyer speak to mine." While prepping your resume.

FlapYoJacks
Feb 12, 2009
I don't think I have signed a vanilla employee contract form in over a decade. Always read them, always negotiate.

geeves
Sep 16, 2004

Jose Valasquez posted:

This but replace NYC with Pittsburgh and live like a king on a Google salary with the super cheap cost of living instead of living in a $3000 a month box on the street like I imagine the NYC people do.

As a bonus Uber is in Pittsburgh too so they might pay you lots of money to download all our files and go work for them :v:

I still need to setup my interview there at some point. It'd be nice to be close enough to walk to work again.

And :lol: at Uber.

minato
Jun 7, 2004

cutty cain't hang, say 7-up.
Taco Defender

TooMuchAbstraction posted:

People that work at Google are, usually, a) not jerks, b) reasonably intelligent, and c) willing to apply themselves. That's it; there's no secret sauce there.
I would emphasize (c) more. The impression I get from this thread is that people focus on passing the CS aspects of interviews. But we don't discuss that once you get in the door, it's necessary to be self-driven.

At many places it's typical for a project manager to identify the issues, rank them and hand them to a development team to solve. At places like Google/Facebook, you're also the project manager, and your development team is you. At the "5" level, managers don't tell you what to do. It's expected that you're good at CS, and you're competent at identifying projects to work on and driving them to completion. This includes selling others on the value of your idea, convincing others to join you if you can't achieve it alone, and evangelizing the project to broaden the impact once it's done.

These skills are not taught in CS classes. And many who might ace a CS test would crumble at the social aspects of the job.

A friend at Google told me once that working there was like making yourself the CEO of your own virtual company and your colleagues were your "clients"; as the CEO, it's your job to identify what their needs are and fulfill them. "Perf season" is hated by many; you have to review your 6-month history and write an essay about what impact you had and how awesome you are, supported by facts and supporting statements from your peers. It's time-consuming and stressful.

This type of job is very empowering if you have the mindset and the energy for it. But if you're the type of person who just likes working on problems and wants someone else to handle the project management, it's probably not for you.

geeves
Sep 16, 2004

minato posted:

At the "5" level, managers don't tell you what to do. It's expected that you're good at CS, and you're competent at identifying projects to work on and driving them to completion. This includes selling others on the value of your idea, convincing others to join you if you can't achieve it alone, and evangelizing the project to broaden the impact once it's done.

This is my main interest in working for Google. I have the buy in from co-workers, etc. to do certain new things or improvements, but they're always squashed by the product board who want to see their ideas in the product (I've heard the product meetings are referred to "House of Cards"). They make business cases, but there is no analysis of what the market wants to back it up. Then we have uninspired features that get trashed by 3rd party reports because we have absolutely no idea of what our users need.

TooMuchAbstraction
Oct 14, 2012

I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.
Fun Shoe

minato posted:

"Perf season" is hated by many; you have to review your 6-month history and write an essay about what impact you had and how awesome you are, supported by facts and supporting statements from your peers. It's time-consuming and stressful.

I found that attitude kind of baffling, honestly. There are so very many worse options than perf, including the standard corporate option of "your manager controls your fate, with zero recourse and zero transparency." I mean, perf is a chore, sure. But doing perf "buys" a transparent and more fair corporate structure, much like paying taxes "buys" civilization.

As for the self-direction, note that level-5 is a fairly experienced dev; most people come in at level-3 or -4, which are more along the lines of "get told to do thing; do thing effectively with a greater or lesser degree of oversight." So you aren't necessarily expected to come in being able to navigate the complete project lifecycle, build compelling design docs, identify deliverables, delegate them to others on your team, etc. etc. etc. You build up to that level.

Good Will Hrunting
Oct 8, 2012

I changed my mind.
I'm not sorry.

minato posted:

it's your job to identify what their needs are and fulfill them

This sounds a bit tedious and exhausting to do in addition to writing code, though I guess Google is way more tech-driven than the places I've worked where business considerations and the industry play a very crucial role when thinking about approaches to problems and what changes/improvements/additions may change our software down the road.

I'd much prefer someone who understands a business more than me (because that's their job lol) to do requirements gathering and me actually play devil's advocate against their ideas in a back and forth discussion then run my ideas across my manager or peer and stuff.

mrmcd
Feb 22, 2003

Pictured: The only good cop (a fictional one).

geeves posted:

This is my main interest in working for Google. I have the buy in from co-workers, etc. to do certain new things or improvements, but they're always squashed by the product board who want to see their ideas in the product (I've heard the product meetings are referred to "House of Cards"). They make business cases, but there is no analysis of what the market wants to back it up. Then we have uninspired features that get trashed by 3rd party reports because we have absolutely no idea of what our users need.

The downside is that every single IC has decided to launch a messaging app.

Munkeymon
Aug 14, 2003

Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.



Writing an essay about how great I am sounds like an exercise designed to make me uncomfortable though it's probably something I should learn to do because otherwise I'm probably dead-ending my career :\

lifg
Dec 4, 2000
<this tag left blank>
Muldoon

minato posted:

"Perf season" is hated by many; you have to review your 6-month history and write an essay about what impact you had and how awesome you are, supported by facts and supporting statements from your peers. It's time-consuming and stressful.

That sounds amazing. A soul-bearing honest self-assessment to keep you on track, and get your head out of the trees and see the forest.

I don't know why anyone would hate it. Probably people who've never worked at a company whose annual reviews used a mimeographed questionnaire from 1970.

b0lt
Apr 29, 2005

lifg posted:

That sounds amazing. A soul-bearing honest self-assessment to keep you on track, and get your head out of the trees and see the forest.

I don't know why anyone would hate it. Probably people who've never worked at a company whose annual reviews used a mimeographed questionnaire from 1970.

IMO, perf sucks not because of writing your own self assessment, but because of writing peer reviews.

(also going for promo really sucks)

Vulture Culture
Jul 14, 2003

I was never enjoying it. I only eat it for the nutrients.
When I was a manager I used to recommend all my reports keep a list of their accomplishments for their annual review, but I don't know that I would ever be ballsy enough to make employees conduct that themselves and actually base the review on it. Other approaches to feedback aren't perfect, but this sounds like a great way to promote narcissism within the company under the cloak of "meritocracy".

oliveoil
Apr 22, 2016

ratbert90 posted:

I don't think I have signed a vanilla employee contract form in over a decade. Always read them, always negotiate.

Can you do that as a junior developer at a company like Amazon, Google, Facebook, etc?

minato
Jun 7, 2004

cutty cain't hang, say 7-up.
Taco Defender

TooMuchAbstraction posted:

I found that attitude kind of baffling, honestly. There are so very many worse options than perf, including the standard corporate option of "your manager controls your fate, with zero recourse and zero transparency." I mean, perf is a chore, sure. But doing perf "buys" a transparent and more fair corporate structure, much like paying taxes "buys" civilization.
I think the results are good, but like your tax analogy, people still complain about it a lot.

I think many intelligent people have an element of self-doubt, and they have to get over that when selling themselves for job interviews. Perf means doing that every 6 months just to keep your job. (I feel this is especially hard as an SRE, whose job is less about developing stuff and more about keeping the lights on at 5x 9 reliability. Justifying that is a bit like the Pool Supervisor bit from The Day Today)

quote:

As for the self-direction, note that level-5 is a fairly experienced dev; most people come in at level-3 or -4, which are more along the lines of "get told to do thing; do thing effectively with a greater or lesser degree of oversight." So you aren't necessarily expected to come in being able to navigate the complete project lifecycle, build compelling design docs, identify deliverables, delegate them to others on your team, etc. etc. etc. You build up to that level.
Totally. I was hired as a 5, and during the interviews they made no attempt to verify that I had those skills, it was all CS questions. I had a really rough time my first couple of Perfs as a result because I didn't have the mindset of a project manager.

My point was not whether Perf and self-management is good or bad; it's that it's suited to a particular type of person, and it's good to be aware of that if you're applying. It's not all about scoring highly on CS questions (which in practice I never used). In the right hands it's incredibly empowering. For others it's a struggle.

Still, it's better than anything else I've seen. My last company's performance measurement was a joke. You worked with your manager to make up goals like "read a book about test driven design", and if you did that you'd get 100% for the goal. And of course no-one ever progressed there, and was just a 9-5 jobber who cared as much about the company as the company did about them, i.e. zero.

oliveoil
Apr 22, 2016

mrmcd posted:

About the only thing that you can't​ prep for is the systems design interview. That's where they drop a problem like "I want to collect location pings for every cellphone in a country. How would you design the infrastructure for this? What's the expected QPS? How much storage do we need? How could we shard it? What kind of engineering do we need to do for privacy requirements? Etc."

These all sound like things that require just a little experience with distributed systems, which is something you could get on your first day at some companies. How much QPS, storage is fairly basic math (I think Programming Pearls had a section on back of the napkin estimates, but if not, I've heard there are plenty of sites that will walk you through this for interview questions), and sharding is a pretty straight-forward concept.

The only one that sounds tricky is the privacy requirement stuff, which is basically what... encrypt everything at rest, plus in transit, make sure nobody has access to that data without a strict permission process auditing? Everything I've googled basically gives me nothing useful on this one.

Che Delilas
Nov 23, 2009
FREE TIBET WEED

oliveoil posted:

Can you do that as a junior developer at a company like Amazon, Google, Facebook, etc?

Yes, you can do that with any job at any level. The trick is how much they're willing to budge.

oliveoil
Apr 22, 2016
I thought those big companies just didn't budge. I remember asking both Facebook and Google recruiters and they told me those agreements were completely non-negotiable.

Che Delilas
Nov 23, 2009
FREE TIBET WEED

oliveoil posted:

I thought those big companies just didn't budge. I remember asking both Facebook and Google recruiters and they told me those agreements were completely non-negotiable.

I don't know about those companies in particular. They might not. But if it were me, and there were an item in an agreement I didn't like, I would cross it out and send it back in and to hell with whatever a goddamn recruiter says.

ToxicSlurpee
Nov 5, 2003

-=SEND HELP=-


Pillbug

oliveoil posted:

I thought those big companies just didn't budge. I remember asking both Facebook and Google recruiters and they told me those agreements were completely non-negotiable.

Aren't companies like Facebook and Google actually good enough to work for that they won't have insane contracts, though? Everybody, their cousin, their cousin's pet monkey, and the bugs that live on that monkey are all scrambling to get into Google. It seems that the worst horror stories come from either giants of the game industry or smaller companies run by a total poo poo head.

Doctor w-rw-rw-
Jun 24, 2008

ToxicSlurpee posted:

Aren't companies like Facebook and Google actually good enough to work for that they won't have insane contracts, though? Everybody, their cousin, their cousin's pet monkey, and the bugs that live on that monkey are all scrambling to get into Google. It seems that the worst horror stories come from either giants of the game industry or smaller companies run by a total poo poo head.

Pretty much. Benefits are generous, compensation is significant, formulaic, performance-based, and fair.

Also, sounds like Google levels and performance reviews match what Facebook does.

mrmcd
Feb 22, 2003

Pictured: The only good cop (a fictional one).

Perf is only a huge burden if you're trying to get promoted that cycle. Otherwise it's pretty straightforward and easy if you've kept notes or a journal of what you've worked on since the last cycle, as you just type that up. The long, detailed essays about how awesome you are is only for promo, because you're supposed to put together a packet of work demonstrating you've grown and are currently performing beyond your current level. The yes/no decision is made by a committee of people not in your direct management chain.

Supposedly this is more fair and objective than just "my manager knows my work and decided to promote me." You could argue either way on that, but there is a logic behind it.

mrmcd
Feb 22, 2003

Pictured: The only good cop (a fictional one).

Also, my understanding of the levels is:

L3 - fresh college grad to mid level eng.
L4 - mid level to experienced eng.
L5 - senior level eng, expected to be capable enough that you can be handed a important team OKR and not gently caress it up. I've also been told outright that this is the equivalent of "tenure" in that you can stay at L5 with satisfactory perf rating pretty much forever without penalty.
L6+ is basically anything where you start reliably delivering projects and work that has significant impact or uptake across a large number teams. Allegedly, you also get an owl and wizard staff to go with your buckets of money.

minato
Jun 7, 2004

cutty cain't hang, say 7-up.
Taco Defender

Doctor w-rw-rw- posted:

Also, sounds like Google levels and performance reviews match what Facebook does.
Sheryl Sandberg is responsible for bringing over (and improving imho) Google's culture to FB, so the corporate cultures are practically identical.

The biggest difference is that FB goes out of their way to make the interviewing experience consistent, fast, and pleasant, whereas Google's is haphazard and unreliable. I shadowed a couple of coding phone screen interviews at FB where it was obvious the candidate had no hope of proceeding (we even interviewed one bloke who didn't even list any programming languages on his resume) but we let them finish the 45min slot and politely answered questions afterwards. The logic is that even if they don't get in, maybe they'll refer a friend who will. Contrast with Google where I hear stories of interviewers trying to ego-trip candidates or not following up for weeks.

As I recall, for every 49 who begin the hiring process at FB, only 1 makes it inside. That makes it sound super hard, but judging by the interviews I did, many candidates would have had no hope at any other company either.


Aside: being a manager at these places SUCKS. (My ex-manager was great at it, but switched back to being an engineer after 10 years of managing). Because you don't actually get to tell people what to do, the job is constantly trying to convince engineers to work on problems you feel need attention. Even big important teams need to fight for engineer resources. And "calibration sessions" where all perf reports are collated and normalized are hellish multiweek ordeals where the entire chain of command reads almost everyone's perf packet.

I had huge respect for the management chain at FB. Everyone was razor-sharp smart and at least as good an engineer as the actual engineers themselves.

FamDav
Mar 29, 2008

oliveoil posted:

These all sound like things that require just a little experience with distributed systems, which is something you could get on your first day at some companies. How much QPS, storage is fairly basic math (I think Programming Pearls had a section on back of the napkin estimates, but if not, I've heard there are plenty of sites that will walk you through this for interview questions), and sharding is a pretty straight-forward concept.

The only one that sounds tricky is the privacy requirement stuff, which is basically what... encrypt everything at rest, plus in transit, make sure nobody has access to that data without a strict permission process auditing? Everything I've googled basically gives me nothing useful on this one.

i think a naive view of these things begets a naive response. For example, sharding isn't simply just "pick a primary key, hash and bucket", some of the things you want to consider

* shards have multiple (in)dependent axes of scalability; how do we identify when we are near the scaling limits? how do we identify how things within a shard are hitting various scaling limits?
* on what bounds do we shard? what can span shards?
* how do these shards help or hinder blast radius reduction?
* sharding can be done logically "Foo object F goes into shard S" or ex. geographically "Foo object F stuff in availability zone 1 is managed by shard S in zone 1". Are you sharding on one, the other, or both? Is one more important now?
* how do we split and rebalance shards over time? minnows become whales, and you'll need to migrate those whales seamlessly and (ideally) proactively.

The last one alone can seriously impact how you design the system, as implementation details around storage and event persistence can change migration from a complex/fragile experience to a fairly straightforward process.

more generally, i think there's two levels of thought about system design that people grow through. the first is learning how to design systems, by understanding how to combine things together (I use a key-value store here! I use a message queue there!) and coming up with cogent designs. the second is learning how to design systems that are safe and available, by removing single points of failure and containing things to static boundaries. its not just knowing how to build something but all the myriad ways it can fail. this is especially important for maintaining/modifying services that exist and have consumers, as you no longer have the benefits of greenfield development or the ability to gently caress up in production.

i think we're getting better as an industry about making the first thing easier to learn through more intuitive and accessible infrastructure as well as whitepapers, but we're not doing a great job of externally communicating the second.

Pollyanna
Mar 5, 2005

Milk's on them.


Hm. I should hit the books on algorithms and data structures, and really, really knuckle down on graph theory and problems. CtCI is waiting for me to open it up again, is stuff on Coursera etc. also good? Any specific recommendations?

minato posted:

I would emphasize (c) more. The impression I get from this thread is that people focus on passing the CS aspects of interviews. But we don't discuss that once you get in the door, it's necessary to be self-driven.

At many places it's typical for a project manager to identify the issues, rank them and hand them to a development team to solve. At places like Google/Facebook, you're also the project manager, and your development team is you. At the "5" level, managers don't tell you what to do. It's expected that you're good at CS, and you're competent at identifying projects to work on and driving them to completion. This includes selling others on the value of your idea, convincing others to join you if you can't achieve it alone, and evangelizing the project to broaden the impact once it's done.

Goddamn that's hardcore. I have to admit, though, that's something I've been missing a bit in my own career. Some reasons this can be difficult to pull off, though:

- Not knowing the business needs or requirements for an ongoing concern, or not being in the loop business-wise
- Not being trusted to make business decisions/being considered too low-level
- Not being interested enough in what's going on (who gets excited over life insurance?)

Is this something that's addressed in these cases?

quote:

A friend at Google told me once that working there was like making yourself the CEO of your own virtual company and your colleagues were your "clients"; as the CEO, it's your job to identify what their needs are and fulfill them. "Perf season" is hated by many; you have to review your 6-month history and write an essay about what impact you had and how awesome you are, supported by facts and supporting statements from your peers. It's time-consuming and stressful.

:yikes:

quote:

This type of job is very empowering if you have the mindset and the energy for it. But if you're the type of person who just likes working on problems and wants someone else to handle the project management, it's probably not for you.

Yeah, I can see myself immediately putting my foot in my mouth if I end up doing a job like this. I mean, I can do it - lord knows I've been outspoken about stuff at my current job - but I can't guarantee not accidentally pissing someone off by doing so.

geeves posted:

This is my main interest in working for Google. I have the buy in from co-workers, etc. to do certain new things or improvements, but they're always squashed by the product board who want to see their ideas in the product (I've heard the product meetings are referred to "House of Cards"). They make business cases, but there is no analysis of what the market wants to back it up. Then we have uninspired features that get trashed by 3rd party reports because we have absolutely no idea of what our users need.

Hahaha, yeah, that's what my current job is like. A lot of decisions being made by people who are clueless and begrudgingly followed by people who heavily disagree and are uninspired by the whole thing. It's a killer, and I hate it.

TooMuchAbstraction posted:

I found that attitude kind of baffling, honestly. There are so very many worse options than perf, including the standard corporate option of "your manager controls your fate, with zero recourse and zero transparency." I mean, perf is a chore, sure. But doing perf "buys" a transparent and more fair corporate structure, much like paying taxes "buys" civilization.

Perf is still reviewed and evaluated by management, so it just shifts the onus of reporting and reviewing onto the employee. It doesn't sound all that different from typical management to me.

quote:

As for the self-direction, note that level-5 is a fairly experienced dev; most people come in at level-3 or -4, which are more along the lines of "get told to do thing; do thing effectively with a greater or lesser degree of oversight." So you aren't necessarily expected to come in being able to navigate the complete project lifecycle, build compelling design docs, identify deliverables, delegate them to others on your team, etc. etc. etc. You build up to that level.

That's good, at least - I just wouldn't want to see L3 and L4's opinions and buy-in being discounted or ignored.

Good Will Hrunting posted:

This sounds a bit tedious and exhausting to do in addition to writing code, though I guess Google is way more tech-driven than the places I've worked where business considerations and the industry play a very crucial role when thinking about approaches to problems and what changes/improvements/additions may change our software down the road.

I'd much prefer someone who understands a business more than me (because that's their job lol) to do requirements gathering and me actually play devil's advocate against their ideas in a back and forth discussion then run my ideas across my manager or peer and stuff.

That's my view on the whole thing as well. I don't necessarily have a pulse on the core business needs just due to the fact that hierarchies and departments exist, so I can't always make an accurate and informed decision.

mrmcd posted:

The downside is that every single IC has decided to launch a messaging app.

why though

lifg posted:

That sounds amazing. A soul-bearing honest self-assessment to keep you on track, and get your head out of the trees and see the forest.

I don't know why anyone would hate it. Probably people who've never worked at a company whose annual reviews used a mimeographed questionnaire from 1970.

Writing these reviews sound like when your dad gets mad at you and makes you recount what you did wrong and how to not do it the next time. At least, that's how it was for me...

b0lt posted:

IMO, perf sucks not because of writing your own self assessment, but because of writing peer reviews.

I have a policy of not loving up my coworkers' prospects because we're already in a vulnerable position against the weight of whatever large corporation we work for, so I would have an agenda for these peer reviews. Everyone does, it's never an objective thing and I really don't like the idea of relying on those for evaluation.

Vulture Culture posted:

When I was a manager I used to recommend all my reports keep a list of their accomplishments for their annual review[...]

What accomplishments are worth keeping a list for? "Managed to get that one feature done on time" sounds like cheap padding at best, tone-deafness at worst. What should I shoot for to make that list bigger?

quote:

[...]but I don't know that I would ever be ballsy enough to make employees conduct that themselves and actually base the review on it. Other approaches to feedback aren't perfect, but this sounds like a great way to promote narcissism within the company under the cloak of "meritocracy".

Yeah, same. Kinda overstepping bounds, IMO.

minato posted:

Still, it's better than anything else I've seen. My last company's performance measurement was a joke. You worked with your manager to make up goals like "read a book about test driven design", and if you did that you'd get 100% for the goal. And of course no-one ever progressed there, and was just a 9-5 jobber who cared as much about the company as the company did about them, i.e. zero.

That's what my current company does and it sucks, especially when working towards those goals is being discouraged in favor of getting an overdue and overpromised product out the door. :/

mrmcd posted:

Also, my understanding of the levels is:

L3 - fresh college grad to mid level eng.
L4 - mid level to experienced eng.
L5 - senior level eng, expected to be capable enough that you can be handed a important team OKR and not gently caress it up. I've also been told outright that this is the equivalent of "tenure" in that you can stay at L5 with satisfactory perf rating pretty much forever without penalty.
L6+ is basically anything where you start reliably delivering projects and work that has significant impact or uptake across a large number teams. Allegedly, you also get an owl and wizard staff to go with your buckets of money.

That makes me feel a little better. I'd fall into the middle-late of L3 here, which is as good a place to start as any.

FB does have a Boston office, I think...I could apply to FB too. I don't like PHP though. If they do Elixir or Clojure that'd rule!

Vulture Culture
Jul 14, 2003

I was never enjoying it. I only eat it for the nutrients.

Pollyanna posted:

What accomplishments are worth keeping a list for? "Managed to get that one feature done on time" sounds like cheap padding at best, tone-deafness at worst. What should I shoot for to make that list bigger?
I was an IT manager, so it was more project-driven. The basic rules are the same, though: focus on the value that you add. What features did you launch, and how did it improve user acquisition, retention, revenue, other KPIs? How did you try to maximize those values? (If your organization sucks so bad that you have no idea what impact your feature had, you've got less to work with. Also, if that's you, you should definitely work somewhere else.)

Basically, I mandated that my employees bring great resumes to their performance reviews that they could shop anywhere else they wanted. And despite the pretty bad pay of the org, I had zero turnover on a ten-person team except for a guy whose family situation mandated he return back to Sweden (he was heartbroken about leaving). Turns out people like the work they do, even when it's hard, when they understand the impact it has.

Vulture Culture fucked around with this message at 15:06 on Mar 24, 2017

TooMuchAbstraction
Oct 14, 2012

I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.
Fun Shoe

Pollyanna posted:

Goddamn that's hardcore. I have to admit, though, that's something I've been missing a bit in my own career. Some reasons this can be difficult to pull off, though:

- Not knowing the business needs or requirements for an ongoing concern, or not being in the loop business-wise
- Not being trusted to make business decisions/being considered too low-level
- Not being interested enough in what's going on (who gets excited over life insurance?)

Is this something that's addressed in these cases?
My team at least has done a good job of keeping team members in the loop as far as what our grand vision, intermediate goals, and short-term goals all are. And in general I get the impression that if you want to go to a meeting that's related at all to your team's work, then you can. So you should be able to get the knowledge you need, then it's "just" a matter of applying that knowledge to come up with plans, and convincing other team members that your plans are solid.

quote:

Yeah, I can see myself immediately putting my foot in my mouth if I end up doing a job like this. I mean, I can do it - lord knows I've been outspoken about stuff at my current job - but I can't guarantee not accidentally pissing someone off by doing so.

One of the biggest things about the Google culture (which I dearly hope has been transplanted to other successful tech companies) is that it is blame-free. Accidents happen, people gently caress up, the answer is not to punish the upfucker, but rather to analyze what went wrong, what didn't go wrong, where we got lucky, and what we should do to make sure that this doesn't happen again. This entire process is called a "post-mortem", and having to perform one might be personally mortifying, but it's not an actual punishment.

quote:

Perf is still reviewed and evaluated by management, so it just shifts the onus of reporting and reviewing onto the employee. It doesn't sound all that different from typical management to me.

The difference is that every employee does peer evaluations, and you get to read what everyone else had to say about you. This makes it a lot harder for a dictator manager to wield power with impunity. Also, managers do not have unilateral authority to block horizontal transfers within the company, so any such dictator would shortly find themselves without a team to lead.

quote:

That's good, at least - I just wouldn't want to see L3 and L4's opinions and buy-in being discounted or ignored.

Absolutely not -- part of being an L3 or L4 is that you're expected to try to operate at the "next level", and part of being a higher-level is guiding the L3/L4s and helping them to do that effectively.

quote:

I have a policy of not loving up my coworkers' prospects because we're already in a vulnerable position against the weight of whatever large corporation we work for, so I would have an agenda for these peer reviews. Everyone does, it's never an objective thing and I really don't like the idea of relying on those for evaluation.

Politics is unfortunately not something Google has managed to get rid of, so yes, this is a potential factor. People are encouraged to be honest instead of blowing smoke, though, and there is a confidential feedback option if there's something you need to tell your manager that you don't want your peer to know you said.

quote:

What accomplishments are worth keeping a list for? "Managed to get that one feature done on time" sounds like cheap padding at best, tone-deafness at worst. What should I shoot for to make that list bigger?

Honestly I just keep track of my day-to-day accomplishments in short sentences. Like, today I implemented this function, today I wrote this design doc, etc. During perf time it doesn't take too long to go through all that and get a sense of what my overall accomplishments were, and from that I can build up more grandiose "lead development of X critical component" statements.

mrmcd
Feb 22, 2003

Pictured: The only good cop (a fictional one).

This thread reminded me I still have one more non-promo peer review to do. :cry:

Hughlander
May 11, 2005

Zamujasa posted:

The advice to :sever: is basically exactly what I'm taking. I was waffling on it because I like the stability even though the job sucks, but this flaming turd really pushed me past that point.



One of the other developers is talking with a lawyer, but I'm told they won't be able to review it until Monday, and the boss wants this signed by Friday.


This is the nuclear option I'm considering. I really, really don't like this agreement, and I'm in a position where if I'm let go there's literally nobody else here who knows how to maintain poo poo.

So it's Friday and i'm going to be :f5:ing this thread like a motherfucker ; I expect updates and not blue balls.

Pollyanna
Mar 5, 2005

Milk's on them.


Vulture Culture posted:

I was an IT manager, so it was more project-driven. The basic rules are the same, though: focus on the value that you add. What features did you launch, and how did it improve user acquisition, retention, revenue, other KPIs? How did you try to maximize those values? (If your organization sucks so bad that you have no idea what impact your feature had, you've got less to work with. Also, if that's you, you should definitely work somewhere else.)

Basically, I mandated that my employees bring great resumes to their performance reviews that they could shop anywhere else they wanted. And despite the pretty bad pay of the org, I had zero turnover on a ten-person team except for a guy whose family situation mandated he return back to Sweden (he was heartbroken about leaving). Turns out people like the work they do, even when it's hard, when they understand the impact it has.

In my year+ working here, there's really only been a few features that have launched to benefit people, and those were for an internal business tool. The use within the company improved, sure, but the features were such a pain in the rear end to develop that they caused us to take a step back and start thinking about what we were doing, and how we could improve our workflow+codebase. That could be something.

On my new dev team/product team, we haven't even shipped a product yet, and we don't have any idea of what value any of these features bring until the product is actually shipped. User acceptance testing and KPI stuff won't happen until we're done making it, which I feel is the absolute wrong thing to do and for various reasons the project is blowing up anyway. It's a huge disappointment and one of the reasons I'm looking to move on.

My resume has only barely marginally improved while working here. I can barely claim to have done anything worthwhile, and it sucks.

TooMuchAbstraction posted:

My team at least has done a good job of keeping team members in the loop as far as what our grand vision, intermediate goals, and short-term goals all are. And in general I get the impression that if you want to go to a meeting that's related at all to your team's work, then you can. So you should be able to get the knowledge you need, then it's "just" a matter of applying that knowledge to come up with plans, and convincing other team members that your plans are solid.

That's good to hear. My current workplace has us all silo'd away and teams barely communicate except in the break room where people bitch about other teams and take potshots at certain key figures that gently caress things up (long story).

quote:

One of the biggest things about the Google culture (which I dearly hope has been transplanted to other successful tech companies) is that it is blame-free. Accidents happen, people gently caress up, the answer is not to punish the upfucker, but rather to analyze what went wrong, what didn't go wrong, where we got lucky, and what we should do to make sure that this doesn't happen again. This entire process is called a "post-mortem", and having to perform one might be personally mortifying, but it's not an actual punishment.

We did post-mortems at my last workplace, and ostensibly it was blame-free, but people got disciplined or fired over them anyway. I find the idea hard to trust as a result.

quote:

The difference is that every employee does peer evaluations, and you get to read what everyone else had to say about you. This makes it a lot harder for a dictator manager to wield power with impunity. Also, managers do not have unilateral authority to block horizontal transfers within the company, so any such dictator would shortly find themselves without a team to lead.

What do you do when a coworker constantly goes dark when remote/leaves after 12 each day, pushes poorly-made solutions that heavily slow down your team, doesn't offer any code review outside of "please alphabetize these things" or "changes I made to my CICD setup means your entire thing is hosed up now, please redo it all", and has managers asking around if anyone has their phone number so they can get in contact with said coworker?

Meaning, what happens when you have a complete rear end in a top hat on your team? Do you trash them in your peer evaluations, or be diplomatic?

I guess it helps with lovely managers, but lovely coworkers are often a problem too.

quote:

Absolutely not -- part of being an L3 or L4 is that you're expected to try to operate at the "next level", and part of being a higher-level is guiding the L3/L4s and helping them to do that effectively.

This is something I've gravely missed in my career so far. I've had jack poo poo for mentoring and guidance, once because of poor management and another because the person who I was assigned as a mentee is aforementioned poo poo coworker. I would give anything to get guidance like this.

quote:

Politics is unfortunately not something Google has managed to get rid of, so yes, this is a potential factor. People are encouraged to be honest instead of blowing smoke, though, and there is a confidential feedback option if there's something you need to tell your manager that you don't want your peer to know you said.

That's good that there's some confidential options, then.

quote:

Honestly I just keep track of my day-to-day accomplishments in short sentences. Like, today I implemented this function, today I wrote this design doc, etc. During perf time it doesn't take too long to go through all that and get a sense of what my overall accomplishments were, and from that I can build up more grandiose "lead development of X critical component" statements.

I...kinda like this idea, actually. Takes a good bit of discipline, but I needed to get some anyway.

lifg
Dec 4, 2000
<this tag left blank>
Muldoon

FamDav posted:

i think we're getting better as an industry about making the first thing easier to learn through more intuitive and accessible infrastructure as well as whitepapers, but we're not doing a great job of externally communicating the second.

What resources or whitepapers would you recommend on system design? I know it's my weak point; it really tripped me up on an Amazon interview.

Pollyanna
Mar 5, 2005

Milk's on them.


What's the difference between a Site Reliability Engineer and someone who does devops? I might be totally off base since devops has like a million different definitions, but I'm thinking of someone who works with tools like Jenkins, Chef, Vagrant, AWS, etc. Is it like that?

mrmcd
Feb 22, 2003

Pictured: The only good cop (a fictional one).

But in general, I would say that the perf system takes a lot of power away from dictator managers that play politics, which is good. It has drawbacks though, the two biggest ones being it requires significantly more time investment from non-manager employees, and biases against those who are uncomfortable with advocating for their work and accomplishments, either because of cultural or personality reasons. My European team members showed me a slide deck they all got as part of a "be better at perf" training that basically boiled down to: "We know it seems gross and uncomfortable and so horribly American to write long documents praising yourself, but it's ok, learn to ignore it. Promo and calibration committees won't be able to accurately assess you if you write vague accomplishments in the passive voice."

mrmcd
Feb 22, 2003

Pictured: The only good cop (a fictional one).

Pollyanna posted:

What's the difference between a Site Reliability Engineer and someone who does devops? I might be totally off base since devops has like a million different definitions, but I'm thinking of someone who works with tools like Jenkins, Chef, Vagrant, AWS, etc. Is it like that?

The specific details all depend on the company, bit SRE is a job title Google coined (I think) that's more or less interchangable with devops.

Google SRE jobs are less about "reboot the server when it dies" and more about "design and build a system that automates remediation as required for release or hardware faults; investigate reasons for elevated fault levels, mitigate then fix; become expert advisors in production systems and architecture; tell SWEs why their ideas are terrible and will burn the world down"

Edit: being on a pretty small and internal SRE team, I'm only able to set ~70k computers on fire in a single afternoon. :toot:

mrmcd fucked around with this message at 15:59 on Mar 24, 2017

Hughlander
May 11, 2005

Pollyanna posted:

What's the difference between a Site Reliability Engineer and someone who does devops? I might be totally off base since devops has like a million different definitions, but I'm thinking of someone who works with tools like Jenkins, Chef, Vagrant, AWS, etc. Is it like that?

DevOps is a philosophy that describes a way of building software with the developers involved in the architecture and running of deployments and monitoring. Site Reliability Engineering is a discipline that describes a specific type of development. If you see a role at a company called DevOps engineer, treat it the same way you would if you saw a role at a company called Scrum Engineer or Iterator Engineer. It's a place buying into buzzwords because they're buzzwords not because they've internalized what it means and is a :redflag:

minato
Jun 7, 2004

cutty cain't hang, say 7-up.
Taco Defender

mrmcd posted:

But in general, I would say that the perf system takes a lot of power away from dictator managers that play politics, which is good.
I hear Google recently tweaked their system to avoid people gaming it, where they'd release a project that had significant impact, then immediately abandon it in the next perf cycle because maintaining and supporting the old project had no impact. This apparently had led to a culture of tools and libs that were plentiful but not supported anymore.

Adbot
ADBOT LOVES YOU

Mao Zedong Thot
Oct 16, 2008


Hughlander posted:

DevOps is a philosophy that describes a way of building software with the developers involved in the architecture and running of deployments and monitoring. Site Reliability Engineering is a discipline that describes a specific type of development. If you see a role at a company called DevOps engineer, treat it the same way you would if you saw a role at a company called Scrum Engineer or Iterator Engineer. It's a place buying into buzzwords because they're buzzwords not because they've internalized what it means and is a :redflag:

Nah. DevOps is a pretty common term.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply