Hacker News Reader

Comment by lexapro | Hacker News Reader

>The normal tech interview questions about sorting or recursion or whatever are not supposed to be business-relevant questions, they are to filter out people who simply can't program.

It's perfectly possible to be a 10x engineer but not being able to solve some obscure recursion problem on a whiteboard. All it does is forcing candidates to study obscure problems before the interview and hope they get lucky and receive a problem that they have memorized so they can pretend to have never seen it.

View on HN

You don't have to solve it, they are interested in seeing you _try_ to solve it.

Every interview I have done expects you to solve the problem.

And most expect it to be solved perfectly on the first try. I was rejected by Google when I solved a LC hard problem (in Google Docs), and when asked the time complexity I said something like, "It's O(nlogn). Wait, it's O(logn), [explanation why that's the case, which was correct]." Feedback: "struggled with figuring out the time complexity." *eye_roll*

Honestly, stuff like this makes me wonder if there's some metric that judges the reviewers, such as "percent of interviews in which feedback is given".

I've experienced this as my company recently implemented metrics for code reviews, with one of them being "percent of lines commented on during a code review"; which unfortunately makes me comment on lines that I wouldn't usually do just to serve the metric.

I'm wondering if they have a similar thing.

late reply, but I know for Google they're required to start participating in interviews to be promoted to L4 (?) and above, whether they have interest in it or not. Maybe there is a disproportionately harsh performance penalty for recommending someone for hire that shouldn't be hired, vs the other way around, and the easiest way to "tick the box" for the promotion is to do the interviews and reject everyone (unless they're seriously impressive).

( Opinions are my own )

Anacdata: last year I passed the interview at Google. I completely failed to solve one of my coding interview questions. I demonstrated I knew what to do but I attempted a fancy way to write the code and it didn't pan out. Completely fell on my ass.

Other interviews went very well though. Only comment I got was "X said your code was a little messy" because I used python generators + list comprehensions.

You can totally fail a question in a tight time slot if the process is built right.

What is stupid is the variability in opinions if interviews. This one dude disliked list comprehensions so much he lowered his rating of me despite this being a normal thing for python programmers. You have no way to know if you hit a nerve ahead of time for an interview and it sucks. I had similar things happen with things like discussing the C spec with interviewers in questions like "what happens when you dereference a pointer to 0" and then you have to say "you want me to say segfault but this depends on the vmm and ring your process is running on".

And the variability, or just the uncertainty in the interview of what they are looking for.

I got dinged for using a promise over async/await (for a backend job that mostly tested my React of all things).

I had absolutely no idea that mattered to them.

>seeing you _try_ to solve it

And pretend that their judgement is any better than coin tosses.

If I am ever exceedingly bored with my life I'll start applying for some jobs just to throw some shade in the form of "the brightest minds of psychology have failed at doing what you are trying to do, with far more resources and time dedicated to it... why do you think you can do it?".

It is better than coin toss. If you can't communicate a convincing solution or approach to your future team mates why should they hire you?

Hah, I don't mean to be rude but, this is what everyone claims they do, but no-one actually practices it.

The simple fact of the matter is, is that if you can't 100% solve the problem, in 30 minutes or less, without asking questions related to how to construct a solution, and cover all edge cases, and come up with the absolute top-tier optimal solution, you're getting rejected.

That is why it's worthless as an interview technique. Everyone plays this whole song-and-dance about how they "just want to see how you approach a problem you might not know how to solve" but, in the end, the only thing that matters is regurgitating the top leetcode solution to the problem.

This is so true, most top companies expect folks to write flawless bug free code of problem in 20 minutes or less now. Some expect two problems in 45 minutes now (if you are unlucky really one medium and one hard). If you write a sub-optimal solution you are rejected for sure. If you haven't grinded leetcode/hackerrank and haven't seen it before there is no way you are going to solve a hard problem in 20 minutes - lets say 10 minutes to think and 10 minutes to write the code for a hard leetcode question.

Obviously, since large companies _have_ lots of employees, either their tests aren't crazy hard, or there are lots of people way smarter than you for whom the same tests are manageable.

Or, you know, they're smart problem solvers and don't need to rely on memorizing.

Is that what you really end up testing though? As parent mentioned this can be broken by simply memorising, so are you sure the candidate is a good problem solver or are they just good parrots?

So I think it's actually evolved into a weird sort of test of conscientiousness. Originally the idea was probably that we will test people's abstract problem solving skills. Can they come up with a solution on the fly? Ok, now can they figure out any clever optimizations?

But at this point it is sort of expected that if you are interviewing with a FAANG you will be getting these sorts of questions (and they tell you that up front), so it becomes a sort of test of "is this person willing to spend 10 hours preparing for an interview"?

Yeah I suspect this is the case, the original intention and structure was solid but it's been progressively shifted into that FAANG space. I think the only solution is probably a question tailor made to the company interviewing, that doesn't rely on leetcode-style approaches to solve.

10 hours? Preparing for FAANG interviews requires months of preparation.

I hardly think a solid interview question can be solved through memorization.

I’ve had interviewers ask about cycle detection in a linked list. The answer was of course the classic tortoise and hare algorithm. Which took ~15 years to come up with, and was found by a Turing award winner.

Anybody who claimed they “came up with the algorithm themselves” in a few minutes in an interview is a liar, and anyone who takes them at their word is a fool.

Well, it's not a rocket science algorithm. But regardless, it's a very bad interview question indeed.

Reply on news.ycombinator.com