2,951 karma · joined August 28, 2011
If someone builds their career expectations and aspirations around what they gathered from Forbes, Techcrunch, or a TED talk, we call them entrepreneurs.
* It depicts something everyone fantasizes about and offers a quick if ultimately unsatisfying release. Who doesn't imagine themselves building something amazing and being idolized by magazines and the general public?
* It happens in an unrealistic sort of magical fairy land, often in the founder's own hazy, romanticized recollections of their past.
* It only shows beautiful companies/people. You don't need to found a space exploration company to be happy just like you don't need to be with a model.
* It offers no real guidance for how to achieve what it's depicting, leaving viewers confused at best and frustrated at worst. This article touches on the fact that people seem to think all they need is an idea, when that's not what it takes.
* It's most popular with those who are either frustrated with their careers/romantic lives, or are otherwise trying to satisfy a need they feel isn't being met. This one is a little shaky because plenty of people enjoy actual porn in healthy ways, so forgive me for the stretch.
The comparisons go on and on. How healthy your relationship with each is depends on how much exposure to the realities of each field you have had and how mature you are as a person/profession.
Almost nothing is unceremonious around here. Even employees who are on their way out are placed on performance improvement plans to give them a change to turn themselves around. I've never seen anyone fired: the closest I've seen is people leaving of their own accord to save themselves the trouble of going through the process.
https://mtlynch.io/why-i-quit-google/
As always, this is my single-sample personal view, so please don't mistake this for anything beyond that.
It's true, we do place a lot of importance on complexity and impact, which are fuzzy metrics, potentially inconsistently defined, and can be subject to circumstance. Yes, engineers do suffer the temptation to game things by releasing their work prematurely and not committing themselves to supporting it. And yes, not all managers know how to set expectations appropriately, occasionally resulting in disappointment and confusion for their employees.
However, that's the individual's perspective. Promotions serve the institution first, and the individual second, and I'd like to offer the institutional perspective.
Promotion to senior engineer is a big freaking deal. Once you are Senior, you've effectively been given the keys to the kingdom. It's the industry equivalent of tenure. Want to transfer to a team? No problem, your manager knows they're going to get someone who's been through hell and is able to deliver. Want to join another company? Great, "Senior Engineer, Google" is an indisputable mark of quality, you'll at least get an interview.
If there's one thing I've learned in my time here, it's that false positives are way more costly than false negatives. Hire someone who can't do the work? Enjoy six months of trying to grow them plus however long it takes to get them to leave and release their headcount. Promote someone who isn't indisputably good enough for the title? Enjoy watching them fail to meet expectations cycle after cycle, trying to grow them, only to watch them leave out of frustration a year later.
Yeah, it kinda sucks as an individual contributor because proving yourself is difficult and subject to external forces. That's torture for the sort of ambitious overachievers that tend to be drawn to this company. However, the thing that makes your career growth difficult is the same thing that makes the work so challenging and the work environment so pleasant.
Also, there are some recent developments the author didn't mention, and I presume he left after this was put into place. A lot of focus has been drawn away from the rank of Senior. On paper, things used to be "up or out" until Senior, even though that wasn't really applied in my experience. Now it's only "up or out" until L4, one promotion below Senior. Plus the Senior promotion process is getting streamlined somewhat, although time will tell how that plays out.
EDIT: And then there's money. Managers have enough leeway that overachieving L4s can make almost as much as an L5, so it's not like the lack of a promotion is impoverishing you.
EDIT EDIT: To give some more context on the process itself:
For non-promo candidates, we do mutual reviews. You list the colleagues you'd like to review you and list the projects you've worked on and your contribution to them. Then everyone comments on their colleagues' assessments.
Managers then get together and have a powwow in which they agree on who in their groups are giving exemplary performance at each level, and people are calibrated as above or below the models for their level.
For promo candidates, the self-assessment is much more in-depth, and a committee of unrelated people get together and perform a similar assessment, except against a more abstract rubric describing expectations at each level.
Note this is very different from: how long does it take for all the devices on the market at the time to become inactive? If these would be equivalent if (1) iPhones were homogeneous and (2) devices had a constant lifetime, but the truth is there are many models available and different devices become inactive at different rates.
Concerning point (1): As an extreme example, imagine Apple releasing a rock solid phone (iPhone RS) with a ten year lifespan followed by a crappy phone (iPhone CR) that dies in a year. Within a year of the CR's release, they'll all be inactive, meanwhile all the RS's will be plugging along (assuming they all last exactly their lifespan). Meanwhile the average lifespan will be identical to what it would be if they were released in the reverse order.
Concerning point (2): These numbers can be skewed by devices with different lifetime distributions. If we assume, realistically in my opinion, that device decay is a Poisson process, different devices with different decay rates mixed together in this analysis would render this analysis way too simplistic.
For consumers who buy the very newest of devices, this isn't a particularly helpful metric because of (1). For consumers who buy older devices, it's not very helpful because you don't know the distributions pointed out in (2).
For financial analysts, however, this is a very interesting analysis because it can be used to make predictions. For instance, if you assume the lifecycle is increasing, then you see a strong incentive for Apple to get their hands on older-but-still-functional devices so they can resell the same phone again and again. My takeaway is I'll keep an eye out for how aggressively they market the iPhone Upgrade Program.
This actually touches on an interesting point. My notorious interview company is Google. I'm not familiar enough with the Hangouts Android client to tell you anything about it, but for the sake of argument let's unrealistically assume it's trivial. Imagine you have an organization where some engineers are good enough to work on the Hangouts Android client but not good enough to work on, say, the F1 distributed database.
Internal transfers become crapshoots. Is this person good enough to work on my new, highly complex project? Should I reinterview them to make sure they can hack it? Imagine what this does to the social and cultural stratification. "Oh, those Hangouts guys are nice but they're not that impressive, it's not like they're working on the machine learning or anything." It'd be a nightmare both practically for management and socially for the engineers.
Our philosophy is: all engineers should have the chops to quickly be able to ramp up on whatever project they like. This means rejecting a lot of people, but it also means that two engineers can look at one another across the hallway and immediately know they could swap teams and not miss more than a couple weeks of productivity. When framed this way, I think the interview process is a natural consequence.
Not sure what the culture is at other places, but I hope this is a useful data point.
If my comment expresses any frustration it's with people who fail to see the point in preparing for anything more difficult than "can you use the standard library and write a for loop" type interviews and then turn around and complain about not getting hired at selective organizations that do very hard things. And then they go and issue a blanket denunciation of a process that consistently meets organizations' expectations.
To be honest, this is a fair question. For someone whose entire career has been spent coding on a single machine, with data that fits in memory, reusing pre-written O(NlogN) or faster algorithms, often with a single thread, I can see why they would ask this question.
The answer is: for what we do, there is no off the shelf solution. Our datasets almost never fit on a single machine, to the point where we make jokes about five terabytes of data being so small we forgot how to count that low. Our algorithms are almost all novel: one of my favorite interview questions starts off as a trivial string manipulation problem but then branches out into easy-to-express, easy-to-understand variations that actually require some very sophisticated algorithms to solve. When it comes to pre-built software, even our internal turnkey database solutions are so sophisticated they require a solid understanding of distributed systems and operating systems to avoid common pitfalls.
Honestly, not every person is up to the task of working in this environment. Our workforce skews towards people with degrees in CS from high-ranking universities not because we're snobby but because there are few places that teach this particular combination of skillsets. You can probably go your entire career without working for us or on the sorts of problems we try to solve, and you can just as well prepare for interviews by focusing on practical matters and not deeper algorithms and data structures knowledge. And that's fine, I'm sure there are plenty of positions out there for you.
But if you do, don't come complaining to me that our interview process is too hard or the prep process is too impractical or that we're being unfair because none of the stuff we test for is practical in the real world. You can have an easy time prepping for my interview or a job at my company, but not both.
EDIT: There is something to be said for companies that cargo cult this interview process. True, if someone can pass this interview process they’re probably pretty decent, but you have to be honest with yourself what sort of problems you’ll be solving. OP, meanwhile, expressed an feeling of blanket pointlessness without saying what kind of job he’s looking for. I hope I’ve made clear this is counterproductive for companies like Facebook, Google, Microsoft, etc.
My company doesn't really do small projects anymore, so we take a lot of care to make sure we hire people with the discipline and ability to handle large systems. There's certainly a lot of organizations that don't have that requirement, though, so some of this assessment may be a little harsh.
As for code review catching errors, that sounds great in theory, but in practice it's just rarer than you'd think. Think about it, your reviewer is always going to spend less time on your code than you did, and they're always going to have less context. I find that unless the error is egregious, it's almost never the code reviewer that catches it. You're not really a one man show, but you're pretty close.
Unit testing is by far a better approach. I catch easily ten times as many bugs in my code by unit testing it as by manual inspection and code review combined.
My time, and the time of everyone on my team, is far too valuable to be spent on teaching new hires things they should have learned on their own in junior year of college. Onboarding people means bringing them up to speed on the complexities and specifics of our own systems. We're not in the business of hiring people and holding their hand for a year until they know enough CS to be useful.
Also:
> This is not junior level knowledge. You're looking for a mid-level to senior developer with zero experience.
Zero professional experience, maybe. Zero experience period, no. This stuff is offered in almost all undergrad CS programs. If you didn't go to college or have a degree in a different field you can find tons of lists of topics for self-study. If you've ever done any project on the side, you're bound to have encountered or at least imagined a couple of these issues. Something as basic as finding the largest N elements in a array isn't a trick, it's something that should be painfully obvious to anyone who's coded for more than a month.
Sooner or later, though, that approach will come back to bite you. Milliseconds matter to the user because the longer they wait for an action to complete, the more likely they are to stop caring. They matter in settings where you're performing multiple RPCs because a millisecond of delay here and there adds up over multiple calls. Not to mention the fact that memory, CPU, and disk all cost money. And when those factors come up, you'll suddenly find yourself surrounded by people who are (at worst) incapable of addressing the situation or (at best) will need to be ramped up on the issue.
And that's just constant factor improvements. Can you imagine choosing an O(NlogN) solution over an O(N) one? Everyone thinks that's trivial, but in real terms it means a 10x speedup per thousand inputs and 20x per million inputs. That's huge.
More importantly: in interviews, a lack of care for performance suggest to me that a candidate is willing to cut corners. Once they have any old solution they pat themselves on the back and move on. We're a very self-driven organization, and in my experience if a new hire is struggling to meet expectations 6-12 months after joining, it's usually because they don't constantly ask themselves how they can improve their work and our codebase and instead expect to be told what to do.
Minor pet peeve: parallel processing is not premature optimization! If you think it is then I suggest you exercise it more. It's not as hard as people make it out to be, and at a certain point it becomes second nature. Then all of a sudden terabyte datasets start looking trivial...
* Number one is probably no Big-O performance considerations, or Big-O is an afterthought. For the love of God, please please please don't do a linear search on an unsorted array anywhere inside a nested loop. If you're going to do any appreciable number of lookups, preprocess your data into a hashmap, hashset, whatever.
* No or insufficient considerations for edge cases. What if the input array is empty? What if I pass in invalid arguments? What if the strings aren't ASCII? What if the numbers you're multiplying are very large? What if the input is coming from an untrusted source?
* No questions about the size of the input. Some of my favorite questions are those whose solutions bifurcate on whether the input can fit on in memory, or whether it's coming in on a network stream. Some questions involve multiple arrays, and I always like to ask "you assume A is much bigger than B, but what if A is much smaller than B?"
* We place a great deal of weight not just on the solution, but on justifying why that solution is the most appropriate one. More often than not, this hinges on the Big-O performance and the system on which we're running. It's a mistake to dive right in to your solution, because it robs you of the opportunity to demonstrate that you have multiple fully-formed ideas knocking around in your head and you need to choose which one to code up. Otherwise I might get the impression that you only have one way to solve a problem.
* Sorting the entire array when I ask you for the top N elements! Getting the top handful of elements is a linear-time operation, people!
Bonus points:
* No consideration for parallel processing. I've run maybe like two serial production workflows in my entire career. Try to parallelize your solution to handle bigger inputs.
* Don't forget cache performance! I usually let candidates working in Python or other high-level languages slide on this one, but those odd C/C++ candidates have a major opportunity to impress me by optimizing their memory access patterns for cache performance.
* I let this one go for intern and entry-level candidates, but testing should never be an afterthought. The moment you finish your implementation you should throw input/expected output pairs on the whiteboard. You don't even need to walk through them super carefully, just show me that you know how to design test cases.
Looking back we see clear signs of a seller's market in talent: companies went out of their way to hire anyone remotely competent. Once hired, devs could hopefully rely on their company's mentorship, training, and experience opportunities to raise themselves up, and companies could rely on the same for retention. Coding boot camps sprung up to give people just enough skills and credibility to get their foot in the door. Salaries were high.
That gold rush has since dried up. Early stage funding has plummeted. Fewer and fewer companies want to go public. Large companies like Google, Facebook, etc. now dominate their respective product categories. Why is it now difficult to find senior people? Because for someone with years of experience and/or formal training, these companies offer the holy trinity of excellent pay, top-tier perks, and opportunities for career growth.
My personal opinion is that many of these junior devs simply aren't very good. As someone who conducts interviews at one of those aforementioned big companies, I'm consistently disappointed by how poorly most candidates perform on basic interview questions. And I don't mean the kind that test book knowledge of some obscure algorithm, I'm talking basic coding tasks.
From where I stand it's a matter of an oversupply of inexperienced, under-qualified developers that are no longer being absorbed into startups desperate for warm bodies to do rudimentary coding tasks, coupled with a strong demand for senior folks from big companies with the coffers to pay them.
The result of all this is that even if a team wants to just get things done, they’re going to be nudged in the direction of better quality simply by using our tools.
As for my team, I work in Ads. We’re a group of just over half a dozen people operating a handful of revenue-critical systems, and our code quality standards are raised accordingly. From a management perspective, it doesn’t make sense to hire a group almost entirely composed of PhDs and then have them spend their time putting out fires caused by sloppy implementstions. We put a lot of effort into getting the code right at the outset and then running it for years without need for massive intervention.
In my experience this involves a few things. First, we tolerate a fair bit of deadline slip. Google isn’t exactly gonna go broke without our newfangled product, so if we need an extra half a quarter to make it happen right, then we take it. Secondly, we write up thorough design documents before breaking ground. This means few surprises at implementation time, letting us focus on getting the code right. Finally, we spend a lot of time refactoring and cleaning things up. Systems balloon over time, and sometimes it’s more cost effective to clean house and make otherwise complex changes simple. Doubly so if subsequent changes are also made easier.
I can’t speak for the rest of the company, but I think our team’s standards are pretty high.
First off, as of 2007 AIG, Bear Stearns, and friends were in the center of a large, complex web of interlocked investments, contracts, and creditworthiness assumptions. Billions of dollars in value were declared to be "safe" and used as collateral for further leverage, effectively laundering them of their inherent riskiness. When this web collapsed, it happened all at once. Today's fintech firms run the gamut, but by and large they consist of proprietarily-managed, non-traded funds. There's none of the securitization that allowed risk to creep outward. The result is that a failure in one is less likely to trigger a failure in the entire system.
Secondly, consider whose wealth fintech is managing. If fintech were managing hundreds of billions of dollars of money belonging to people, institutions, and other banks, it'd be cause for concern. But if the marketing of funds like Betterment and Wealthfront are any indication, they're targeting individual investors. Naturally, individuals losing money is a bad thing and would depress demand and confidence for a while, but it's a far cry from the catastrophic, systemic credit crunk we experienced as a result of the crisis.
Finally, just because a system is automated doesn't mean it's going to rogue. Just because an algorithm is complicated doesn't mean it's fragile. I appreciate (and to a certain degree share) the anxiety, but I think it's misplaced in this particular case. This article seems to be to be more about hand-wringing about computers doing things than actual commentary about the structure of the financial system.
Thiel is definitely a business leader, but is he really an ideological leader? If I recall correctly he was decidedly in the minority when he came out for in support of Donald Trump.
As an engineer who's done a fair bit of volunteer recruiting work as well as conducted interviews, my experience has been that race- and gender-specific programs are used exclusively as outreach, sourcing, and mentorship tools. James claims there are "hiring practices which can effectively lower the bar for “diversity” candidates by decreasing the false negative rate," which strikes me as untrue. Regardless of how they are sourced, once candidates are in the interview pipeline their are all treated exactly as rigorously as one another.
In other words, recruiters are responsible for finding, reaching out to, and advocating for candidates. Once they source the candidate they "throw them over the fence" to the cold, hard interview process, which involves experienced interviewers and a hiring committee of senior-tenure engineers. The aim is to ensure you can trust that those who make it out how the hiring committee to be top-notch.
After years and years of working at the company I haven't heard even a whisper of complaint among anyone about the quality of people we're hiring. After working with people of all stripes I can say I haven't met a single person where I thought to myself "how did this loser get through the filter."
https://en.m.wikipedia.org/wiki/Greater_fool_theory
Forget taxi drivers telling you to invest as a mark of a bubble, questions like this are about as clear as signal as you can get.
Note a similar FUD argument can be made about Google's own advertising network: "if we unilaterally decide we don't like your ads or your websites we'll cut you off." Similarly for search results. Yet Google's implementation and guidelines are generally seen as reasonable, economically satisfactory, and not stifling innovation.
Also, what would be the point of dropping out of this coalition? The online ads industry is largely self-regulating, there's no federal regulator setting the rules. Instead coalitions like this one are formed which set guidelines and make standards. What point would it serve to pull out of a coalition and subject yourself to the control of your competitors for a one-time show of goodwill at the expense of long-term influence?
Maybe you don't trust self-regulation, and that's fine. Appropriate even, given how often it breaks down. But keep in mind the alternatives are either government regulation or no regulation. The advertising industry is presented with an existential challenge in the form of bad advertising and ad blockers. The closer you look at it, the more you realize this move is actually a pretty good one, all things considered.
Or they could disable Chrome ad blocking and install their ad blocker of choice.
If I'm reading this correctly then no portion of the user population is hurt by this. Power with religious objections to advertising are free to continue using them. Typical users who don't care don't have to deal with awful and broken stuff. People who feel charitable enough to pay for advertising get to do so.
But doesn't it hurt the advertisers? That's not a given either. This article makes it sound like all non-Google advertisers will be shut out. But that's clearly not true: plenty of non-Google advertisers are represented in the decision making process, to the point where one can be convinced that a variety of views were considered.
Ad blockers are a response to the absolutely worst of ads, to the detriment of better-behaved networks like Google, Facebook, and friends. While I agree it's a little creepy that an advertising company shoulda put out an ad blocker, Google is in a unique place to tackle the problem of poor advertising by filtering truly bad experiences, and doing so hurts no one except truly abusive networks.
> Google is very very large and very (for a web tech company) old. It has a lot of internal technology that's not available elsewhere and it's built to make it easy to build extremely large systems.
Please don't read this and get the impression that we have a lot of legacy code that just sits around. Our systems have a tendency to turn over very quickly, to the point where we joke that all infrastructure systems are either "beta" or "deprecated."
> Thanks for your email. I'm very interested indeed. I have nothing against an interview. However, there is one condition: I have to be interviewed by the person I will be working for. By my future direct manager.
This kinda misses the point. I can't speak for any companies besides Google, and this is all my personal sense and not the company line, but anyway: speaking with a hiring manager who wants you is actually less useful than speaking to a disinterested stranger. Hiring at Google is done by committee and actually regards feedback from a hiring manager with some suspicion. Here's why:
Google allows for a lot of mobility. Internal transfers are common, projects are scaling up all the time, sometimes new engineers don't gel with their teams and want out, and we strongly prefer to keep people within the company when projects scale down. Given this, hiring an employee solely on the basis of an enthusiastic manager's word is a recipe for lowering the overall level of engineering. Even if Yegor had the strong support of a manager who wanted him, he'd still have to go through the same raft of interviews and be judged by the same hiring committee.
Alright, fine, I hear you say, but if a manager likes you, surely that's still a positive signal? Well, in the best case scenario, sure: you're talented, the manager is wise enough to spot a good engineer when they see one, and they express their assessment honestly. But the best case scenario involves the manager acting as though they were a disinterested outside, so why not get the opinion of an actual disinterested outsider? However, what if the manager is short-staffed and just needs whatever help he can get to meet their goals? What if the endorsement is made on some biased basis, such as going to the same school or assessment of talent in an area unrelated to engineering?
For all their warts, whiteboard-based interviews are the state of the art in assessing the capabilities of a large number of candidates within reasonable time and cost. They're not foolproof, and smaller companies can afford to (and should) use more bespoke methods. However, at the scale of Google and friends, they're unfortunately the best thing available. But I won't lecture hacker news on scale. We all know expectations have to be adjusted as systems grow.
First off, there is no such thing as a library swap at Google. Our codebase is quite large. Like shockingly overwhelmingly large. Executing a change like this is almost certainly not a case of "swapping out one configuration line for another." It requires writing new code, testing it appropriately, updating any integration tests, updating documentation, etc. But the real fun starts when you're done coding...
There's the issue of frontend and backend. Serving Brotli-compressed data is great, but what if you're app doesn't support it? If you're lucky, this will be handled by the underlying network layer but then you have to deal with...
Rollout. I don't know how many servers are dedicated to app updates, but I imagine it's a lot. I also imagine they're distributed geographically, across regions and probably even continents. Getting all those servers to support new features is a delicate, time consuming process where any misstep will result in users noticing. It's not coding, but that's why it's called "software engineering" and not "coding engineering." But then once you're servers are all up and running you have to deal with...
Versioning. Updating backend servers is bad enough, but at least you control them. What about that zoo of Android versions out in the wild? How do you ensure they all support this changes? Short answer: you don't. You design a strategy that will allow the rollout to happen gradually over a period of time, and closely monitor it to make sure nothing unintended is happening.
Then how do you turn down the old feature? When do you turn it down? You need to build and properly use instrumentation to determine the safest time to kill off the old feature. Or you could never kill it and commit to paying the cost in perpetuity. That's a design decision, and not a trivial one.
But, odds are you're not the only feature being rolled out. You have to anticipate/deal with potential interactions with other features, rollbacks of other people's work, etc.
I could go on, but I think I've already demonstrated why this is by no means a trivial accomplishment, even for a full time engineer. Add to this the fact that every intern has to race against the clock to get ramped up on their project, making something of this complexity and with this large an impact happen deserves applause.
I should add, I'm speaking as myself here and not representing Google in any way.
The naive and/or cynical answer is because the organization demands conformity: wouldn't want to hire a fresh thinker to derail our institutional gravy train! Let's burn them out by making them jump through an arbitrary and tedious series of hoops so they come out the other end too limp and tired to overthrow us! This interpretation is nonsense.
The informed answer is that this stage is an additional filtering process. Being a leader in a large organization requires politicking: coalition building, patience, tact, etc. Not every junior hire will develop these skills. Organizations that endow too much power in someone lacking such skills will inevitably suffer from unnecessary conflicts and (often) fruitless instability.
This post seems like the author is listing his accomplishments while stunned that they alone don't qualify him for tenure. However, I would wager anything that his potential to accomplish these sorts of things was obvious to the department from day one. If so, it likely influenced their decision to hire him in the first place. His achievement of this potential yielded little new information. Meanwhile, his ostentatious conflicts and overly vocal style likely did.
My personal assessment is he's clearly a brilliant and hard-working faculty member, but the rock-the-boat actions he boasts and the very fact that he wrote this post suggests that he lacks the soft touch of a leader. Tenure doesn't just mean being un-fireable, it means helping shape your institution, and a brilliant leader without a steady hand is more trouble than he's worth.