I recently had an interview at a taxi firm that followed this format.
One two three pre-interviews followed by a day of 5 grueling 1 hour interviews.
I didn't get the role. Apparently the frontend guy I had the first interview of the days five was concerned about my technical skills.
I mean, I find it insulting, having worked for the last 12+ years as a developer to be told that there were "concerns about your technical competency"
I hate interviews. I hate take home coding tests and have failed every single one I've had. Apparently this is a sign that I don't do well under pressure.
I've been building working software for years, and the main problem I have is convincing people that I can actually do the job. I don't have a degree, and I don't have prestigious companies on my CV, and I don't have the time or energy to chase around roles like this, so I have to settle for unfulfilling and underpaid roles
> having worked for the last 12+ years as a developer
I've done plenty of interviews, and the amount of years someone worked does not mean they are technically capable.
By chance, last week I interviewed a frontend JavaScript expert: couldn't explain 'scope', couldn't explain 'function context', didn't know what happens when setTimeout() is followed by an infinite loop ("After 10 seconds or so the browser will probably timeout the loop"). A junior cannot know everything, a senior should be able to pull a project and team.
Personal advice to you: if you are really good but cannot show it in an interview, try to land a job at companies with ex-colleagues, where they are able to vouch for your technical skills.
If a colleague that I respect vouches for someone (s)he worked with, (s)he is practically already hired.
> didn't know what happens when setTimeout() is followed by an infinite loop
I'm not some JS guru but I've done a few and I'm wondering why would I need to know this? To me this looks like the type of question that is there specifically because people answer it wrong, they know they answer it wrong and you know they know they answer it wrong so it makes them lower their demands in terms of pay rate.
I guess it's an important question because it is about the event loop.
Lots of weird things (bugs) can happen when you don't understand how the event loop work. I would definitely pass a "senior" javascript dev that don't know/understand the concept.
A senior should know that JavaScript runs single threaded with an event loop, and therefore doing heavy calculations will block your user interactions.
If you don't know this, you also won't know when to use WebWorkers etc.
Juniors can learn, seniors should be the ones teaching them. Seniors should define the architecture of your solution, and solve weird problems. You cannot do this without proper in-depth knowledge.
Yeah but here's the thing: I do understand the event loop, I understand the sync/async models in JS but I have very little knowledge of how setTimeout works in this context. That's because I've never used it, and I've never used it because the book that I read 15 years ago about JS said something like this: "Here's a function that allows you to run some code after some time. If you feel the need to ever use it, it means you're doing something wrong, therefore please never use it". This very vague explanation combined the lack of usage of it makes it pretty hard for a candidate like me to realize that you are actually asking a question about event loops. So my question is, if you want to see my knowledge about those things, why not ask some direct questions about it?
I'm the kind of interviewer that would keep asking until you do know. I would actually start with asking about the event loop. Don't know that, no problem, what happens with setTimeout()? Don't know that, no problem, how does async, await work? Don't know that, why do we need WebWorkers? What happens with an infinite loop? How do events work? etc.
There are plenty of ways to see how this person came into contact with the event loop concept, whether in theory or in practice.
Meh, I'm with previous commenter. I know what the event loop means, that JS is single threaded, and what setTimeout is supposed to do under normal circumstances. I consider the question stupid, moreover your answer to it is likely incorrect, because it depends on the implementation. I bet Node.js never interrupts the loop for example (and I never even done Node.js, it would just be a sane thing to do).
And yeah, you might agree on Node behaving differently, but that just proves the question is very bad. Even with "in browser" clause the answer can change tomorrow for all we know.
It is like asking about undefined C++ behavior in an intentionally very bad example.
I am not saying understanding event loop is not mandatory for senior JS devs. It is just that your question is really obscure. Why not just ask what an event loop is and what are the consequences of that execution model?
Some JavaScript developers know the theory, but not all of them. At least you should know how it practically works.
So when you ask "What is the JavaScript event loop?", most will stare at you not knowing what it is. So then I jump to the practical side. They at least should have worked with either setTimeout, async/await and/or events. So then you start asking for practical consequences of the event loop, such as what happens with an infinite loop after setTimeout or await, or during handling of an event. That is a real practical example that they should know. If you don't then you don't know neither theory nor practice.
I agree that a senior should know this, but at the same time I've never run into a problem at work that required me to start using web workers because what I was doing was so CPU intensive. Most professional Javascript development is pretty run of the mill.
> I agree that a senior should know this, but at the same time I've never run into a problem at work that required me to start using web workers because what I was doing was so CPU intensive.
A few weeks ago I interviewed a front-end developer who said that in his current job he rolled into production some code that blocked the UI for nearly 1 minute, and that problem was only noticed in production because during testing they didn't used realistic data.
He then said that his approach to solve the problem was to rewrite everything from scratch using a faster framework.
Unloading the blocking tasks to web workers wasn't even in his universe of potential alternatives.
Suffice to say, he was not hired.
If you're applying for a front-end position and are oblivious to basic GUI principles, such as how not to block the UI, then you might not be lucky.
These are examples of indicators that, taken together, helps determine how in-depth your knowledge is. I imagine that if you work with JS on a more than surface level, you'd eventually be curious about or be forced to understand how things actually work to be able to precisely control your program outcomes.
It could be very important. Like the difference between something running at the right time or not.
There's a video of a talk I gave floating around the internet somewhere a year or two after Node.js came out where I talk about Node, the Event Loop, and how much I liked JS. Perhaps they saw it and were like "ew!"
I've never failed a take-home test (out of 7) and I do it by doing things no reasonable person would do for production code.
I will write a comment for every line (within reason). I will write an entire page of documentation for a one hour project. I will write a test to check for the presence of a title in the rendered page. I will make sure to host it on AWS or Azure and give them instructions on how to upload it themselves (even if any dev should know how to throw a git repo onto the cloud).
They seem to just be looking that you can do things to a certain level of excellence (even if practically unreasonable).
The most recent take-home test was one hour of code and two hours of window dressing. Totally absurd, but I keep doing fine on that step.
EDIT: If you are talking about the Hackerranks, those are frustrating simply because you can't clarify requirements. I remember back in university that we gathered in groups to do them to just cover as many test cases as a team as possible.
Reminds me of a recent take home test for a SRE role I completed recently.
Normally when it comes to take-home tests I set a hard limit on actual working time to 3hrs. This doesn't include any research or reading I will do ahead of time.
The test itself was:
> We have 3 services that we want to have running in a kubernetes cluster.
> The first service is a software application called JIRA which will be used internally for the company, so we only want to be accessed by specific IP’s.
> The service needs to be highly available, have failover tolerance and able to restore from backup.
> The other services are a golang application and a python application which we provide the code.
> Inside the go-service folder we will find the golang application which exposes 2 HTTP endpoints, one of those endpoints, talks to the python microservice through GRPC protocol.
> It has 4 environment variables:
> - PORT (the port on which the http server will run)
> - SERVICE_ENDPOINT (endpoint to the python service)
> - REQUEST_TIMEOUT (request timeout in seconds)
> - IDLE_TIMEOUT (idle timeout for requests in seconds)
>
> Inside the python-service folder there is a python microservice, which only supports GRPC Protocol. This service does not have to be exposed to the outside world, and it can only be contacted by the go lang service.
> The python microservice supports a single environment variable:
> - PORT (the port on where is going to be running)
>
> These services also require high availability, failover tolerance, and also they need to scale according to the load they receive, as our external clients consume them.
> Deliverables:
> - Dockerfiles for the 3 services
> - Full yaml configuration for the services to be deployed in a k8s, taking into
consideration the remarks above.
> - A diagram explaining the whole infrastructure and how it is connected with each other.
> - Paper with ideas on:
> - Monitoring
> - Instrumentation
> - Security
Now, to be perfectly fair, I knew much more about how kubernetes works than how to deploy services on it, so it might have taken me a little longer to create the deployments. However, there's no way that I can make that all work in 3 hours. Not to mention that the backend code I was given wouldn't compile so I had to fix bugs.
Additionally; if I spend more than 3hours on a test, I might as well spend 6 hours, or 12 hours, or a week... At some point it becomes impossible for you to interview at multiple places. The idea of spending 9hrs of my day at work, then coming home and spending another 3hrs+ every night because I want the opportunity to keep spending 9hrs at work is insane, I'm physically unable to do that. When I get home I'm usually burned out, so these kinds of tests are done on the weekend.
Anyway. Where I work, we also give a take home test, and I apply the same principles:
If one of our team can't do it inside of an hour, we don't send it. We expect a candidate to be able to do it within 3hrs. The point of the take home test is that it's something we can discuss later, too. It's really obvious if someone struggles hard or finds it too easy.
> Did they not like that it wasn't wholly your project?
No idea - the feedback in full was 'we're not sure you have enough practical experience programming - maybe try working on an open source project'. Then they literally showed me the door at that point lol.
It's an interview, so a more accurate piece of feedback would have been "you couldn't convince us you have practical experience programming."
So maybe they had a question like, how would you solve those problem, and you said, here's the solution, but they really wanted you to say, there are three potential approaches that i would use, these are the things i evaluate to decide which approach is likely best, these are the war stories that I've had that led me to refine my thinking to this point.
Yeah I guess but how much open source do they want? If you've already got a hundred thousand lines and it isn't fixing what they're after then suggesting something else would be more helpful. But I guess their interview method works for them.
They're not looking for open source per se, they're looking for you to demonstrate range/depth of experience. If you haven't been able to pick it up from your job, because they're too limited in the types of projects and assignments you can work on, then they're hoping that you can get it yourself from open source.
Now, you may already have the abilities that they want you to have, then what you lack is the ability to show so in the interview.
edit: Just to clarify, in technical interviews, they often don't even look at your resume, they just ask you the questions and judge you on how you answer them. Stating your years of experience or lines of code written have no bearing.
I don't know if we're talking past each other, but if you've already done tons of open source, and it hasn't gotten you the skills they want, then is just repeating 'do yet more open source' useful advice? That's what I mean. If someone had done tons of open source and it wasn't coming through in terms of skills I'd give them advice like 'get a friend to help you practice interviewing'.
Ok gotcha. I think you're asking a bit too much from them to give you personally tailored advice. Your interviewers most likely didn't even read your resume. Most companies will just send you pre-formatted email "sorry you weren't a fit".
If you're trying to parse their message "we're not sure you have enough practical experience programming - maybe try working on an open source project" then I would interpret it as I stated above - they didn't think you demonstrated the depth of experience that they were looking for, and were hoping that working on more types of projects, which you might not get at your job, but you might get by working on a whole bunch of different open source projects, might get you.
I find that the interviewing style of a company is often very telling of its' general work culture. You've missed our on opportunities and had to settle in less prestigious jobs, but are you sure they would've fulfilled you any better.
IMO the take-home tests close to the job's technical requirements and followed by 1-2 technical interviews to discuss its details and potential improvements is probably the best interview method. It gives a chance to both parties to get to know their potential future colleagues and see their technical background, skills and effort on solving an actual problem that could be part of their daily tasks.
And it gives you the right, if you feel 100% ok with what you delivered and you hear an excuse of lack of technical skills to skip the job and look for something else. Whereas having to pass 6 interviews with random CS and DS questions and problems where you have to memorise algorithms which you will never use in your daily work and then finally be rejected because you forgot one of them is way worse and has probably deteriorated the software engineering industry as a whole.
In the last few years, I've sat on both sides of the interview table several times. Recruitment in software engineering is a disaster from start to finish for all involved. As salaries have risen, it's only gotten worse.
On one side, there is a depressing number of people out there applying for programming jobs who effectively can't code. Their "skills" range from mindlessly repeating previous patterns they were told to use elsewhere without considering their applicability to the current context, all the way down to literally copy/pasting code chunks till the program appears to be working. Many of this group either don't care, or are blissfully unaware of what they don't know, or how little they know about subjects they believe themselves to be experts in.
This group is the majority of applicants. This is where the take home coding tests come from (which frankly, I also loathe).
On the other side, interviews are usually conducted by who-ever has been at an organisation the longest, and/or is most willing to put up with the shenanigans of interviewing the group mentioned above. This often means they're the ones most likely to enjoy catching people out, or who have some particular thing they like to grill people on. This is where you get the twenty-questions bingo style interviewing. Your recent interview sounds like one of these.
To add to this, there's a variety of situations where the applicant _should_ get the job, but they don't for reasons outside of the interview room. A manager wants to hire someone they know. Due to reshuffling, the job requirements have changed between publishing the job ad and interviewing. The budget was curtailed after the interview. Chances are, you'll never know the true story.
In addition, a large portion of developers don't ever go through the normal recruitment process. They'll do interviews, but they're recommended by colleagues, members of their meetup, friends of the above, or their IRC / Slack / Discord / etc group, and their interview process will reflect that. This is currently the best way to get a job. Often these groups are invite-only, and effectively invisiable.
In the middle of this maelstrom, are the few reasonably competent applicants applying for a job that is right for them, with a reasonable and fair interviewer.
--
Based on all the above, without knowing a thing about you, I'd be forced to conclude one of three options:
a) You've just been really unlucky. I've been there, it sucks.
b) You're not actually as good as you think you are. Usually this is when a programmer hits a certain level of expertise and stops learning anything new for some reason. Sometimes this is down to ego, sometimes it's because they've become the biggest fish in a small pond. The symptom seems to be a lack of curiosity, if not hostility, about novel or unexplored concepts.
c) The above observations are based on my incredibly biased view of my corner of the world, and don't match your reality at all.
I understand your frustration, but it seems clear to me that there is difference in what you consider high level technical skills, and what others might perceive as such.
In a highly paid position, both selling yourself and your ideas, and smoothing out differences such as this one, are expected from the employee.
While I believe that with your experience, you have accomplished a high degree of strong delivery... You still need to be able to manage this whole dealing with people thing. Because that’s why you get paid a high salary, to get any issues out of the way in a skilled manner.
It's pretty indisputable that the industry has a penchant for interviewing problems/techniques that are deliberately unrealistic.
Whiteboarding interviews aren't about a lack of time in interviews, for instance, theyre an homage to the academic background of many of the initial internet trailblazers (google, et al).
> I understand your frustration, but it seems clear to me that there is difference in what you consider high level technical skills, and what others might perceive as such.
Or the person who did the interview is an asshole. It's pretty hard to say which one it is. Smoothing out differences such as this one is expected not only from the employee, but also from the interviewer.
I work at Google as an SRE, joined a few years ago. I am approaching 40, worked in a bunch of other companies before. My degree is is in the humanities, from a third world university you never heard of. I don't have any open source contributions. I speak lousy accented English (but I am a man and "white" if we are counting privileges.)
I got contacted by a recruiter. I had a couple of phone interviews which felt like sanity checking that I knew what I claimed to know. I was asked to grade myself in a bunch of areas. I chose makes around 5-6 for the stuff I think I know well, and zero or one for the rest. I was given some recommended reading list that I ignored. I did browse Skiena's book on algorithms to get in the zone. I didn't study it or implement anything. I am very stressed during interviews and would forget anything that isn't in long-term memory already so there was no point. (know yourself...)
I went to the onsite interview. Year, it's ~5 hours of being interviewed by people who have done dozens of interviews before. Everybody was unfailingly nice. I was panicing, not because "omg Google" but "omg humans I don't know for years already". Some algorithms, some Python, more troubleshooting and Unix. I had to estimate some numbers, so I announced I would use my cell phone calculator to not get anything wrong. I multiplied even low numbers by two on the calculator. Most interviewers are poker-faced about whether they liked the interview or not (now that I am an interviewer I understand - they probably try to put some distance between the interview and their rating, as they should). I could see that one was happy. I could see that one was not.
I was hired. Large team, three sites. I did a reasonable amount of C++ (not a language I ever claimed to know) fixing bugs and performance issues. Most of my work has to do with low-level synchronization in x86 - I picked a small "specialty" first and applied it to a number of problems. I like it. I feel that I actually write more code than my peers in the product teams, as they do too much design-docing, design-reviewing, meeting, etc. (they are SWEs, I am a SE). The design doc culture at Google is excessive and silly. I am exposed to that too.
I earn slightly more than my similarly-leveled peers on the SWE side /before/ accounting for oncall. Oncall rarely pages on weekends. I feel very able to fix any problem while oncall, or to escalate if not in my area. It doesn't stress me. I mostly consider it free money.
My peer SREs actually know far more about all the nice Google architectural stuff than our peers in SWE-land, who are mostly implementing features on top of huge abstraction layers and typically are only exposed to one particular facet of the infrastructure. Google's infrastructure is impressive and something of a marvel. It doesn't mean it's perfect. SRE is the better point of view to observe it.
Google employees are better than in any other large company (a few boutique shops are better on average, of course, at a smaller scale). Some of them like to pretend that they are better than they are to the outside world. Internally, nobody goes far being arrogant, and showing vulnerability or gaps in knowledge is not a problem. There is also someone smarter and nicer than you anyway.
I interview people. The immense majority of people I interview are really good. It's not possible to get to the point of onsite interviews unless you are good, you just know the person you are talking to is a potential peer. Interviewers are happy when their candidates do well. The committee ends up rejecting most, though, out of hyper-conservatism. I have no idea how I was hired. I suspect there is a large amount of randomness between "invited for an onsite" and "hired".
> The design doc culture at Google is excessive and silly
I have a friend who started there last year and said the same thing.
> My peer SREs actually know far more about all the nice Google architectural stuff than our peers in SWE-land, who are mostly implementing features on top of huge abstraction layers and typically are only exposed to one particular facet of the infrastructure. Google's infrastructure is impressive and something of a marvel. It doesn't mean it's perfect. SRE is the better point of view to observe it.
Reading that stuff always makes me feel incredibly stupid (or rather clueless). I wouldn't be able to answer most of those questions off the top of my head. Including this weird clock hand question (which is probably some trivial math that might or might not have been taught to me more than a decade ago and which I never ever actually applied since).
Then I probably have to remind myself that I'm (halfway successfully) running a SaaS platform with tens of thousands of users, so maybe I'm not that clueless after all.
Using google products has made me certain that being able to solve math/algorithmic problems and being able to make good software really aren't connected in most cases.
Yep! To be fair, Google software is usually technically very good (e.g. their security is second to none), but they have no product vision, and often very bad UX/DX.
Clock hand question is painfully obvious once you look at actual analog clock face.
All of the questions were easy bordering on trivial as long as your background lines up with target position. The problem is not the questions, but the culture of gotcha interviewing. Haha we got you doing off by one by offering the C option on whiteboard, haha you didnt initialize one variable on whiteboard, haha I have bad mood therefore you fail, etc.
>I recently came across your name as a _possible world class Engineer_
> Clock hand question is painfully obvious once you look at actual analog clock face.
You see, intuitively I thought this would involve some kind of radian maths (just because it's about angles and a circle) and I don't remember any of that - never had any use for it.
But yes, it is a lot more easy than that. Not sure I would have discovered the trivial approach in an interview situation when it didn't even occur to me at home on the couch.
It's established that the Google-style interview questions bear no semblance to real world performance or software engineering skills. All they test is the ability to memorize leetcode style questions and regurgitate them during interviews.
These interview are notoriously hard to pass. Less than 5% gets in. You should not feel bad about it. Being an SRE at Amazon or Google scale require that you know what is going on in every layer of the infrastructure, including data structures in code, so that you can pinpoint the exact problem in the stack. I think some of these question are overkill and have nothing to do with how good you are going to be at the job though. Writing a binary tree certainly one of those. You are not going to write one because there are tons of libraries in every language that is in production. Knowing that DNS can use TCP is much more valuable. This falls into the category of questions that you are likely to run into when debugging an issue.
If you want to get a job at Google you have be willing to be put up with these questions (both the ones make sense and the ones do not) just to show your dedication. I usually prep for such interviews roughly 3 months and I have worked as an SRE for a long time. Do not assume that we know all of these things on the top of our heads and do not feel stupid.
2. For the interviewer to feel better about already having a job at Google. I remember one guy bragging about how much he made.
It's really not to find out if you're good at something. I have been offered jobs at some of the FAANMG companies so I'm not talking out of jealousy or whatever.
One thing that struck me is that the interviewers are asking the same questions to many different candidates, so they are going to know all the slip-ups that people make.
Well, when you work at Google, at least you must have passed that kind of an interview at one point - which is something I'm fairly certain I wouldn't be able to do.
One of Google's HR groups did a test where they gave the hiring review team their own interview packets (anonymized, from when each team member originally interviewed). None of them were hired.
I can say with 100% certainty that my coworkers ask questions in interviews that they wouldn't be able to answer themselves. It's kind of ridiculous IMO and I try to call it out when I see it (in the nicest possible way of course)
The issue with impostor syndrome is that your brain is good at finding excuses such as "I was lucky", "They did not catch me", and so on.
Personally, I had a lot of fun doing my interviews and learnt a lot while preparing them. I would recommend you to try them, it's gonna be interesting, even if you don't get the job.
I have done interview training twice in my 8.5 years at Google, and both times it only made my impostor syndrome far far worse. I simply can't do interviews here, I wouldn't pass the ones I had to give.
Clearly the interviewing Googler with a 250k salary doesn't value a decent wrist watch where whole minutes and hours tick over nicely in a single movement. ;-)
> Clearly the interviewing Googler with a 250k salary doesn't value a decent wrist watch where whole minutes and hours tick over nicely in a single movement. ;-)
I've never seen a watch where the hour ticks over in a single movement. Do those exist? I imagine it'd be very confusing to see the minute hand at 59 and the hour hand still at 0100 when it's 0159.
I have a great video of my kids trying to figure out what a pay phone is back in ~2014. Not rotary, but a similar sort of "wow, I'm old" sort of experience.
Actually I (never took an algorithms class, so I would definitely have to brush up on execution of the basics there) thought this questions were not that bad, the newer reports seem much harder (or are plain exaggeration by the "leet"code community).
I'm also a bit puzzled about the trick question being mentioned at that. That's just primitibe (maybe I'm a little bit burned by that as in 5th grade or so, our teacher did a test, writing times on a sheet and making us calculate the angle between clock hands (and it was a lot of numbers on that sheet))
I was good before but i did excersize for google interview for 2-3 month.
I actually overdid the learning as i assumed that the coding questions can't be that easy.
But at the end of the day, i'm still not working for google because yes the coding questions are not that hard but you have to convince 5 different people that you are a good fit.
Suddenly you excersize for learning how to know what the interviewer wants from you.
Is that wasted time? Definitly not. Loved the more focus learning approach.
Also, i'm now 10 years working in that industry, you don't stop looking for a new job. That interviewing skill is critical.
I feel the same way, except I think the clock-hand question is quite straightforward. Except for that one, just like every other time this sort of thing is posted almost every question is either:
1. About fairly low-level details of computer networking, or
2. What would you do if your data doesn’t fit in memory?
I’ve been a successful developer for years and never had to deal with either of those problems.
It's been the same experience for me. I've been successful as a developer and yet have never encountered many of these problems that interviews in the past demanded I know.
Ultimately if I end up encountering a problem like that in my career, the honest answer is to pick up a book or begin reading through articles on solutions. Sadly that kind of answer seems to be frowned upon because it's better for you to lie about what you know than to admit you don't know the solution and figure out ways to rectify it.
Google employs the very elite of the elite. If you're working there you're probably at the very top of your field. Obviously not every can meet that standard and there's no shame in not being the absolute best.
I feel a little sorry for Google's developers. They're told they're brilliant but asked to write software to deliver adverts and track people. They could literally be curing cancer and putting people on Mars if they wanted, and yet they sit in Mountain View working out new things to do with the data about what I clicked on today. It's a huge waste of talent.
People who dedicate their lives to curing cancer and putting people on Mars are titans for making verrry verrry wee little dents in those problem areas.
Your typical software engineer slept through the minimum amount of biology coursework required of them and has no special interest in chemistry beyond maybe like, a broscience-level grasp of pharmacology related to research compounds commonly viewed as smart drugs.
If bay area futurism woo is indicative of broader trends among software engineers, this person also has a vague, half-ironic commitment either to superintelligent AI immanentizing the eschaton or brain uploading becoming a hot-swappable replacement for the mortal coil within 20 years. Or both.
A belief that Google's workforce constitutes an addressable vat of brainpower of such raw g that, were it not for the idle concerns of developing adtech, it could turn to curing cancer is a very strange belief.
I'm not sure what the intention of the OP was but I read it as those engineers could help push those efforts forward by doing what they do best -- writing software. Not all of those involved in the effort to cure cancer are studying chemicals and making drugs. There's also people who have to run some matrix calculations with MATLAB code, or who have to transcribe experiments into excel sheets. It's hard to think that if we took the pool of talent that makes the information-collecting products that Google makes, it wouldn't have any difference in the amount of progress made
I'll explain why it sounds preposterous to me, and why the idea that google could change the fate of cancer research or missions to mars if not for its profit motives is patently unrealistic to the point of being insulting to everyone involved in this counterfactual.
1. Why cancer?
Number one cause of death is heart disease. Why not that? Surely the #1 problem is good enough for people currently working on adtech if the #2 problem is.
You said curing cancer, not "applying the numerical optimization expertise of a tiny fraction of google's workforce to the occasional omics problem in collaboration with a research lab" or "headhunting the PI of a lifesci research program to build an initiative at Google" or "throwing google infra at something other than Stadia". Even something far more obvious like "applying deep learning to diagnostics / early detection / etc."
These are the things Google can actually do, and they are the things Google already does. Examples: DeepMind for breast cancer screenings, Public Datasets program support for selected research. Still no cancer cure. So if you'd said that, well, they're doing it, to whatever extent they deem worth the prestige bump.
Unless they decide to become Microsoft and buy out entire sectors of applied biotech, they're not going to radically improve their hands-on involvement in lifesci relative to what they're already doing.
More, just ballpark the numbers. Google has 100k employees — "98771" in 2018-12 as per their SERP infobox. "A lot" of those employees absolutely do not by any stretch of the imagination possess the skillsets required to assist in meaningful ways on high-end cancer research, unless that work is conducted like some kind of wartime effort and the assistance is largely of a clerical nature.
And in the event that Google employees were being unilaterally drafted into this effort as grunts, the very first thing they'd do would be to crowdsource/outsource the bulk of the menial work to cheaper labor sources beyond Google. So their main contribution would undoubtedly be in building the scaffolding required to pass the buck.
2. Why Mars?
This constitutes a complete diversion of Google's autonomous driving and robotics people to an out of the blue project that they're out of position to handle. It would merely sabotage a division where Google is a market leader for the sake of starting up an incoherent, laggard mess in an area defined by maddening bottlenecks and complexity. Google has no substantial preexisting expertise in this area, afaik.
At one point they put up 30M USD in sponsorship prize money for a lunar lander competition, but that's about all that comes to mind. It also went pretty dismally. They had to repeatedly extend the deadline. Eventually the comp ran 11 years and ended in one launch -> one crash on the lunar surface. They threw a mil at the team as a consolation prize.
That project was more of an exercise in reifying the moonshot metaphor than anything else.
One far more recent indicator of how hard it is to make strides in this area is the DARPA Launch Challenge, intended to accelerate radical improvements to launch pipelines. It just closed without a winner. One team barely made it to the launchpad then scrubbed.
In terms of both social good that Google can do with its nearest preexisting R&D and profitability, it's clear that redirection would be disastrous. Autonomous vehicles are the play for them. This has nothing to do with the adtech people either way.
All in all, the relevance of Google to either of these problem areas is about what would be expected, cet par: not a lot. Modern work with any technical bent is hyper-specialized. There's no jump from literal cancer like adtech to actual cancer.
On top of that, adtech is largely a house of cards. You can't ever assume that 'data science' coupled to business requirements and marketing is in any way rigorous or indicative of the current state of the art in independent research. A lot of this work is pure smoke and mirrors operating on greater fool theory. To specialize in that sector is to specialize in window-dressing falsity. So it's not like you'd want adtech data jockeys touching subject matter that actually matters.
They are working on things that interest them. What is wrong with that? That is also a little insulting to the researchers that are actually studying how to cure cancer.
Google has at least 50K employees, spread all over the world. I guess it is quite possible to gather and recruit 50K employees who are much better developers than most others outside but I would not (rather cannot) call each one of them elite of the elite !
Look, a great deal of valuable software has been created by Google and other FAANGs. But I reckon most of that value has actually been created by the first or the best 5000 or maybe 10K employees at most. Most of the others in Google are enjoying the fruits of their genius, and they don't really have to perform any greater miracle than moving protocol buffers around. Still, no doubt that they are highly competent software developers and passed tough interviews. Not to imply that Google interviews can even distinguish between a genuinely talented programmer from a diligently-practicing-over-a-year leetcoder.
> I guess it is quite possible to gather and recruit 50K employees who are much better developers than most others outside but I would not (rather cannot) call each one of them elite of the elite !
There are other companies besides Google. Who's to say, for starters, that any of the engineers at the members of FAAN, or Microsoft, or the unicorns, are any less elite?
> Obviously not every can meet that standard and there's no shame in not being the absolute best.
There's an interesting implication in your statement. The inherent assumption is that the metrics which Google uses to hire interviews would be the definition of the best. In other words, if you'd use Google's interview process in the whole world - the filter of that would lead you to the "best of the best" and "not so the best".
I don't know the answer to it but you may want to consider this aspect before reaching the conclusion.
No. We laugh at this stuff. All sorts of internal memes about "hiring the best engineers in the world to move protobufs around."
There are definitely personalities around the company who think of themselves this way, but certainly not the majority. I think this kind of language in fact hurts us, because it creates a pronounced impostor syndrome around us, as we all _know_ we're mere mortals.
The reality of a SWE job at any BigCorp is quite mundane, and is more politics than coding most of the time.
Honestly our interview process should be more testing people how to write and comment on design docs and fill out a performance review, because that's what they seem to want the most out of us.
EDIT: Oh, also filtering through 2 pages of new emails, mostly automated, to find the two things that are relevant to your job.
Is this still true? I know they strove for this 15 years ago, with much success. From what I've seen in the past decade, I highly doubt that this is still true. And I'm not speaking of Google's products, but other aspects like their culture, the opinions of academics, media reports, etc.
>At first I thought I would be applying for a software developer position but after we went through my skillset, the recruiter concluded that I would better fit as an SRE.
I've got to say, I've been contacted by recruiters for Google a few times, and it has always been for SRE roles. I got the distinct impression that it's less about whether my skillset fitted being an SRE, but more that they need lots of SREs and have trouble pursuading people to take that job. I'm sure some people want to be SREs, but Google seems to want Software Engineers to become SREs.
The impression I got from talking to the recruiter is that you're spending more of your time ensuring systems work as intended and managing running systems than you are building systems from scratch, and particularly you're not working on the sexy parts of systems - the bits people actually notice,bu instead are focused on making sure those sexy bits actually turn up in a timely manner. It's not a bad thing, it's just a very long way away from what I do, and what I want to do, and the fact that the Google recruiters are always pushing me that way gives me the imipression they struggle to find people for the SRE roles.
I'm speculating here, but everything I hear about google is how they _love_ people who make features. Which has been touted as the reason why a lot of projects fail to be maintained and get shuttered.
If that's the case, then it follows that SRE is less glamorous because it's "What developers do when they're tasked with operations work", and operations work is maintenance.
Not to mention operations work in of itself is unsexy to a lot of people (excluding current operations staffing because we're inextricably drawn to it).
When I first started down the path to becoming a software engineer, I never suspected that flashcards would be part of my interview prep as though it were a history course.
I'm probably not as driven as most people here. But I wouldn't want to have SEVEN technical interviews for what seems to be a relatively average opening.
Just reading this post triggered my anxiety. I don’t think I’ll ever make it though a single one of these FAANG interviews if at all I want to work for one.
My take away from this is that the bar may have been lower in 2008 when the headcount was lower than it is now despite the headcount having exploded recently.
You still get the in-depth system design questions and "tech trivia" that requires a review of the spec for whatever language/technology you interview on, but the algo questions are harder now.
Finding the unique set and implementing a binary tree would be "lay up" questions now to most prepared candidates. At the very least those caliber of questions have limited ambiguity and don't require knowledge of any tricks to get optimal solutions.
> Unfortunately, I just learned that I'm not getting hired.
Seems like a ton of effort to go through to not get hired. I'm curious as to why he wasn't hired; IMO it seems kinda strange to go through 8 interviews only to be rejected.
Google is notoriously bad with these interviews. Most famous case is the Homebrew guy. I got turned down once because I haven't had a degree in CS. They knew that in advance yet they did the whole round.
I’ve passed the exact same SRE interview, well enough to be offered follow up interviews for a higher level. I’m not saying that to boast, I’m saying this to remind people that the celebrity developers, whose blogs and tweets we share here, are just as good as you, and more importantly, you can be just as good as them.
Did anyone notices these questions aren't hard on algorithm sides(all algorithm questions in this post are common/trivial) but more about understanding Network(TCP) and Distributed System(Map-Reduce problem).
And the issue about forgoting to initalize data. Is the interview at Google really looking for that perfect solution on a whiteboard? In an interview, it's easy to forgot those thing like. I'm sure we have that moment when debug something and miss some trivial thing
Anyone has done similar SRE interview recently care to share some questions?
My interview process for SRE in Dublin in 2012 went pretty much exactly the same (procedure-wise - content was different though), and passing the on-site interview felt hard enough that I'm kinda proud of it to this day... But I also had to agree to not ever talk about the questions presented, in case I ever wanted to work for them.
Now I wonder if that provision was alreay in place when that article was written initially, and the author just doesn't and didn't care - or if it had to be installed after such articles started popping up, and Google engineers and recruiters felt like running out of questions people couldn't prepare for :)
I like how they asked a map-reduce question. If your previous experiences didn't involve working over massive datasets with distributed computing, you wouldn't have a clue. But if you did your search about your prospective position, you could find and study for the potential interview topics.
They are effectively selecting candidates who have spot-on experience for the position in hand or are willing to put the time to study for it. Is it too much to ask? Probably not for what you would be getting in the next couple of years if you were to keep it up.
I was asked that question 2 times in different companies. At the first time I apparently forgot the the Hour stick will move a little bit when the Minute stick move to 15. I guess it's a trick question when we can easily forgot that fact. My brain is train that way that when it's 3 then the Hour stick is at 3...
Wow it had not even occurred to me that anyone would not remember that the hour hand ticks forward a bit every minute. Blind spots and all that. Also just reinforces how much I dislike trivia and trick questions.
And I'd probably be surprised at just how common it is to forget that. Not that forgetting (or remembering) provides any information as to whether someone's a good SWE or not.
These sorts of interviews do not find good software developers, they simply remove a certain kind of bad (not really) software developers along with a whole host of very good software developers that don't fit a very specific mold (perhaps people who write cheery blog posts about how fun it was? ...weird). Which is fine if you're the company doing the interviewing, but completely time wasting for the interviewee. In aggregate it sounds like abuse and disrespect. It's dismissive of experience, accomplishment and aptitude in favor of training to the test.
People say that Google has changed their tune somewhat over the years, but their creed has had impact throughout the industry. It's a shame.
I'm not going to defend this style of interviewing, but I think it's useful to have tests which filter out people who cannot program at all. If you do any hiring you'll know that a surprising proportion of interviewees who make it to an on-site interview for software positions simply know nothing about the subject. When I did interviews at my start-up we'd have a Linux machine connected to a projector for interviewees to use (this is for Linux programmer and sysadmin positions), and a small but significant proportion of the candidates had no idea what to type into the terminal to list files, or what an absolutely trivial program (like loop to 10 printing numbers) did.
Sure, can't dispute what you say. There has to be some amount of "you must be this high to ride this ride" but you don't need to measure 7 times or whatever before thinking the first measure was accurate.
I've been on both sides of the interviewing tables many times and the processes that worked the best were the ones that involved telling stories to another another and seeing how the other reacted. You know, actually interviewing, humans having a conversation.
Ah screw it, I'll be the boy in "the emperor's new clothes". Google sucks! They try to put themselves on cloud9 and look at us "mortals" like we should be grateful for 8 interviews, LOL.
Age has caught up with them, they just refuse to acknowledge it. They are no longer the "hottest" company on the planet yet they keep behaving like they are.
To me personally, Google has become tne old IBM, a giant tech behemoth who cannot move normally and is riding on a single product and old glory.
I would rather work at Microsoft right now than at Google (although I am aware I don't have "qualifications" for neither"
I interviewed at Google for an SRE:Systems role around a month ago; I can share my anecdotes.
The first interview put me in contact with a recruiter who would basically be my guide throughout the process, at first he asked me some basic questions to feel out where I was weak and then told me to prepare those weaknesses for the next round.
The next round was 2 phone interviews, lasting about an hour each and over different days, one focused on my programming skills (of which, I have little because sysadmins don't typically do anything relating to data structures) and the second one was surrounding linux internals and debugging (which I was very strong on).
I spent roughly 2 working days worth of time preparing for them.
Preparing for the on-site was pleasant, I was put in touch with another google recruiter who ensured I knew where I was going and what I was doing, they told me that I'd be there the whole day and while they couldn't tell me what I would be asked/who I would meet/what to prepare; they gave me an approximation of the _kind_ of questions, very broadly.
I spent roughly 18 working days preparing in my weak areas, including leetcode/data structures and reading comp-sci papers (paxos and ilk).
On the day, I went through about 5, 1-hour long interviews that focused on various aspects of SRE (one of them being 'googliness'), some were about distributed systems (where the interviewer got hung up on the fact that I said I would use postgres instead of making my own database) and others were heavily programmer focused (linux internals was more about knowing the implementation of 'ls', scripting was all about the kinds of questions you get on leetcode).
I'm not going to lie, it was gruelling, and I'm typically pretty comfortable interviewing;
I thought I'd be fine with these interviews because I'm considered to be "shit hot" in sysadmin/writing glue by my peers, but I guess not, as I'm not a Google-SRE. :)
(sidenote: everything in TFA rings true, including the tips, google recruiters are quite transparent about your process. But they also said that the last stage is not the interview, it's roughly 5 hiring committees that are looking at your application "package" through different lenses)
They explained that; it's coded word for "culture fit", but it's used as a verb inside google (one example: "Sorry, that wasn't very googly of me").
It's the idea that you're expected to be open to feedback, empathise a lot and be always willing to go above and beyond to help someone.
I actually passed that one. So, I think it's just a jerk test. I think they asked me about if someone was stealing my credit, or the credit of others- what would I do.
It doesn’t seem unreasonable for an SRE position. Presumably the focus of the interview would be quite different if you were applying to work on, say, V8 or the Go compiler.
Companies like Google have hundreds of thousands of machines and nothing they do will ever run on just one box. I can see why they'd select for networking knowledge.
Ranging from none to "whatever you happen to know about this stuff is not enough". Quickly building mental models for unknown stuff is the top skill. I'm afraid nobody even tries to assess this in the interviews.
The irony of the clock brain teaser is that it operates on two assumptions. One being that the person asked has experience with analog clocks (which, given that it's 2020 has become less relevant) and the second being that said clock behaves according to standard specifications.
If the clock was instead a jump hour clock for example, then that tosses the trickery out of the window. Which is really what that brain teaser is about; testing that your cultural understanding of how an analog clock functions is correct.
I think getting the correct answer in code is easier than solving the "trick question" about 3:15.
If I were the interviewer here, I would make sure the candidate states their assumptions and that the code they wrote follows those assumptions. You can make the hour hand stick right at the number for the entire hour, or you can have it smoothly sweep as the minutes (or seconds) increase. I would not care and consider both to be reasonable interpretations (but I've never seen a clock that sticks at the hours; it is harder to implement in hardware).
I honestly wouldn't even ask this question because it's too simple. It's two divisions, a subtraction, and then a modulo 360. It is awkward when your interview question only takes 5 minutes and you have to awkwardly fill 55 minutes with follow up questions ("and how would you test that?").
Whenever I read about people's interview experience with Google it sure sounds more stressful than my actual day job. I understand investing the time when youre a new grad, but I have no idea how already employed people find the time to prepare for these interviews …
There are three types of developer. Those who never worked at Google, those who currently work there, and those who used to work there. The third kind are the ones to avoid if you're interviewing for your company.
One two three pre-interviews followed by a day of 5 grueling 1 hour interviews.
I didn't get the role. Apparently the frontend guy I had the first interview of the days five was concerned about my technical skills.
I mean, I find it insulting, having worked for the last 12+ years as a developer to be told that there were "concerns about your technical competency"
I hate interviews. I hate take home coding tests and have failed every single one I've had. Apparently this is a sign that I don't do well under pressure.
I've been building working software for years, and the main problem I have is convincing people that I can actually do the job. I don't have a degree, and I don't have prestigious companies on my CV, and I don't have the time or energy to chase around roles like this, so I have to settle for unfulfilling and underpaid roles