查看: 1568|回复: 5

[职场感言] zz how_to_be_successful_at_amazon_or_any_other_large

[复制链接] |试试Instant~ |关注本帖
lhn9021 发表于 2016-10-4 13:30:21 | 显示全部楼层 |阅读模式

2014(1-3月)-[]CS硕士+1-3年 - 内推| 码农类全职@Amazonfresh grad应届毕业生


您需要 登录 才可以下载或查看,没有帐号?获取更多干货,去instant注册!

本帖最后由 lhn9021 于 2016-10-4 13:30 编辑 .1point3acres缃

https://www.reddit.com/r/cscaree ... or_any_other_large/

Please take all of this with a grain of salt. Your individual results may vary. Some results not typical. Feel free to comment with your own contributions and/or corrections. Please do not base your career decisions solely on this post.
You have been warned.
Now, back to the point.
What to do
  • Get an mentor outside of your immediate team. Someone that works on roughly the same thing you do but is at least a few degrees of management away from you. You need someone to serve as your godfather/godmother who can answer politically sensitive questions. Try to find someone who is at least one level above you and has a few years under their belt. Ask around for people who are considered good mentors. The best engineers are not necessarily the best mentors and vice versa. Sensitive questions are things that, if you asked your manager, they would talk around it or take offense. In general, questions that you would never ask face-to-face if you wanted to have any shred of leverage. One example, is my project enough to get me to the next level? Any manager will respond saying “Yes, of course” because they want to keep you focused.
  • Get an on-boarding mentor on your team. Typically, your manager will ask someone who has been on the team for longer than you to do this. This mentor will answer your day-to-day question like “How do I set-up my environment”.
  • Start small and work up from there. It’s very tempting to choose to work on big (relative to SDE I) things right out the gate. Start small and work from there. Management cares about two things.
  • . 鐗涗汉浜戦泦,涓浜╀笁鍒嗗湴
    • Predictability. You don’t have to be the best engineer. You need to make sure stuff gets done well enough but on time. Someone who produces OK but not great code continuously and is on-time and makes good estimates is better than the person who writes great code and solves the most complex problems in the eyes of management. Managers have schedules and need to adhere to them. Likewise, either be at the top of your game or get out. Managers have zero tolerance toward flakiness.
    • Find out what your managers “fitness function” is. Also known as KPI (Key Performance Indicators) or OKR (Objectives and Key Results; the name is used by Intel and Google but all managers have these). Every manager has quanitative metrics around how well a team is doing. Common metrics at Amazon include trouble ticket count, high-severity trouble-ticket count, OPS (basically total amount of cash earned), latency (how fast things work), etc. Find out what the team-wide and organization-wide goals are. Work to achieve them. Use these as guides for your personal goals.
    • Write good code. A good litmus test is how many comments do your code reviews have relative to the size. When I started, my code reviews consisted of mostly comments around how to better structure my code. Now they are mostly small things (find a better name for that method, add a comment here, etc.)***
      *** Good code is subjective. I once rewrote a major piece of JavaScript because it had a bunch of leaky abstractions without telling anyone. The WDE (Front-end engineer) who originally wrote it flipped out and wrote some less than positive things on my review saying I was over-complicating things. Keep in mind who your audience is.

  • Document everything! If it’s not on paper, it didn’t happen. Some ideas include...
    . 鍥磋鎴戜滑@1point 3 acres
    • Having a personal “resume” wiki page with a running list of accomplishments with hard numbers and links to more details. Be specific with regard to what you personally did and what metrics you achieved. For example, “Implemented a distributed cache that reduced page loading time by 90% from 100ms to 10ms”. Have a link to the project wiki.
    • For each task you work on, write a paragraph that encompasses the following. It sounds stupid, but having a paper trail is half the battle. Do this even if it is a small task. Your career lives and dies by how well your successes are documented. Drop your failures on the floor and hope people forget. NEVER EVER bring up a failure more than once.
      • What you will do
      • Key decisions
      • Test plan
      • Operational considerations
      • Results

  • Ask for frequent anytime feedback. I like to do so after the end of a major project, so roughly every 3 months.
  • Avoid projects where you are the only person working on it. Not having other people review your work frequently will mean you are forgotten come review time. You want to be at the top of your manager’s minds.
  • Avoid being loaned out to other teams UNLESS it is for a serious project. A serious project is something that has multiple senior engineers on it. Being loaned out is a kiss-of-death for you. You are doing work for another team but your current team is evaluating you. Notice the problem?
  • Avoid projects where there are no senior (at least one level above you) people in the same job on it. If you are a SDE I, avoid projects that consist only of other SDE Is. You need visibility from SDE II+ to advance.
  • Avoid projects (and teams for that matter) that need SDEs for simple front-end and configuration changes. You need some meaty work. I was stuck with a shitty carousel that was sent for UX redesign N+1(!!!!) times before management was happy (talk about too many cooks in the kitchen). Each iteration took about a week from getting a new design to management reviewing what was going to be deployed. By the time everyone arrived to something everyone liked, the feature became a static image. I had another colleague (SDE) who became a de-facto HTML helper for various business people. Most of these people could not bother to RTFM, so he was roped in to do it for them.
  • Avoid ops-heavy teams. On these teams, SDE I’s get to do the majority of the ops work while the senior people get to work on important stuff. Once in a while, you will get a morsel to work on if your manager is decent. If not, I would find another team before doing more bitch work.
  • If you think you are going to work with Golang, React , Node or some other new technology, Amazon is not the place for you. Most of the stuff Amazon does is enterprise flavored Java/Spring with pockets of other things. Every now and then,, you find a team who is using Scala. I feel that there is a direction correlation between the number of senior engineers and the amount of new stuff a team uses.
  • Remember that this is just a job. At the end of the day, it’s like any other business transaction. Treat it as such. Don’t get emotionally involved.
  • Push back on unreasonable deadlines. Recruit others if you have to.
  • In meetings, don’t be caught without hard numbers. If nothing else, have back of the napkin estimates ready. Also, don’t be caught without an answer in a meeting. If you don’t have an answer, take a note of what the question was and who asked it. Follow-up with them ASAP! Do not bullshit an answer either. People can smell it.
  • On that note, be THE EXPERT on whatever components you own. When someone asks a question, answer it and add it to a wiki. Don’t be caught without an answer.
  • Most low-level SDE managers are only loosely technical, if at all. By loosely technical, e.g. they made an Android app or used AWS to build something. I would put it at the level of an undergraduate project, maybe a notch higher. That said, you become an SDM at Amazon by managing SDEs at Amazon (as a L6 Senior SDE that is serving as a team lead) or as an SDM /TPM at another company. In my time at Amazon, there were two SDMs that truly grokked the tech. One was an SDE on the same team for about 5 years and became the team’s SDM, the other was a PhD who had also served at Amazon for many years and built the system in question. Notice the pattern. Managers are on a need-to-know basis with the actual technology. If anything is going to kill Amazon, it would be this. Many managers are neither technical enough to directly contribute but are also not good enough people managers to manage independent-minded Amazonians.
  • Your career lives and dies by what happens in the OLR meetings (Organizational Leadership Review). It's the semi-annual meeting that managers stack-rank their subordinates. They typically happen in February and early September/late August. You get bucketed into one of 5 categories for technical skills (Outstanding/Exceeds/Achieves/Improvement Needed/Unsatisfactory) and 3 categories for leadership (Role Model/Solid Strength/Improvement needed). Getting any combination that includes Unsatisfactory or Improvement needed means you are on your way out. Likewise, not getting Exceeds or above means you are still on your way out, just not this cycle. Think of it as an A/B/C/D/F grading system. The company wants to keep people who are at least a B. The difference between Exceeds and Achieves is usually pretty small. Likewise, the difference between Achieves and Improvement needed is only slightly larger. It's very important to get Exceeds or better. Otherwise, you will get the shitty projects and your management will not listen to you. Remember when I said, the difference between Achieves and Improvement Needed is one cycle. In general, you want to avoid getting the same rating twice in a row (Read Topgrading by Bradford Smart if you are interested in the why). Low/mediocre performers are expected to self-select out after a few years.

As much as I hate to admit it, you are destined for an organization where consistently get the mediocre rating. Maybe it won't be in the same company, but it will be somewhere. It's like dating where people date up and down until they eventually settle for something in the middle.
  • Do not ruin your reputation. It takes 20 years to build a reputation and about 5 minutes to ruin it. Do not let anyone think you are anything but the best. One mistake can be written of as an accident, twice is a problem. If you find yourself in this situation, leave. You need to reset your trust by going elsewhere. You will be amazed how many people make decisions on reputation alone.
  • Sit back and take it. If you do don't like something, make it known. After all, only the squeaky wheel gets the grease.
  • Never ever be negative. Like I said earlier, drop your failures to the floor and sweep them away. There is a reason people call them "learning experiences" and not "failures", the connotation is totally different. I didn't fail to deliver a feature on time, I learned that additional complexity is to be expected.
  • Do not make the same mistake twice. Once is okay, twice is a problem.
  • Do not ask the same question twice, it makes you look stupid.
  • Do not ask for help until you have throughly explored the problem. I like to keep a counter for the number of times I ask for someone else's opinion and set a daily quota for myself.
  • Do not assume that management is on your side. You should operate with a mercenary mindset. There are no loyalties. It's more like "the enemy of my enemy is my friend". Hold management accountable for what they say and what they do. Be ready to present hard evidence for or against your position. In most places, there is a two-class system. Management and everyone else. Act accordingly.






ryuichist 发表于 2016-10-18 23:32:21 | 显示全部楼层
回复 支持 反对

使用道具 举报

Faraday 发表于 2016-11-11 11:18:04 | 显示全部楼层
回复 支持 反对

使用道具 举报

nana19903 发表于 2017-3-28 09:40:05 | 显示全部楼层
回复 支持 反对

使用道具 举报

续命神哈 发表于 2017-3-31 15:23:09 | 显示全部楼层
多谢 mark一下
回复 支持 反对

使用道具 举报

冻海冰河 发表于 2017-4-2 05:10:22 | 显示全部楼层
回复 支持 反对

使用道具 举报

B Color Image Link Quote Code Smilies |上传





一亩三分地推荐上一条 /5 下一条

手机版|小黑屋|一亩三分地论坛声明 ( 沪ICP备11015994号 )

custom counter

GMT+8, 2017-4-25 17:41

Powered by Discuz! X3

© 2001-2013 Comsenz Inc. Design By HUXTeam

快速回复 返回顶部 返回列表