According to intervieees all people applying for Google are asked this question:
You walk into a TED talk auditorium full of people. Estimate how much poo is in all of their bums collectively
Explain your reasoning
According to intervieees all people applying for Google are asked this question:
You walk into a TED talk auditorium full of people. Estimate how much poo is in all of their bums collectively
Explain your reasoning
Big tech companies are engaged in an arms race against their applicant pool. They want to ask questions that (theoretically) gauges their abilities to solve complex problems, estimate costs, extrapolate from incomplete data, or make inferences about a system, but they need it to be a question that their candidates haven’t heard before. This is tough, because people who want to work for Google are notoriously good at retaining information and being assiduous researchers, so the questions tend to evolve away from any kind of real-world application and into the absurd, e.g. “How many ping-pong balls would it take to make the Empire State building neutrally buoyant?”
This by itself wouldn’t necessarily be a problem, but big tech has another problem: they have way more applicants than they have open positions. They could just pick any qualified applicant, but there is a whole sub-industry around selecting the best candidate by using ever more elaborate and difficult tests to separate out the very best from the rest. This leads to more teaching to the test, as this book does, and intensifies the cycle of hiring candidates who are remarkably good at technical interviews, whether or not they are actually the best fit for the job they are interviewing for. It’s really hard (and time consuming) to test the efficacy of these tests, and the companies who make them have zero incentive to disprove the efficacy of their very expensive proprietary systems, and it’s often enough the case that the person who gets the job is good enough at it anyway, so the problem persists. It’s started to move down into smaller and less well-known tech companies too, and the difficulty (and arbitrariness) of software developer interviews has shot way up over the past several years. Ask me how I know 😩
I read one of the questions in the book, it was about ‘how would you escape from a blender if you were shrunk to the size of a bee. The blender starts in one minute’
It literally reads like a shit post
spoiler
The answer is that idk something about relative body sizes and power ratio, if you were shrunk to the size of a bee you could just jump out
(You’d also die if you were shrunk to that size because isn’t there that thing that our circulatory systems would fail? So it’s a pointless question in so many ways)
yep. If I may be so bold as to presume what the question writer is thinking: the question is supposed to test for how well you account for other changes in a dynamic system when one variable changes. It’s not an unreasonable thing to want to test an engineer for. Your power-to-weight ratio is dependent on your weight, so the clever engineer should be able to start with the independent variable (size) and work out the ramifications and derive a solution (better jumping ability -> just jump out). Unfortunately, the questions are so divorced from reality that they introduce a ton of other factors the author makes assumptions about and doesn’t explain, like how your muscles or circulatory system functions under this mysterious shrinking magic. Can you even breathe in this scenario? Is it “less correct” to assume this is a “Honey I Shrunk the Kids” situation and your jumping ability remains proportional to your height? Do we know whether this blender, like all blenders, has a lid? Am I strong enough in this scenario to remove the lid? etc. And the further you get from “real-world” scenarios, the more of the hypothetical world you have to explain, and most questions really underestimate how many assumptions they’re introducing. So you get these insane questions that you can only get right if you already know the answer, which is why this book exists. It’s a great system.
In my imaginary tech company my interview process asks these insane questions and only considers the candidates that push back against their absurdity.
Plz hire me bc I am seething reading this thread lol
I’ve never worked for one of the big “big tech” companies so I don’t know how deeply they’ve drunk of the kool-aid, but that attitude isn’t uncommon at smaller shops. Questioning assumptions is an important part of the engineering process after all. I have been on the other side of the interview table a few times and I like to make up my own questions, and part of the interview process is seeing how well the candidate clarifies the parameters of the question. It’s not dissimilar to GMing an RPG. You lay out an environment, the player-candidate asks questions about it, then they take a course of action and we see how it proceeds. I try to be prepared with a solid, work-related scenario because I don’t like candidates having to workshop my questions for me when they’re hunting for a job, but if they spot an inconsistency or something else I hadn’t thought of before, it’s a positive sign that they’re thinking about the problem the way I expect an engineer to think about problems.
It sounds like an absolute headache and I’m sorry you’ve had irl exposure to it. I’ll let you off the hook of answering my ‘how much poo in the TED talk auditorium’ question as a sign of my maganimousnessness
Thanks, it is lol. I am currently weighing whether to even continue with the industry or move on to something else. I’m job hunting right now and exceedingly over it. I still like the work when I can get it but the interview process has gotten significantly more insane since the last time I was actively looking for work, and it wasn’t great then.
The answer is 549 poo
That seems way too low for a TED talk audience.
Surely the blender has the lid on? Where the fuck are you jumping?
Sorry i forgot to clarify. In one minute a bee that has become human sized will put the lid on the blender and hit the on switch
🫲 welcome to the team
Hang on I know this one, I think I just need to learn to see things from the bee’s perspective and we’ll switch places. Then I blend the bee to prevent it from inflicting this cruel game on future candidates.
The problem with getting the best candidate is once you have that person they get even better offers from the other big tech companies a year or two later because you already did the hard work of selecting them from the pool.
Best is a slippery concept to describe, and I’ve never worked for big tech companies so I can’t compare really, but in my experience there are plenty of excellent developers working at tiny companies nobody’s ever heard of. Most of them are technically underpaid, and some of them do move on to larger companies, but not all of them. Working at a smaller, lower-pressure shop can have a ton of benefits beyond money. One of the big ones is office-political power: generally speaking the smaller the org chart, the more power the people at the bottom have to influence the people at the top. Generally, you have to shop around because there are plenty of software companies who want to become the next Google and have adopted the “give 110% all the time mindset” that grinds people down and prevents leaders from listening to their subordinates, because they already figured it all out from some book or, more often in my experience, their VC handlers.
I think the larger problem with retention is that work experience is highly valued, IMO overvalued (that is, it is highly valuable, but I still think it’s given too much weight) in evaluating candidates, so a junior engineer you hire with zero experience at $X salary can move and get anything from a $(1.5 * X) to $(3 * X) salary increase with the experience they got in your shop. This leads the market to believe that jr devs will inevitably churn off, and in many cases prevents smaller shops from hiring any jr devs at all. But if they do, they assume that the jr devs will leave soon, so they don’t invest in them and work them as hard as they can, which self-fulfills the “they’re going to leave as soon as they can” prophesy.
Which leads to the other big problem with assuming your talent will leave: if you think the “best” people will leave sooner, you try to aim for the least-good developer you think will still be able to do the job, which has a dramatic effect on your workforce over time: your quality slips, you miss deadlines, which leads you to tighten controls on your workers, which lowers their quality of life and encourages them to jump ship, and the ones who can do, which again lowers the quality of your remaining workforce. It’s a spiral that leads to kakistocracy, which I think is a natural result of not trusting people to do their jobs, and it leaves you with middle managers who hate and feel trapped by their jobs, which is a huge factor, maybe the biggest single factor, in hiring and retention.