|
Kyth posted:Why I'm happy in management: As an alternative POV, I can explain why I didn't end up taking a management role when it was offered to me. I interviewed all our managers who'd all been promoted from engineering. - They never get to do any technical development anymore. This makes most of them sad. - Their product is now a good team, not good code. Fixing people is a lot harder than fixing code. They have to be enough of a people-person to understand what others want, to read between the lines when people ask them for stuff, come up with socially-workable solutions, and defuse meltdowns and tantrums. Budget constraints mean they can't just toss out low performers and hire better ones. With broken code, they know that they can fix the code given enough time. That's not always the case with people and it's an entirely new skillset to learn. - There's a power differential between the manager and their team, and this requires they keep the team at a certain emotional distance. Can't always go drinking with the team like the old days, because they're the one who controls the team's bonuses and promotions, and ultimately whether or not they get fired. Non-rockstar team members will always be on eggshells around the manager to present themselves in the best light. - Being a good manager requires discipline, imagination, foresight, empathy, diplomacy, good communication, good time-management, and ambition. And those things have to be fairly consistent; they can't just slack off for a week and crunch through the next like they could to some extent with development work. - They have to let go of micro-managing. If a team encounters a technical obstacle, the manager has to pave the way for them to get over that obstacle and avoid the temptation to dive in and work on the technical problem itself. This can be hard because Solving Problems Is Fun. - They lose the possibility of sitting down and focusing on a single problem for hours at a time. Being in management means frequent context-switching and hundreds of interactions per day. I think it takes a special kind of person to embrace this kind of role, and many of the devs I've worked with would not be up to the task. I certainly didn't think I would enjoy it, so I declined the role. That said, it may be inevitable - I can't imagine still being a software developer at 60 and having significant value over some 28-year old.
|
#
¿
Jul 19, 2014 20:52
|
|
|
|
| # ¿ Apr 28, 2024 15:50 |
|
|
There's a good 30 min talk here about a guy's experience with burnout in the Ops field, although it equally applies to development. https://www.usenix.org/conference/lisa14/conference-program/presentation/lehtonen The gist is that people work themselves to their detriment in order to prove themselves to their higher ups, with a view to moving up the chain. He came to the conclusion that the higher-ups don't really care and will instead use this behavior to their own ends. And more importantly, the people you should be trying to impress are other engineers because they're the ones you're likely to be working with for the rest of your career. He also talks about the pager-duty situation. He's a consultant, so he can afford to say "sure I can be on call, for $$$", and he's been much happier because most clients balk at that.
|
|
#
¿
Dec 13, 2014 20:06
|
|
|
Personally I would never mention that I'm in the process of learning something. I know it's meant to sound like a positive thing, but to a person reviewing a stack of a hundred resumes it just sounds like "I don't know this thing, but I've heard of it."
|
|
#
¿
Jan 30, 2015 03:56
|
|
|
Isn't the reason it's standard practice for companies just to answer "Person X was employed here from <start-date> to <finish-date>" to avoid lawsuits if they decided to say something bad about Person X? If so, it sound like that questionnaire is inviting a visit from Saul Goodman.
|
|
#
¿
Mar 24, 2015 08:37
|
|
|
Twerk from Home posted:Is working in games as much of a brutal meat grinder as rumors say? A coworker of mine is leaving us to go work for Cloud Imperium Games in Austin making Star Citizen, and it's a $20k pay bump from an already fairly compensated developer position, 6 weeks total paid time off, and they don't start work until 10am. It can be. Depending on the studio there can be a lot of crunch time near the end of a project, and I've had friends in the industry do things like sleep in the office overnight to try and meet deadlines. It's a young person's game I think; younger people are more tolerant of longer crunch periods, whereas older people tend to value a better work/life balance. If it's something you're concerned about, try to get a feel for what it's like at Cloud Imperium by talking to some leads.
|
|
#
¿
Mar 25, 2015 16:48
|
|
|
Burnout can still happen even in a 9-5 job. Resource-strapped companies frequently take shortcuts and use sub-par tools to get under budget, and while this obviously results in an inferior product delivered late, I think it also causes significant "cognitive stress" in the developers as they have to deal with doing more with less. An apropos quote from Terry Pratchett:quote:“The reason that the rich were so rich, Vimes reasoned, was because they managed to spend less money. To me, these kinds of money problems can make it stressful to work, and it contributes to burnout. Even if the employee decides to switch to an 8 hour day, it doesn't get rid of that extra cognitive load. The only way to solve these at the source is to get more money, and that usually means gathering metrics showing how under-resourced your team is and what the bottom line value would be if they allocated more to your team.
|
|
#
¿
Mar 25, 2015 23:22
|
|
|
kitten smoothie posted:I also have some weird feeling of duty to my remaining teammates because they'll be screwed even further if I leave. This combined with a healthy helping of impostor syndrome is keeping me from aggressively looking for a new job. Imposter Syndrome is something I think we all feel from time to time. I think it's compounded by seeing stories of 20-year old whizkids become billionaires. But being part of the hiring process for so many years and seeing the low quality of candidates has convinced me that developer rockstars are far-and-few between.
|
|
#
¿
Mar 25, 2015 23:31
|
|
|
If you're a programmer, deadlines are not your problem. They are your manager's problem, though they'd like you to believe otherwise. My litmus test on this is "if we miss this deadline, who is going to die?". The answer is invariably "no-one", though your manager might lose a few hairs. Development is supposed to be sustainable, and that's one of the goals of Agile. The agile manifesto recognizes that developer estimates are always way off, so it's pointless to make hard deadlines for 3 months down the track. The theory is that by switching to Agile you'll gather data on how much you get done per iteration, and so you'll get a better idea of how much you can achieve sustainably in the future. No more crunches. (Well, that's the theory. In practice, there's lots of ways to do Agile wrong and screw this up) Another source of stress can be lack of focus. I work in an open plan environment where there's constant noise, and headphones don't help because there's constant interruptions for questions, support, and meetings. Productivity drops to zero because I can't get into "flow" mode. Paul Graham wrote a good article about this. He suggests that managers should propose all meetings for (say) the morning, and leave the afternoons free as pure coding time. Additionally, our workplace has a bunch of meeting rooms so I'll occasionally commandeer one as a quiet space. To echo what was said above, a lot of the older programmers seem to have a consistent productivity rate and seem to be unstressed. I'd love to know their secret. All I've observed is that (a) they don't work overtime, and (b) they don't give a poo poo about deadlines, they just make sure their manager is aware of their progress and any obstacles.
|
|
#
¿
Mar 29, 2015 21:15
|
|
|
MrMoo posted:The Agile Waterfall development model wins again. Agile is Waterfall - there's still the process of "Gather requirements, design, implement, verify with stakeholders", but it's done on a 1-2 week cycle instead of a 6-12 month one. Agile doesn't get rid of Waterfall problems, it just reduces their impact. It's (supposedly) hard to completely and irreversibly gently caress something up in 2 weeks without stakeholders keeping an eye on your progress, but you can certainly do it in 6 months. Point being, if you were crunching with Waterfall then moving to Agile 2-week iterations won't solve the crunching, it'll just reduce the crunches from 3 solid weeks to 2 days, every 2 weeks. If a team has any crunch at all, they're (glibly put) Doing It Wrong. kitten smoothie posted:The thing about working to arbitrary dates like this is that it turns priorities and incentives completely wrong. There is a large penalty for failing to deliver or slipping the date. The penalty for bugs found after release is far lower. So when crunch time hits, everyone starts trying to shovel features in as quickly as they can. QA gets just as sloppy on testing. We end up delivering a worse product and we're all stressed out, but hey, it's on time! The SAFe methodology states that Program Increment planning (where you plan for 5-6 iterations ahead) is something to give POs a rough idea of when features are going to land in the next quarter. They use the evil word "commitment", saying that the team commits to the 12 week plan. But I've also read the opposite: "As soon as you make this 12-week plan, throw it away." Because in reality it's not a commitment at all. All kinds of stuff happens in those 12 weeks to mess with the plan. People get sick, priorities shift, small stories explode due to unforeseen obstacles. "Commitment" implies "I'll take responsibility for this job and do whatever it takes to get it done on time" but to me that's just a manager trying to trick me into working my guts out to meet some arbitrary deadline. I don't want to commit to any deadline. This is why I prefer Kanban or Scrumban which don't have commitments as such. You take on the work as it comes, and it's up to the manager to measure the average rate that stories pass through the pipeline, and it's their job to optimize that rate.
|
|
#
¿
Mar 30, 2015 02:13
|
|
|
Investors hate risk. A single person that the company's progress relies on is a huge risk. They could leave, or get sick, or get hit by a bus and die. And then the company is in the shitter. If the board is not smart enough to recognize this risk and reduce it by fixing that bottleneck, that's 100% on them.
|
|
#
¿
Mar 30, 2015 06:52
|
|
|
Moving to the US is probably predicated on a US company sponsoring your visa, which is going to cost them a fair chunk of change so you'd have to be worth it. I made it to the US on an intra-company transfer visa so it was a lot easier for me. Demand is very high for good people so I think setting up some interviews might land you a few offers. But I'd choose larger companies who are used to the whole H1-B visa 3-ring circus, not plucky startups without an HR or legal department. H1-B visas regularly run out their yearly quota very quickly, so there may be significant delays in actually getting you over. If you do travel to the US for an in-person interview, be honest with immigration officials and say you're traveling for business but do NOT tell them you're looking for work in the US. If you do land a job then you'll have to wait 3-5 years for a green card, and to some extent that puts you under the thumb of the company sponsoring you. If you ever leave that company for any reason then you've got 10 days to pack up and leave the country, unless you can find another US company to pick up the sponsorship process. Once you get your green card, you're free to do whatever. There's a yearly green card lottery system, but for people from the UK it's highly unlikely to win. Choosing where in the US might depend on a few factors. If you have a significant other with close ties to family, then the East Coast can be a little easier because of the smaller time difference (5 hours vs 8 on the West Coast). Weather has a wide spectrum on the East Coast - stultifyingly hot summers in NY, buried deep in snow in winter... and further down the coast nearer Florida there are hurricanes and terrible humidity. The West Coast easily has the best weather as it's temperate all year round (well, except Seattle which is famous for its rain). However if you're thinking of the San Francisco Bay Area, the cost of living is pretty nuts as rents are very high. Take that into account when comparing salaries - $70K in Kansas would let you live like a king, whereas $120K in San Francisco will get you a closet with a view of a brick wall. Moving to Australia is probably visa-wise easier as you're a member of the Commonwealth, but I'm not familiar with particulars. The two places people seem to go are Sydney and Melbourne. The time difference to the UK is as bad as it can get, which can make it harder to keep in touch with UK relatives. Overall I hear pretty positive things from people who've moved there. The weather's nice, the people are friendly, it's a beautiful country, and the culture is essentially homogenous with the UK so there's no chance of culture shock.
|
|
#
¿
Apr 26, 2015 17:46
|
|
|
Strong Sauce posted:Right now my plan is to truncate the last few jobs into smaller blurbs while keeping the last two jobs current. I think this is a good plan. If you consider a resume to be mainly a timeline of everything you've ever done, then the most recent stuff is the most relevant because it's representative of your cumulative experience. When reviewing resumes, I tend to read the latest 2 positions and then skim the rest. To me, resumes are sales brochures, not biographical documents, so they don't need to be comprehensive. I suggest cherrypicking the interesting stuff from your previous jobs that make you look good, and word them in such a way that they show off why you're awesome. "As an intern, designed and implemented a feature on the company's timecard system" --> "Reduced payroll costs by 20% by optimizing timecard workflow."
|
|
#
¿
May 18, 2015 12:39
|
|
|
Milotic posted:I've got 3 months gardening leave prior to starting a new job, and whilst there will still be a fair amount of .NET (of which I'm very comfortable with), I'm going to be exposed to linux and python. 3 months of free time = plenty of time to learn. The python I'm not worried about, but what are good books or resources for learning about development and diagnosing issues on linux? e.g. On Windows, you'd check eventvwr, check active directory, run either procexp or procmon, ildasm, corflags and similar depending on where you thought the problem might be. Is there a good book that sort of thing for Linux? I'm finding it hard to phrase my searches appropriately. Knowing what's out there, as well as what each does would be helpful. Also I'm thinking of getting http://www.amazon.co.uk/Linux-Programming-Interface-System-Handbook/dp/1593272200/ as well. Anything better. I'm kind of in the same boat, in that a job interview I've got coming up is going to quiz me on troubleshooting Linux performance so I have to learn this stuff fast. What I'm doing first is acquainting myself with the fundamentals of Unix, Linux, and TCP/IP. Understanding processes and how they're spawned, system calls, signals, virtual memory and swap, file systems, sockets, etc. In that respect, not must has changed at all over the decades and a book like The Design of the Unix Operating System will still provide a useful foundation. But the trouble is with books about Linux tools is that they go out of date so quickly. Both the tools and the kernel move really fast. What I'd do is search for articles and StackOverflow answers, they tend to be more up-to-date and to the point. E.g. "How do I determine which process is hogging all my bandwidth?" is going to get you about 4 different answers, but a least it usually indicates the most popular tool these days. Here are some of my notes about tools to troubleshoot a slow system: - vmstat - displays check swap, memory, block io. - top - check load (# of waiting processes), CPU usage, memory usage. - nethogs / iotop - see what processes are using I/O (neither is part of a standard install on many distros) - ps - List running processes, look for processes with state ‘D’ (uninterruptible sleep, usually due to I/O) - cat /proc/<pid>/io - lists io statistics for a process (the /proc virtual filesystem has an amazing wealth of information) - lsof -p <pid> - list files opened by the process - netstat (deprecated by 'ss') - show what connections are open - df /path/to/file - show what filesystem a file is mounted on - strace -p <pid> - see what system calls are being made by a process - ulimit - control process quotas
|
|
#
¿
Jun 6, 2015 16:10
|
|
|
kitten smoothie posted:I want to be comfortable during an all day interview loop. Am I going to be underdressed wearing nice slim fit jeans and a button down? Maybe throw on a jacket? That seems to pass for business formal in Palo Alto as far as I've seen.
|
|
#
¿
Jun 7, 2015 21:39
|
|
|
Milotic posted:TL;DR: Good book on "Problem on linux in qa or production, what do?" https://access.redhat.com/documenta...Linuxnbsp7.html
|
|
#
¿
Jun 14, 2015 02:59
|
|
|
Slashdot / ITWorld had a thread on that topic recently. (Skill #0: Don't read Slashdot) http://ask.slashdot.org/story/15/06/01/1713203/ask-slashdot-what-do-you-wish-youd-known-starting-your-first-real-job In general, clear communication and good task organization skills are very useful. Something they don't teach you in a CS degree.
|
|
#
¿
Jun 15, 2015 23:55
|
|
|
Stats show that 80% of people who accept a counter-offer will quit within a year anyway. The money might be better, but it rarely fixes the systemic issues that caused the person to want to leave in the first place.
|
|
#
¿
Jul 23, 2015 00:30
|
|
|
High Protein posted:I took a hackerrank test for Amazon a while back and it was a bad experience. Main issue was that before the actual algorithm in question could be implemented, I had to read a variable-width matrix from stdin. In my years of programming c++ I've never really worked with reading stream input (and its fuckery with line endings not being consumed, etc.), especially not the last couple of years as that's all been abstracted away. I spent most of my time messing with the matrix routines instead of actually implementing anything algorithm-related. On the day, I chose Python as my language and promptly forgot how to read in a line, and mistakenly used PHP function names instead. I didn't notice until afterwards but the interviewer didn't blink because he wasn't testing my language knowledge (and of course we never even ran the code), he was testing my ability to think through an algorithm. I would hope that a decent interviewer would stop a candidate from going down a rabbithole of fixing up donkeywork code, and cut to the chase of testing their algorithms. quote:Finally, for some of the unit tests the input was set to be hidden, which I get, but also find dubious. A good example of this: Start with an array of N integers, where Array[N] = N. Then process a list of commands of these 3 types: 1) Reverse(X,Y) - reverse all the numbers between index X and Y. 2) PrintIndex(X) - display A[X] 3) PrintPosition(Y) - display the array index of number Y (1 <= Y <= N) This is trivial for a competent programmer to implement. But once N gets large, the speed of some operations can get very slow depending on the implementation. The hidden tests will only tell you is that they time out, so a good programmer should be able to at least identify the failings of the algorithm and come up with some alternative implementations. I think it's a good interview question because it exposes how people think when they come up against a problem. But I would never test this by making the programmer submit code, I just want to see their thought process.
|
|
#
¿
Sep 17, 2015 21:05
|
|
|
MeruFM posted:there must be some good ol' proverb about "future proofing" code before requirements are given
|
|
#
¿
Oct 2, 2015 06:23
|
|
|
Cryolite posted:Now, the company wants me to prepare a 30 minute presentation on a topic I know well to present to the company's CEO and CTO. In your situation, I think it'd be reasonable to push back on this by telling them exactly that. If they won't budge, then get them to defer it until the very last stage of the process when you're actually sure you want the job. Otherwise it's just not a good investment of your time.
|
|
#
¿
Dec 16, 2015 18:50
|
|
|
Xerophyte posted:This morning I was offered to relocate to San Francisco -- alternative: find another job since my office is closing -- at pretty minimal notice. SF seems neat, but isn't quite my dear, dark, dreary Sweden (fun fact: San Francisco, apparently famous for poo poo weather, gets half the rainy days and twice the sunshine hours of my beloved hometown!). This really wasn't on my radar and now I've got 3ish weeks to decide whether or not to uproot my entire life. I'm tempted, I'm in a situation where uprooting isn't impossible, but I've never been relocated halfway across the globe before so I have no clue what to expect. San Francisco doesn't have poo poo weather. It's famous for its microclimates where walking 3 blocks can feel drastically different, but the worst it gets is "oooh, it's a bit foggy and chilly." No snow, hardly any rain during winter, almost zero rain during the other months. I'd say go for it. You'd be moving to Silicon Valley, which is an incredible career opportunity as one of the world's biggest tech hubs. It's got its downsides for sure; high cost of living, and you'll be leaving a (comparative) socialist paradise. But a tech salary mitigates most of that.
|
|
#
¿
Feb 5, 2016 01:02
|
|
|
vileness fats posted:Bear in mind that becoming a US citizen / green card holder has some pretty unpleasant tax implications if you're not intending to live in the US permanently. Yes if you're a US citizen, no if you're a green card holder.
|
|
#
¿
Feb 5, 2016 08:45
|
|
|
vileness fats posted:My understanding is that green card holders are automatically considered US residents and therefore have to report worldwide income and pay US tax (subject to tax treaties) whether or not they are currently resident in the US. Green card holders have to report their world-wide assets. But the big difference is that if you become a US citizen and then decide to move to your another country, Uncle Sam will still want you to file a tax return every year. Green card holders can cut ties more easily, but as you said, there's no chance of getting a 401k out without damage. That makes sense; the incentive for putting money into a 401k is that it's not taxed, so of course they'll strongly incentivize you to keep it where it is. For comparison, the UK does something similar too. I have some money sitting there in a pension fund, and they'll tax me 50% if I try to withdraw it all in a lump sum.
|
|
#
¿
Feb 5, 2016 15:03
|
|
|
vileness fats posted:I may be used to commonwealth countries having closer ties - e.g. I was able to transfer a UK pension fund to a NZ pension fund with no issues (or cost). quote:In any case, I suppose my point was that if the intention is just to go to the US for a few years (rather than permanently), do your homework on this stuff.  The US tax system is ridiculously complicated (sometimes by design), so it's not really something you can just look up on a website and be comfortable that you've got the whole picture. If there was one set of rules it'd be easier, but then state and even county-specific rules can complicate things.
|
|
#
¿
Feb 6, 2016 00:19
|
|
|
3) programmers universally aren't good at estimating times That's the only conclusion you'll get from tracking estimates vs actuals. Agile practices take this into account by forcing you to split up the work into stories (features) and rank them by priority. So whatever release date you pick, you'll at least know you got the important stuff in there.
|
|
#
¿
May 30, 2016 18:37
|
|
|
This presentation about burnout is pretty interesting: https://www.usenix.org/conference/lisa14/conference-program/presentation/lehtonen
|
|
#
¿
Jun 9, 2016 04:40
|
|
|
Good Will Hrunting posted:they ask pretty hard algo/data structures questions and I haven't reviewed them in 2+ years and don't use a lot of them on the daily. When I went through this a year ago it was a pain to do the revision, and I immediately forgot everything the minute I left the interview. But I totally get why they focus on that. By way of contrast: At my old job, we got people to tell us about prior projects and they'd tell us stories about how they set up stuff in AWS, which we didn't use and therefore couldn't evaluate if they were geniuses or StackOverflow-script-kiddies.
|
|
#
¿
Jun 22, 2016 21:47
|
|
|
So, hands up who is resorting to plastic surgery to get a job? http://www.bloomberg.com/news/articles/2016-09-08/silicon-valley-s-job-hungry-say-we-re-not-to-old-for-this
|
|
#
¿
Sep 10, 2016 02:26
|
|
|
IC = Individual Contributor, which is fancy way of saying "Not a manager".
|
|
#
¿
Sep 14, 2016 20:04
|
|
|
Stinky_Pete posted:More important than the free food, I feel, is the clean, beautiful version control system we have here, and the fact that your odds of running into frustratingly awful code is next to none.
|
|
#
¿
Oct 4, 2016 06:24
|
|
|
sink posted:Scala, Java, and (unfortunately) Go. Folks try to avoid C/C++ unless, as mentioned, it's important for ridiculous real time performance (finance, adtech, voice/video). That said, I don't feel it's that important to learn C++ unless you're actually working on the service in question. As sink demonstrated, the field of working at scale is very broad and there are a million other things to learn that probably rank higher.
|
|
#
¿
Dec 13, 2016 05:35
|
|
|
vonnegutt posted:Also, observe the office. Do people look happy, or run down? Do people's desks show signs of stress and late hours, like trashbins full of energy drinks?
|
|
#
¿
Dec 27, 2016 23:26
|
|
|
Good Will Hrunting posted:Any advice for dealing with severe imposter syndrome when coming from a work environment where you feel like you didn't progress very much?
|
|
#
¿
Dec 28, 2016 22:56
|
|
|
A couple of years ago I spent a lot of time googling Python stuff. One time Google injected an interstitial into the search result that redirected me to a programming "game" at google.com/foobar. It turned to be a set of HackerRank-style challenges that presumably would have culminated in some recruiter contacting me.
|
|
#
¿
Jan 12, 2017 02:57
|
|
|
Steve French posted:But also, web developers are the ultimate lovely database schema creators. Schema? Schema? We don't need no stinkin' schemas!  *drives a mongo DB database off a cliff*
|
|
#
¿
Feb 9, 2017 18:11
|
|
|
Roadie posted:So, here's a warning for anybody else interested in SDE stuff at Amazon: regardless of your experience or references, they will make you take a programming test with someone watching you through your webcam the entire time.
|
|
#
¿
Feb 17, 2017 05:10
|
|
|
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. 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.
|
|
#
¿
Mar 23, 2017 21:39
|
|
|
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 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. 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.
|
|
#
¿
Mar 24, 2017 01:13
|
|
|
Doctor w-rw-rw- posted:Also, sounds like Google levels and performance reviews match what Facebook does. 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.
|
|
#
¿
Mar 24, 2017 04:07
|
|
|
|
| # ¿ Apr 28, 2024 15:50 |
|
|
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.
|
|
#
¿
Mar 24, 2017 16:55
|
|