The rise of never-ending job interviews • Hacker News Board

Re: The rise of never-ending job interviews

#751

Post by kragen » Mon, Aug 02, 2021, 2:16 PM UTC

smt88 wrote: post #327

hdjjhhvvhga wrote: post #305

Earlier quoted context omitted.

Actually this one might make sense, depending on the code and the position you applied for.

Your IDE can check your syntax. For people who have to switch between languages regularly, precise syntax memorization is difficult and a waste of time.

Your IDE can tell you if your syntax failed to represent any valid program. It can't tell you if your syntax represents the wrong valid program. If you can't even spot invalid syntax, you have no hope of spotting bugs, because you can't read what the code says. Which turns out, contrary to your beliefs, to be important for many purposes.

That doesn't mean you can't debug. You can step through the code step by step in the debugger, or add more and more logging around the bug, until you figure out which expression has a meaning unintended by its author. But that means that, if we're working in a language someone knows well, you're likely to spend hours debugging a problem that they can just see immediately when they're reviewing a merge request. That's an orders-of-magnitude difference in productivity when it's important for code to be correct, precisely due to what you call "precise syntax memorization".

Most of programming isn't writing code. It's reading code.

It's possible to go overboard with this. There are other skills that are more important than being able to look at some code and immediately see what it means. There are excellent programmers with severe dyslexia who will just never be able to do this. But it's foolish to think that gaining this skill is "a waste of time" for those who can.

There are languages I've used where I don't know the syntax that well. PHP, Ruby, x86 assembly, OCaml. There are languages where I know the common syntax well, but there are plenty of obscure corners of the syntax that I don't: C++, Perl, bash. But I regularly switch between C, Python, and JS, and I'm pretty confident that I know their syntax, as well as numerous other languages like Tcl, Lua, Prolog, PostScript, and arguably Scheme and Elisp, which I don't use regularly but still wouldn't have any trouble spotting syntax errors.

Re: The rise of never-ending job interviews

#752

Post by GuB-42 » Mon, Aug 02, 2021, 2:17 PM UTC

pjmlp wrote: post #438

bb88 wrote: post #282

Earlier quoted context omitted.

What's funny is that I specifically remember a conference where some library that a google employee wrote was terrible. The one google developer talking about it, disavowed any responsibility of it. Whatever metrics that google is using in their interviews have probably become worthless in the past decade as people game the system.

Just check the Android code, specially the early versions looked like "C dev (not even C++) tries to create a Java based framework". And the NDK clearly is anything but modern C or C++.

How much of the early Android code was made by Google? Android existed for two years as an independent company before Google bought it.

Re: The rise of never-ending job interviews

#753

Post by mistrial9 » Mon, Aug 02, 2021, 2:17 PM UTC

taude wrote: post #732

rubicon33 wrote: post #695

Earlier quoted context omitted.

I liken it to what lawyers go through with the bar here in CA. It's gatekeeping. Just like I don't think the CA bar should have a pass rate in the 20% range, I don't think coding interviews should ask riddles that are nearly impossible to solve on the fly unless you get lucky and memorized THAT riddle in your studying.

Is there a shortage of attorneys in California?

attorneys multiply when left to their own devices, which is often bad for society.. (since like law enforcement and middle management, LOTS of new people every year want the job for all the wrong reasons) so California Bar limits the new attorneys, which both lessens the total number of attorneys, and also advantages the incumbents.

Re: The rise of never-ending job interviews

#754

Post by noirbot » Mon, Aug 02, 2021, 2:19 PM UTC

ironman1478 wrote: post #161

kamkazemoose wrote: post #144

Earlier quoted context omitted.

Part of the problem is that Manton the interview panel do feel like they're wasting their time. It is valuable to the company but for the engineers, they want to get back to coding or whatever else they are working on. It isn't fair to the person applying because they didn't pick the people on the panel, but if the one doing the interviewing doesn't hide their feeling it's obviously not great.

That's true. I want to say that that's Google's fault right? Because not everybody is on the team you're interviewing for (I might be wrong)? At Apple you are interviewed by the team, who presumably needs another person to assist them. Also, regardless of whether or not they want to be there, it's a bad look for the company. Somebody took a day off to talk to you, it's only fair that an interviewer reciprocates

Some of the difficulty is that the team may be hiring people because they're currently under-staffed. I've been on teams before where we're 3 engineers on a team that we're trying to hire up to 6 people. It's really hard to both try to keep up the work of 2 people, even in maintenance, and spend hours every week on trying to hire the replacements. Even if the company is good about reducing demands for new work after a departure, it's generally true that you're hiring BECAUSE you need more people on the team, which often means that team is overworked already.

Re: The rise of never-ending job interviews

#755

Post by jt2190 » Mon, Aug 02, 2021, 2:21 PM UTC

simias wrote: post #683

throwawayboise wrote: post #667

Earlier quoted context omitted.

I've never written a sort from scratch since my college days, over 30 years ago. Also never had a job interview that asked me do to so, or any other coding questions. I'm planning more for retirement than a next job at this point, but I shake my head at what my younger colleagues need to go through these days for the opportunity to write JavaScript with IDEs that do most of the work for you.

I sometimes have to implement a sorting algorithm when I write bare metal code that doesn't have any sort of standard library available. Of course, being a 1337 hacker, I then resort to the state of the art bubble sort. Or maybe an insertion sort if I'm feeling fancy. But enough bragging.

OT: I wish I could relocate a blog post (on Microsoft’s site, I think) about a very a naive and “obviously wrong” sorting algorithm that a dev identified in their (Excel?) codebase. Turns out the code was naive because the vast majority of their users were sorting very small sets of data and the implementation actually performed much better in those circumstances.

Re: The rise of never-ending job interviews

#756

Post by AlwaysRock » Mon, Aug 02, 2021, 2:24 PM UTC

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…

So... What does this comment have to do with the posted article? In the article Google claims that 4 rounds is what they see as the max to get a good hire/no hire signal.

Re: The rise of never-ending job interviews

#757

Post by lbrito » Mon, Aug 02, 2021, 2:25 PM UTC

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…

Had a similar experience.

I was a recent grad, around 10 years ago. A Google recruiter called me out of the blue. After a couple of minutes, she started asking technical questions about Linux, which I had just started using.

After a while came the final blow: I was asked what was the fastest way to sum two integers (there were probably some additional specs I don't recall).

I mumbled something. Wrong! The answer is, in fact, using the TLB. I vaguely remembered what the TLB was from my CPU architecture classes, but was aghast at the connection between that and summing two integers.

The recruiter pretty much said I wasn't Google material on the spot and said goodbye. I felt bad for myself at the time, but now I can see this is a ridiculous approach to interviewing.

Re: The rise of never-ending job interviews

#758

Post by AJRF » Mon, Aug 02, 2021, 2:27 PM UTC

kwertyoowiyop wrote: post #750

sdevonoes wrote: post #568

Earlier quoted context omitted.

> the kind of people who need to cram leetcodes and memorize algorithms are not the kinds of people who Google wants to pass these interviews. I thought it was exactly those who Google wants to pass. Anecdote: ex-colleague of mine who is not specially bright studied 3 months how to "crack the coding interview" and got a job at Google. His knowledge about algorithms and data structures was like mine: I know what a tre…

I’m trying to think of how many tree structures I’ve encountered in all the projects I’ve ever programmed on, in my entire career. Maybe one or two?

You probably aren't the demographic Google want/needs to hire by the sound of it.

Re: The rise of never-ending job interviews

#759

Post by AlwaysRock » Mon, Aug 02, 2021, 2:28 PM UTC

zschuessler wrote: post #709

I was semi-actively hunting for a role a year ago. The worst offender was a company I had five meetings with, 3 of which were identical code reviews for the same code test. None of the reviewers realized I already had the code review with their peers. None knew what the next step was. Most companies just didn't have an organized funnel for candidates. The one that did I quickly took the job offer at. Here's what they…

The paid code review or paid technical is a big one for me. If a company is willing to actually value my time during the interview process then I'm going to be much more interested in them. Instead of just inventing steps and adding seemingly worthless technicals

Re: The rise of never-ending job interviews

#760

Post by endtime » Mon, Aug 02, 2021, 2:29 PM UTC

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…

Standard disclaimer: everything below is my own opinion based on my personal experience, and I'm not speaking on behalf of my employer.

> I thought I was done, then the interviewer said she would go go copy my code and compile it after the interview to see if I was right, which blew my mind.

I've been interviewing at Google for nine years and have never done this. I generally don't think it's fair to ding a candidate for something I don't notice in an interview, where I'm at a huge advantage. If it looks right to me then that's good enough.

But that said, I have often asked questions similar to what you describe. You have to write code in the shared doc because hiring committees want to see it - fair to blame the process for that, but not the interviewer. I actually appreciate this for a couple reasons:

* It levels the playing field a bit, in the sense that code is more objective than an interviewer's notes on how a conversation went (especially for people who aren't native English speakers)

* I sometimes find that candidates who communicate well struggle to turn their ideas info code. Other times, someone's communication and solution are kind of average, but then they use all the little things I like seeing (defaultdict(set), zip, etc. in Python). Lots of people claim to be very experienced programmers; seeing how comfortable and fluent someone is when actually writing code is a strong signal. If you don't like the focus on data structures and algorithms that you haven't thought about since college, you should probably appreciate the coding part.