Hacker News Reader

Comment by Grustaf | Hacker News Reader

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

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.

>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?

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.

Reply on news.ycombinator.com