Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The rise of never-ending job interviews

bbc.com

Post reply on HN
Print view View original

501–510 of 1001 posts

Re: The rise of never-ending job interviews

#501

Post by tinco »

neilv wrote: post #323
silisili wrote: post #119

My one and only Google interview went this way years ago. Each round they'd send me more books to study, which frankly I couldn't be bothered to read given the circumstances. My experience ended when an interviewer in round 3 or 4 asked me an obviously scripted question. I answered sarcastically, he got peeved, and I never heard from them again. I'm not claiming I'm Google caliber, whatever that means. Obviously I'm…

> the entire question was: What's not in a Linux inode? Were they considering you as an experienced developer of a Unix/Posix filesystem, who would almost certainly know what an inode is? Or were they considering you as someone who had been using a Unix so long and extensively that you had a chance of once having had to configure an older filesystem for huge numbers of inodes. Or a chance that, for some rare reason,…

I once cost my employer a bunch of valuable data due to a bug in my code that the second I discovered the data was gone I knew why it was gone because I understand inodes and their relationship to filenames.

That's to say it's information that is useful to have in your head if you're an SRE, just part of understanding Linux fundamentals.

That's not to say it was a good question. Despite my encounter with that bug in my code I still wouldn't have answered the question correctly. Filenames point to inodes, inodes point to data. The word filename might not even pop into my brain when thinking of inodes in isolation.

Also it doesn't show the full picture, I'm not at all sure I have what it takes to be an SRE let alone one at Google, that I sort of know what an inode is says nothing about if I can properly use that information to make architectural decisions.

Re: The rise of never-ending job interviews

#502

Post by merlincorey »

kamaal wrote: post #353
yobbo wrote: post #338

Earlier quoted context omitted.

It is disrespectful, but it is a proxy test for how many hours you have spent reading and writing code in that language.

A while back Indian companies were notoriously famous for giving questions from Let us C, from Yashwant Kanitkar . The questions go like, What is the output of the expression below? int i = 10; ****++&&*+p; Followed by a myriad of options. Including things like Syntax error . Not sure how this measures language proficiency.

> What is the output of the expression below?

> int i = 10;

> **++&&*+p;

> Followed by a myriad of options. Including things like Syntax error.

I consider myself fluent in C and to a lesser extent C++ -- that's a Syntax Error in C, at least.

This isn't a particularly difficult one to spot, but I can understand how it would be if you weren't very familiar the language.

Re: The rise of never-ending job interviews

#503

Post by TGImemegen »

ladberg wrote: post #226
silisili wrote: post #119

My one and only Google interview went this way years ago. Each round they'd send me more books to study, which frankly I couldn't be bothered to read given the circumstances. My experience ended when an interviewer in round 3 or 4 asked me an obviously scripted question. I answered sarcastically, he got peeved, and I never heard from them again. I'm not claiming I'm Google caliber, whatever that means. Obviously I'm…

I had a similarly bad Google experience that I've talked about before[0] but will copy here: I was asked to do a task that eventually boiled down to a topological sort, and I thought the question consisted of recognizing that the answer was a topological sort and moving on because it was over the phone. However, that was not the case. The interviewer wanted me to code it all out over Google Docs, but I didn't remembe…

Googler here. At some stage of the interview process, we have to check whether you're able to code, there's no way around it if you're applying for a coding position. So yes, we'll have you code the solution to a problem. Of course in the real world we'd use a library or look up the algorithm on stack overflow like everyone else. Good for you if you came up with a workable algorithm for the problem quickly. But that's not the only point of the interview. An important goal there is to check if you can really code. We don't usually care if you don't know find the perfect algorithm (unless it's for a senior position), and in fact it's a desirable property if you don't, because that allows us to see your thinking process. Some of the best interviewees I've had, they didn't have the right solution, but impressed me with how they thought about the problem and dealt with the situation of having a problem in front of them that they didn't know how to solve. How they considered possible boundary conditions and restrictions and extensions. Someone saying "yeah, this is just depth-first-search" and then spits up a memorized solution gives me zero insights on whether the candidate is good (and will likely not allow me to write great feedback on the candidate, unless they're able to sell me that they understand what they are doing and why and how). It's usually expected that most of the interview will be taken up by you implementing some algorithm, and it's expected that you won't get every detail right.

We do NOT require you to produce token-by-token perfect code, and nowhere in the process will I ever have to give feedback on whether the code produced was actually valid. So maybe you misunderstood your interviewer's intention, or something else went wrong, or maybe they were just joking. But it's not the interviewers task to copy code into GCC and try it out, that'd be a huge waste of time. So let me be very clear and explicit: no-one gets classified as "no hire" because they've forgotten a semicolon somewhere. You messed up somewhere else.

With that said, if a candidate says they can write in a language, we expect them to know the language, its idioms and at least parts of the standard library. Not every nook and cranny (e.g. I'd often instruct candidates "just pretend you have some library that implements a heap, and invent an API for it, I don't care about that part"), but if you call "strlen" in the termination-condition of your for-loop instead of before, or do other stuff that shows you don't know the language well, that's a red flag. After all, we expect you to be able to write production-level code that servers billions of users.

Re: The rise of never-ending job interviews

#504

Post by powerapple »

janoc wrote: post #417
powerapple wrote: post #350

Earlier quoted context omitted.

it is not optimal, but there is no alternative. The interviews should show 1) you want the job, i.e. you put some effort; 2) you can learn, i.e. those ridiculous questions; 3) team fit, i.e. you like them, and they like you. Programmer interviews are the only thing people can do in a reasonable timeframe. As programmers we always learn, we learn what we need to learn to do the job, there is no reason to reject someon…

Sorry that's utter BS. I have just passed an interview for my new job and it was none of the above. Yet very technical, still very involved - but with competent people on the other side that were showing they are as interested in getting someone hired as I was in getting the job. There were 2 interview calls in all (normally the second one would have been on-site but Covid ...). No need for BS scripted questions, no…

Software engineers can learn everything and can take on whatever tasks. Small teams may look for specific skillsets they need, big companies can afford to hire people then find something they can work on later. Also, they are more candidates so they are basically doing a filtering rather than looking for the right candidates.

Yes, there are 3 months trial period, but Google will have thousands of candidates every week, they need to quickly filter them rather than evaluating them equally. Many people interviewing don't even know the job they are interviewing for, that's the problem of big organization.

Re: The rise of never-ending job interviews

#505

Post by varjag »

eecc wrote: post #214
achow wrote: post #207

Earlier quoted context omitted.

Most probably, because manhole covers were/are made using cast iron, which were sand casted. Mold for sand casting is easily done in lathe (turning a wood on lathe for precise shape is faster and more accurate than sawing). So as one of the parent comment mentions - it is round because of production reasons.

My guess is it’s also a matter of practical usage: they’re made of heavy iron and a round one will fall in place whatever orientation it’s thrown over the cover, while a different shape needs to be carefully oriented. I suspect this also means less broken fingers.

Isn't as easy to shatter in handling too, lacking stress concentrators.

Re: The rise of never-ending job interviews

#506

Post by bborud »

ladberg wrote: post #226
silisili wrote: post #119

My one and only Google interview went this way years ago. Each round they'd send me more books to study, which frankly I couldn't be bothered to read given the circumstances. My experience ended when an interviewer in round 3 or 4 asked me an obviously scripted question. I answered sarcastically, he got peeved, and I never heard from them again. I'm not claiming I'm Google caliber, whatever that means. Obviously I'm…

I had a similarly bad Google experience that I've talked about before[0] but will copy here: I was asked to do a task that eventually boiled down to a topological sort, and I thought the question consisted of recognizing that the answer was a topological sort and moving on because it was over the phone. However, that was not the case. The interviewer wanted me to code it all out over Google Docs, but I didn't remembe…

I worked at Google and did a fair share of interviews. Two observations:

When you have 3 interviews per week for a prolonged period, you, as an interviewer, are not going to do a stellar job every time. What's worse: you will develop a routine and it becomes very easy to give candidates that do not fit your routine a lower grade. It takes effort on the interviewers part to recognize talent that perhaps doesn't fit your routine or your expectations. If you are not going to end up being a bad interviewer you also have to try to relate what you see in interviews to what you know about work.

For instance I _never_ asked people to code live (mostly on whiteboards back then) because it just isn't a relevant exercise. And I was kind of horrified at experienced interviewers who asked people to code and then got obsessive about small details that the tooling would have taken care of. Absolutely pointless.

The only piece of advice I found useful from the interview training was this: this is the candidate's big day. For you it is a chore, for them it is their big chance. Keep that in mind and respect it. I kept telling myself this for every interview - and some days I felt really terrible because I wasn't properly prepared.

The other thing that horrified me was when we let inexperienced people who had been out of school for less than a year interview people. These interviewers barely knew how to write software themselves, and they'd get even more hung up on irrelevant stuff because they simply had no idea how to be software engineers.

I doubt that I would have done very well in those kinds of interviews because this isn't how I work and it certainly isn't how I teach people to do problem solving. Problem solving requires more time because any even mildly tricky problem worth solving tends to have a lot of facets far beyond picking an algorithm or knowing how to code it up. That's the easy part because for that part, you have books, papers, tools and other people to seek advice from.

Junior programmers right out of school with no engineering experience have no business interviewing developers. They make poor and overly judgemental interviewers and only rarely are able to spot talent if it doesn't fit their template. They also aren't going to fight for candidates that may not fit the imaginary template, but have some special gift because they are junior programmers. It takes a certain amount of balls to say "I know you think this candidate is rubbish, but I see something here and I don't care what you say, I am going to insist".

(btw, statistically, this used to be a good predictor for later success: candidates that were somehow "controversial" in that they didn't make the grade with some interviewers, but displayed something that made other interviewers fight for them)

Re: The rise of never-ending job interviews

#508

Post by robinson-wall »

trinovantes wrote: post #301
ladberg wrote: post #226

Earlier quoted context omitted.

I had a similarly bad Google experience that I've talked about before[0] but will copy here: I was asked to do a task that eventually boiled down to a topological sort, and I thought the question consisted of recognizing that the answer was a topological sort and moving on because it was over the phone. However, that was not the case. The interviewer wanted me to code it all out over Google Docs, but I didn't remembe…

I once had an in-person interview where they gave me a sheet of printed code and asked me to point out the syntax errors. Some interviewers are absolutely insane.

More than a decade ago I had an amazon interviewer write some perl on a whiteboard, and ask me to find the error.

There were two - I pointed out both and they didn't seem super happy about it. To this day I'm still not sure if one of them was an unintentional error.

Re: The rise of never-ending job interviews

#509

Post by planet-and-halo »

phendrenad2 wrote: post #220

Meanwhile you can go down the street and make 70% as much money with less hassle. Companies with grueling interview processes are inadvertently weeding out people who value their time, which seems like a good kind of employee to have.

Yep. This interview process is pretty much why I'm out of the market. Could I increase my comp? Probably. But the hours of my life are slipping by, and those never come back. I used to enjoy the hours I spent learning to code. Absolutely loved it. Doing this Leetcode crap just to jump through hoops is a miserable waste of life, though.

Re: The rise of never-ending job interviews

#510

Post by hownottowrite »

TGImemegen wrote: post #503
ladberg wrote: post #226

Earlier quoted context omitted.

I had a similarly bad Google experience that I've talked about before[0] but will copy here: I was asked to do a task that eventually boiled down to a topological sort, and I thought the question consisted of recognizing that the answer was a topological sort and moving on because it was over the phone. However, that was not the case. The interviewer wanted me to code it all out over Google Docs, but I didn't remembe…

Googler here. At some stage of the interview process, we have to check whether you're able to code, there's no way around it if you're applying for a coding position. So yes, we'll have you code the solution to a problem. Of course in the real world we'd use a library or look up the algorithm on stack overflow like everyone else. Good for you if you came up with a workable algorithm for the problem quickly. But that'…

“servers billions of users”

And therein lies the problem.

Post reply on HN