Live data from Hacker News

The rise of never-ending job interviews

bbc.com

541–550 of 1001 posts

Re: The rise of never-ending job interviews

#541

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…

Isn't the question nonsensical ? inodes are a property of some filesystems like ext, xfs..., that you can happen to use on Linux. If you installed Linux, say, on an NTFS partition there would be no inode anywhere, no ?

the inode vs filename distinction is historical unix behavior (but I don't remember whether posix mandates it), and it is quite important and relevant in many system programming scenarios. Of course not all filesystems support it.

The question is still phrased terribly of course and the candidate would have to reverse engineer what the interviewer is actually asking to have a chance to answer it.

Re: The rise of never-ending job interviews

#542
Aside from being tech lead for my project I am also technical interviewer and I regularly interview candidates.

Recently I have asked my HR if they could set up longer meetings with candidates because, honestly, 1.5h is in my opinion not enough to evaluate candidate. I would like to ask some technical questions, I would like to see the candidate write some code, I would like to have a discussion on general tech topics just to get the feel of the candidate. And also have time to respond to questions that the candidate may have.

Usually it is the coderpad part that overflows and takes more time but it is also hugely helpful in understanding how candidate works and deals with problems.

So the response from HR was that they "don't want to scare the candidate". And if I need, maybe they will set up follow up with the candidate "just don't tell the candidate upfront to not scare them".

So that's that.

Re: The rise of never-ending job interviews

#543
post #511

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 inode question is tricky. It is certainly not something an employer should take for granted you have memorized. But the answer can be reached by reasoning, at least if you know something about filesystems and the concept of hard links. Which you probably do if you have read the "ln" man page. It is still a pretty poor question, I remember getting a similar kind of question when I passed through the (at the time,…

Well, maybe it'd be better called "aptitude test": if you don't know that gasoline lighter than water that means you've never handled it manually, so better not put you into an automechanic position.

Re: The rise of never-ending job interviews

#544

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…

>What's not in a Linux inode? Wow, even if you were hiring filesystem experts to write filesystems I think there are a million better ways to ask that question. e.g.: "Hey, talk me through the design of a really basic filesystem, it needs to support hardlinks, symlinks, files and directories."

I'm not experienced in tech interviews nor knowledgeable about inodes ... but your question and the interviewer's question seem like they're functionally equivalent. They presumably don't just want you to say "names", they're expecting you to talk about what is in a Linux inode, what a directory is, etc., and they can drop in further questions to prompt you if you don't "talk me through the design of a basic filesystem".

If the question is too vacuous surely you ask for clarification -- "well, what happens when you issue the 'mv' command" -- and presumably if you designed file systems you can talk about different implementations, optimisations, and problems crossing filesystem boundaries or whatever.

Re: The rise of never-ending job interviews

#545

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.

Done right there will be a lot more in there than syntax errors. A good example of this sort of test will separate those who have revised syntax without really thinking (they'll get the syntax errors but little or nothing else, great if you want to employ a human linter) from those who actually think about what they are looking at will spot much more (a logical error that would cause an infinite loop, a point where a comment and the code disagree, an incorrectly validated input, an injection flaw, a heavy expression inside a loop that could be done first and result-cached for efficiency (your compiler cannot always identify such situations), hard-coded credentials, bad naming, ...). The best may identify some but also state why in the grand scheme of things is might not matter (efficiency in code that runs once so 10μs and 100μs is statistical noise) or where other priorities might take precedence (for example readability and therefore ease of maintenance).

Re: The rise of never-ending job interviews

#546
post #327

Earlier quoted context omitted.

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.

While I understand where you are coming from, I disagree. IDE tools are great performance enhancers, but they can also be crutches. I would always expect a professional software developer to be able to parse some code on a page and point out its syntax errors (as well as suggest edits). edit; here I am thinking about something more substancial then just a missing ';' or a lack of a closing "

[deleted]

Re: The rise of never-ending job interviews

#547
Preferably one. Perhaps two if there are unanswered questions. You're really, really pushing it at three, however. Unless I'm compensated for the time I'm about to waste, I might not bother meeting up to a third interview.

Re: The rise of never-ending job interviews

#548
post #511

Earlier quoted context omitted.

The inode question is tricky. It is certainly not something an employer should take for granted you have memorized. But the answer can be reached by reasoning, at least if you know something about filesystems and the concept of hard links. Which you probably do if you have read the "ln" man page. It is still a pretty poor question, I remember getting a similar kind of question when I passed through the (at the time,…

> "What is heaviest, gasoline or water?" It depends on the amount. Two pounds of gasoline are heavier than one pound of water. Yes, I get that they are asking about density, not mass. My point is that tests need to be carefully written. I remember once during an early online screening at a multinational they asked something like Alice went shopping in the morning and bought apples. What did she buy? A) Apples. B) Ora…

If looking for the best answer, you can rule out B but A vs C is still ambiguous.

Re: The rise of never-ending job interviews

#549
post #327

Earlier quoted context omitted.

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.

While I understand where you are coming from, I disagree. IDE tools are great performance enhancers, but they can also be crutches. I would always expect a professional software developer to be able to parse some code on a page and point out its syntax errors (as well as suggest edits). edit; here I am thinking about something more substancial then just a missing ';' or a lack of a closing "

Let's use (C++) something not common, but not all that crazy:

    bool x = false;
    x ||= something();
How many multi-lingual programmers will remember which one of the 7 languages they know does have a boolean assignment operators and which do not without looking it up? Does that make them unprofessional?

How many do remember exact operator precedence rules for all those languages, when in practice you may need just the basic ones and use () to work around the lack of exact knowledge.

Also which version? Something not working in PHP 7.3 may be ok in PHP 8, but company wants you to code in PHP 7.3, or ES5. In practice you get quickly acclimatized to any of the languages you know after working with them for a few days or a week, but good luck remembering exact rules of any of them at any given time when asked.

Re: The rise of never-ending job interviews

#550

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.

I had to review someone's PR for one interview. Ultimately I failed it because me feedback focussed solely on implementation details and asking if there are better ways to solve the problem (with some suggestions as a nudge). Apparently, that was fantastic and showed all the qualities of good coaching...but they expected me to point out all of the instances of poor indentation and other aesthetic things. My justification that it was unimportant and that running rubocop would fix it wasn't good enough - the PR had to know all of the nitpicks.

You know, if I had to do that for every PR I reviewed, I'd be burned out in no time.

It was a shame, but if I didn't flunk that interview then I wouldn't be where I am now.

Post reply on HN