Live data from Hacker News

My Job Interview at Google (2008)

catonmat.net

121–130 of 169 posts

Re: My Job Interview at Google (2008)

#121
post #116
post #109

Earlier quoted context omitted.

> 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.

Exactly this.

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.

Re: My Job Interview at Google (2008)

#122
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.

Re: My Job Interview at Google (2008)

#123

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 techni…

> 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 probab…

Interviewed a guy who wrote a JavaScript book.

He Had no idea how to do anything other than write books.

Re: My Job Interview at Google (2008)

#124
post #20

Earlier quoted context omitted.

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.

Is this established? What I've heard is that while it bears no relation to the actual job, it does correlate with real world performance at that job. I've only heard this anecdotally, but it is their best hiring indicator which is why they persist with it, despite it being very expensive.

I think you would find a better correlation of interview-job performance if you looked at the interviewers involved in the hiring process

Re: My Job Interview at Google (2008)

#125

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 techni…

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.

Re: My Job Interview at Google (2008)

#126

Earlier quoted context omitted.

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)

Re: My Job Interview at Google (2008)

#127
post #116

Earlier quoted context omitted.

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.

Exactly this. 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-d…

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?

Re: My Job Interview at Google (2008)

#128
post #13

>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 ha…

Why do you feel like it's less glamorous/whatever to be an SRE?

Nobody got promoted for maintaining mundane shit. "delivering" Google+ on the other hand ...

Re: My Job Interview at Google (2008)

#129
post #69

Earlier quoted context omitted.

Google employs the very elite of the elite. 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. I…

A lot of cancer research is about optimizing computation, which is what a lot of Google engineers do. I didn't pick the examples flippantly.

Re: My Job Interview at Google (2008)

#130
post #69

Earlier quoted context omitted.

Google employs the very elite of the elite. 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. I…

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
Post reply on HN