Live data from Hacker News

The rise of never-ending job interviews

bbc.com

861–870 of 1001 posts

Re: The rise of never-ending job interviews

#861
post #822

Earlier quoted context omitted.

My first linux install was Redhat 5.2 bought at a bookstore in ~1997. I have not always been a primary linux user, but I have been using it in some capacity for over 20 years now- though as a means to an end primarily- in the bad old days I mucked around with drivers and X configs and have even recompiled a custom kernel on occasion. Never once has it come up that the filename is not stored in the inode. I am actuall…

You'd never need to know anything about it as a user. I don't know how anyone could seriously make the argument otherwise. In fact the only reason I know anything about inode and dentry specifics is because they are 'very clever' interviewer favorites! I've been a professional UNIX admin for 15 years and I've dealt with inode issues literally once in my life lol

Thanks. Its comments like the GPs that makes me wonder how I have avoided learning some very commonplace issue and its these types of comments that foment imposter syndrome.

I have even read books on linux architecture and remember discussions about filesystems and inodes and remember the general structure and form, but a detail around what is and what is not stored in the actual inode... seems like an absurd detail to memorize.

The only way I could see this being commonplace is if I somehow missed out on a widespread bug that somehow caused inodes to be corrupted and requiring manual intervention/surgery to prevent data loss.

Re: The rise of never-ending job interviews

#862

Earlier quoted context omitted.

Pretend there's a Programming Quotient (PQ) which is like IQ. Let's say Google would like candidates with PQ>130 with 95% confidence. Google has an error with std. div. of 15 points in measurement of PQ in jobs interviews. Google then needs to set the hiring bar at 160 PQ in order to get those candidates. This: - screens most qualified candidates out; but - most candidates who do screen in are qualified Statistics wo…

I’ve used Google’s software. I’m not sure they’re all that great. Someone just released a product that offloads Chrome to the cloud. Gmail has a very long loading screen. Hangouts was replaced by something like 4 incompatible apps. Android phones are significantly less power efficient than iPhones. YouTube copyright notices are trivial to game. Etc

I think the bar I gave, PQ of 130, is about right for Google. Your typical Google programmer is pretty bright and pretty competent, but not spectacular.

Most of what makes big companies succeed or fail is in the overall culture, organizational design, incentive structure, and corporate structure -- properties of a network of individuals rather than of those individuals themselves. I think most of Google's success and failings can be explained that way, much more so than the success or fault of employee quality.

Organizational design is really hard to get right. A senior manager described it like a herd of cats. If you get them all mostly moving in a beneficial direction, you're doing okay.

That's why they pay executives the big bucks. Executives fake understanding how to manage this stuff. Most don't, but they do a good job of convincing boards that they do.

Re: The rise of never-ending job interviews

#863
post #833

Earlier quoted context omitted.

If he has the skills to get such offers, then he's in a power position with employers, which explains his demeanor towards them

Definitely, if you’re being recruited for L8, thats a level of distinction all on its own..

Hard to know what to make of these comments.

I've known a lot of far better engineers than I am. We've all been in this game a long time. Titles, companies and package aren't the most important thing to any of them. I'm sure most will look back and even though our titles and roles appear to have changed it feels like we still do much the same as we always did, just at a different scope and what's important is whether the work is engaging, there's as little politics as possible, and you're setup for success.

Re: The rise of never-ending job interviews

#864

Earlier quoted context omitted.

Pretend there's a Programming Quotient (PQ) which is like IQ. Let's say Google would like candidates with PQ>130 with 95% confidence. Google has an error with std. div. of 15 points in measurement of PQ in jobs interviews. Google then needs to set the hiring bar at 160 PQ in order to get those candidates. This: - screens most qualified candidates out; but - most candidates who do screen in are qualified Statistics wo…

This is an excellent way of looking at this and many other high bar organisations - thank you !

It's helpful to explain this to recent grads.

A lot of really good people are discouraged by repeated rejection. However, high levels of rejection of very qualified people are built into this (and many similar) systems. You have to be qualified AND get a lucky die roll to get in the front door. Once people stop taking rejection personally, they can start acting more rationally, and there's less emotional harm. People feel really bad about themselves otherwise.

There are back doors with less luck involved.

Re: The rise of never-ending job interviews

#865
This trend is absolutely ridiculous. I'm currently in "Round 3" and have FIVE interviews this week, four of which are technical. I already passed the technical in Round 2.

As someone with 10+ years experience in the industry, I've about had it with these technicals. I'm just going to start refusing. I'm happy to have a long technical discussion on my work experience and to provide you with portfolio examples. Take your hacker rank problems and get out of here.

Re: The rise of never-ending job interviews

#866

Earlier quoted context omitted.

Except that lawyers have to pass the California bar once in order to get licensed; we SWEs have to pass the "bar" every time we look for a new job.

From what I've heard, the bar is much harder than SWE interviews.

My first degree was civil engineering and I took the California Engineers in Training exam back in my college days and boy was it tough even though I had stellar grades from a top university. You could bring mountains of reference books to the exam but you had no time to use them. You had to solve endless problems based on fundamental techniques you already learned during your education.

Re: The rise of never-ending job interviews

#867

Earlier quoted context omitted.

Almost everybody with some Linux experience knows that the file name is not stored on the inode. It's not this part that makes the question bad. What makes the question bad is that nobody can guess what answer he wants, and anything else, as correct as it may be, will be understood as a mistake (what is evident by the OP's answers that were perfectly correct). "What number am I thinking right now" may be a really str…

My first linux install was Redhat 5.2 bought at a bookstore in ~1997. I have not always been a primary linux user, but I have been using it in some capacity for over 20 years now- though as a means to an end primarily- in the bad old days I mucked around with drivers and X configs and have even recompiled a custom kernel on occasion. Never once has it come up that the filename is not stored in the inode. I am actuall…

Probably the most common case where this comes up is in the context of hard links: two (or more) files with different names that point to the same inode. I guess actual usage of hard links is rare enough that it doesn't come up all that often, but I'm actually surprised you didn't know this – not judging you, just something I thought most more experienced Linux/Unix users knew, but it seems not.

Hard links can be a somewhat notorious footgun due to this by the way; with a soft link you know you're only deleting a link, but with "rm hard-link" this is a bit trickier: if you think there's another link but actually, it turns out you made an error and there's not then you've lost that file. A "hard link" isn't really a thing on its own: it's just another reference to an inode. This is why symbolic links are used in most cases, but you can hard links are still used from time to time in e.g. /bin and some other places.

Re: The rise of never-ending job interviews

#868
post #342

I’m usually OK with doing more than three calls after a recruiter call (which are ideally with a hiring manager, peer manager, and a prospective peer), but that is usually because I quite like getting a feel for company culture. More than that is just silly and contrived (although I usually end up talking to a VP or similar these days on account of my seniority). There are usually three major red flags that make me s…

regarding the last point, nowadays what I see is the opposite where candidates still struggle with getting a clear salary range before engaging into time wasting exercises.

Re: The rise of never-ending job interviews

#869

Earlier quoted context omitted.

In my startup I interviewed a 48 years old senior Java programmer with excellent resume, who took 1hr to write a String.contains(), it only worked for the requested 4 letters, didn’t work if a letter was repeated twice, and didn’t work with Chinese characters. At least it had the JUnit. I asked an employee to do it too and he made his code pass the JUnit in 6 minutes. The candidate hated the interview, claiming it wa…

But which is more likely? 1. The candidate was a complete and utter fraud and their previous (and apparently well-regarded) employers were too stupid or negligent to notice this, wasting literally millions of dollars (48-21 * $100,000+). 2. Something about the interview failed to let this person demonstrate the skills that had kept them employed for two decades. Maybe their mind went blank under pressure, or at the e…

I've repeatedly had employers very happy with my abilities & results, and am also entirely sure I've, on a few occasions, convinced interviewers I'm entirely unable to write code and am one of these frauds everyone's sure exist and that they need these coding tests to "catch".

Re: The rise of never-ending job interviews

#870

Earlier quoted context omitted.

I have done this. Is it really such an insane idea? Makes for a nice break from "what does this code do"? You need some technical "anchor" to make for more concrete discussion points.

Would you accept "my build toolchain and linter will catch all of these syntax and stylistic errors." as an answer? 'Cause that's what all your devs are going to do IRL.

Not really since that doesn't leave much room for discussion, but that is my problem not theirs. The point is to have something to discuss, not to listen for a singular answer. Now we can discuss hypothetical situations and philosophy but I'd much rather have a concrete piece of code to go through.

Seeking out problems and errors can be a good conversation piece. Hopefully you get to hear some anecdotes, prod the taste in style and how well that that taste might play with others. The interview situation isn't easy for anyone, and anything that can if something is even remotely qualified helps.

Post reply on HN