Hacker News Reader

Comment by npiit | Hacker News Reader

I don't think practicing interviewing should be encouraged even though I know this has been done for years and years. If you want to end up working on something you actually love in a place you like, you should just learn what is interesting to you. Your "dream" job at a FAANG might be more unpleasant and boring than you've been expecting.

View on HN

For one job I wanted I knew a lot of the engineers that worked there went to a specific developer meetup group. So I signed up to give an hour presentation on something. The day I went to the interview the lead interviewer asked - hey are you the same ... that's doing a presentation tonight at ...?

I said - oh yeah you heard about that. Yeah I'm doing that later if you can make it.

Got the job.

I'm starting to agree with that. And the older I get, the less I feel like I want to study for a couple of weeks for an interview process that has a high probability of not resembling the work I'd be doing. The other day an Amazon recruiter called me up and even said that that's the case.

But each their own, I'm sure people are happy going through that process and then also enjoy working there.

I feel the same. This really irks me. Obviously there are areas of building software where algorithms are a big deal. I recently was approached by a facebook recruiter(for android team) and amazon(can't recall the exact engineering position)...the facebook was even saying we will be asking some medium and a a few hard questions......literally ranked the same way as all the sites that people grind. I'm debating if I want to do it or not. Working at those companies can be beneficial for my resume but the interview process bothers me. The fact that you can solve a problem does not mean you are a good software engineer. There is just so much more to development, architecture, oop, good team work and communication etc but maybe it is easier to teach those things than algorithms. Maybe this system works for the big companies. Plus, I think they are more likely to higher people who are obedient as people who simply won't put up with that hiring process might be more of a 'speak up' type.

They're just using them as "how bad you want it" + IQ filters. The interviews end up testing for some combination of that—want very very badly + good but not amazing IQ, or want somewhat + very high IQ, that sort of thing. That one cannot be prepared for these interviews with the work one does 40 hours a week is by design.

Conversely, interview questions often have very little to do with the content of the day to day work. So while studying the things you like may help you ace the day to day work, you could still struggle on the interview if you don’t prep for it specifically.

This is confusing to me, because supposedly there’s a shortage of “good engineers”. That may be the case or not, but if so, why are these additional bottlenecks being added when these interviews universally seem to be perceived as irrelevant to the daily work of engineering? What would make more sense to me is if the focus moved toward architecture design instead of leetcode.

“What stack would you propose for this product?” Instead of, “Take these two arrays of strings and output a new array where no strings has a letter found in another blah blah blah...”

There isn't a shortage of generic developers, but there are shortages of specialized developers. One shortage example would be an SRE who knows Azure, Kubernetes, Jenkins, and Jira, very well. Another example would be a front-end developer who knows iOS development so well that they can make up for the pit-falls of React Native while also writing half decent typescript code.

It's often difficult to interview specialized developers because the specialist often understands (or pretends to understand) the specialty better then the interviewer themselves.

These hiring opportunities represent a large number (maybe even a majority) of roles at small, medium, and large, companies.

FANNG and maybe a few other companies which have custom tool chains from top to bottom are a little bit different because Google probably doesn't care if you know Jenkins because you'll have to be trained in their homegrown alternative anyways.

The demise of training in this industry is pretty lamentable. While companies can't be expected to turn generic developers into incredibly specialized developers, they probably could do more to help the former move closer to the latter.

I think I read something a while back from the point-of-view of a Google recruiter or someone that described their reasoning for this. The reality is that most companies are okay with the possibility of rejecting a good engineer who has all the potential to be a good fit for them. There's really no shortage of candidates who want to work for them, so they are okay with false negatives as long as engineers are still lining up to interview for them. What they aren't okay with, however, is the possibility of accidentally accepting a bad engineer: a problem which is quite costly to remedy.

The current state of algorithm-heavy interview process is really just a hamfisted solution to the problem stated above. They are trying to minimize false-positives while accepting that it increases the rate of false-negatives, and their proxy for implementing this threshold is algorithmic knowledge. It's not fun for anyone involved, but I guess I have to assume it works.

Personally, I've done interviews where I ask a few toy algo questions of increasing difficulty, in a language of their choice. The first question is trivial and screens out candidates who can't code at all. The more difficult questions are more to see if they can communicate clearly about code, and performance / complexity issues, and how they respond to questions and feedback on their code. I don't care that much whether they can solve questions 2 and 3 perfectly, but they should be able to come up with something.

If they pass that I would devise a longer interview suited to their CV. I expect a senior to be able to answer architectural questions and / or talk intelligently about architectural decisions they've made on past projects. If they claim experience in a job-relevant domain I would ask domain-specific questions, if not, the expectation would be that they would ramp up, and I would stick to more general questions.

So the point is to avoid wasting time preparing and doing longer interviews for candidates who can't even calculate the average value of an array (or worse, hiring them), and get a bit of an idea of their ability to think and communicate about code.

I'm honestly not very confident this is a good approach but that's why I did it.

There is no shortage of good engineers applying to these places.

There is a cheap engineer shortage.

Kafka is jealous.

“Your "dream" job at a FAANG might be more unpleasant and boring than you've been expecting.”

The money can compensate for a lot of unpleasantness. I think finding a “dream job” is an illusion for most people. The question is usually “bearable” or “unbearable”.

The practice isn’t just about how to give correct answers. You’ll never be able to practice enough to have prepared answers to every possible question.

The practice is about getting comfortable with the process of being interviewed. Practice is a great way to become more comfortable and confident before the real thing.

Get the anxieties out before you sit down with a real job interview so you can focus on performing well in the interview.

I think of interviewing like I think of other "tests" like the SATs. They're a thing you've got to study for. Just because they don't mirror what your day to day at a job will be like doesn't automatically mean they're of no value.

I think some coding interview questions are bad, some are better, but I don't think the idea that you must take what amounts to a test to get a job is inherently bad.

Do you think you will hold the same opinion 5-10 years down the road?

Uh, I dunno? Is the implication that I'll have less patience for taking tests each time I change a job when it's the Nth time?

Maybe? At 5-6 years out of school, I personally don't mind tests. Sometimes I actually really like tests (e.g., I've started watching youtube vids of Putnam problems, like doing daily problems on brilliant). I can imagine time to study becoming more scarce if I had a family, but I was under the impression that changing jobs was something that's gonna take a healthy amount of time regardless.

To be clear: I think you can have bad tests, and I imagine I'd find it frustrating if I was boxed out of a lot of jobs I thought I'd do really well at because the unrelated test keeps me out. But I don't think needing to study inherently makes a test bad.

I don't think there's anything wrong with practicing interviewing. It can be a good exercise to do some self-reflection and, depending on the type of interview being practiced, can sometimes help prepare for real-world situations/challenges in a 'safe' environment.

Where I do think you're spot on is that you shouldn't focus all of your time practicing one specific type of interview or practicing for interviews at one specific company. FAANG is a good example. I've seen far too many people get enraptured with the "dream" of working at a FAANG, devoting all of their time to practicing FAANG-style interviews, making their whole life about it, and then either not getting the job or they do get the job but they quickly have their illusion shattered that FAANG isn't heaven and they wasted all that time preparing/fantasizing over something that isn't true. It's Paris Syndrome [0] but for jobs.

0: https://en.wikipedia.org/wiki/Paris_syndrome

unfortunately this is the only way to get a job today, almost in any company not just FAANG, no one cares about experience, interests and projects, but only about this randomized IQ test that can be cracked by practice and rote memorization. I think this imperfect filter got widely adopted because of oversupply of people sending resumes.

Absolutely not true, at least in my experience. Could it be a Bay area problem? I'm in Vancouver BC and interviewing right now and it's definitely different here.

Fellow Canadian, living in California but worked in Canada beforehand. There's still plenty of companies who don't ask leetcode style questions. However, none of them pay even close to what the FAANG companies pay in my experience. You can find offers for similar base salaries (there's startups in LA paying 180k base for roles), but the TC is still nothing compared to the 300k+ packages you're getting from the big boys.

It may have changed since I've been living in Canada, but total comp in Toronto at the time were HALF what they were for similar positions in California. Almost all my great engineer friends who still live in my home town in Canada work remote for USA companies for that reason.

For sure salaries don't compare but that wasn't the question. If you want to maximize salary then you probably want to work for FAANG and go through the interview process.

Same experience here. I'd actually say interviewing was a very interesting learning and participative process. Lot of companies handled it as a chat between peers. Usually there is a coding challenge upfront though (understandable).

The beauty of the peer chat was that it shows the company culture. Lot of interesting people. And makes you highly interested in the company and the job.

Not all experiences were great, but I didn't have to go through painful whiteboarding sessions

this is the case in major tech hubs on US coasts with high salaries/competition

I think your first statement sadly doesn't connect with the rest. These days the place you like will most likely pose a similar interview process as the ones at FAANG, even if the material might be slightly less algorithms-heavy.

Reply on news.ycombinator.com