Hacker News Reader

I find that for more problems you do need a trick. Once you memorize some of the main algorithms asked, usually the questions are a twist on common algorithms + some trick that is not obvious.

Sure you it can become easy if you "Practice" but everything gets easier the more you do it.

People who pass these either have have IQ or have grit, thats why companies use this to judge canidates, either you spent 500 hours on learning it or DS/A just sticks to your head like glue.

the main problem is that you can get caught in an interviewing pet project, so it seems obvious for them, but not for you. Properly done, a code interview could not require clever tricks, but the problem is that it's just too easy to slip into that realm...

That's true, you can get unlucky with interviewers.

The quality of the interviewer is one thing that the interviewee can’t control. The main interviewer failures are:

1) Letting the interviewer struggle. By the end of the interview, the candidate should know what the solution looks like, even if they couldn’t solve the problem themselves. If you let someone struggle too long, you’re failing them. Give feedback early. Point out caveats. Don’t have them code up a dumb a solution, and then in the last 10 minutes tell them to redo it with a completely different approach because it’s suboptimal. (Im not talking about special cars they can retrofit, or if the original wrong solution was trivial. Use your judgement.) The interviewer understands the nuances of the problem. The candidate probably doesn’t. After all, they just heard problem.

2) DO NOT CONFUSE THEM! This happens by giving the wrong feedback. You might think you’re helping someone, but you could be knocking them off their game. If they’re going for the optimal solution, and they know the approach, just let them. It’s not wrong, I’m fact it’s the most correct answer. It’s very easy to confuse someone in these timed and stressful situations. Don’t don’t do it!

3) If it’s a design question, or something else with multiple reasonable answers, then there are multiple correct answers. Make them state their assumptions. Ask how the solution would change if something was different.

Don’t expect someone to come in off the street and understand the nuances of your use case and data issues. You didn’t understand them until you were confronted with the obstacles either.

Binary search

Quicksort

Mergesort

Dijkstra’s algorthim

Depth first search

Breadth first search

Doubly linked list

Semaphores and mutexes

Make sure you know the recursive versions of the algorithms, and that’s pretty much everything you ever need for a generic coding interview, and you might not even get asked a dynamic programming or a producer-consumer question.

Maybe you need some more specialized data structures for a more specialized role (eg tries[0] and inverted indices, for a search job), but you probably already knew those if you were already doing that job.

There’s just not that much to know.

[0] https://en.wikipedia.org/wiki/Trie

> Coding interviews are the easiest interviews.

For you. I am a bit over a year into my eng career and coding interviews are far harder than any other type of interview for me. I have a handful of stock behavioral question answers that I can adjust for most non technical interviews. I do minimal prep before hand looking up who I am interviewing with to have a few questions for them and try to find a way to relate to them during the interview.

That is much easier than someone asking me anything from fizz buzz to red black trees.

No one asks anyone to implement a red-black tree. There are too many special cases. Just know it exists and what problem it’s trying to solve.

Fizz buzz is a hello world problem. That’s why it exists.

I'm giving examples of the range of questions that exist. I've been given Fizz Buzz in a real coding interview. I'm sure someone has been asked to implement a red-black tree before.

Replace red-black tree implementation with some other silly overly complex question that isnt related to the actual job.

They might ask you to implement sqrt(), but the question being asked isn’t “Can this person implement square root using Newton’s Method?”, it’s “How does this person tackle a problem without an obvious solution?”

Absolutely agree. I’ve found that behavioral interviews are harder than technical interviews at this point. If you don’t have the set of experiences they’re looking for then it’s game over.

This can be ameliorated slightly if the interviewer is willing to accept a hypothetical, but this has rarely been the case for me recently.

Or if your management philosophy doesn’t mesh with theirs.

“Tell me about the last time you had make your team work late for a deadline.”

“I don’t. It’s been my experience as both an IC and a a manager that crunches just burn people out, and you end up getting less quality work out of them. It’s much better to communicate early and either adjust deadlines or deliverables.”

“What if you can’t?”

“Unless there is an external forcing function on the company, everything should be negotiable. Does this happen a lot here?”

“One or twice a year.”

“Huh. It’s only happened to me once in ten years, and that was due to a multimillion dollar contract deadline. If it happens regularly here, then the company should fire the directors of engineering for gross incompetence. They can’t project manage.”

Needless to say, I didn’t get the job, but at that point, why would I have wanted it?

>Manufacture some demand, and you have a low effort company

What do you mean by that?

I’ve interviewed at four of the five FAANGs, and got offers from three of them, including one of them twice. I’ve interviewed at I don’t know how many startups and midsized companies as well. All the technical interviews are the same. You might get some better interviewers at the bigger companies, but that’s more due to practice on their part. They just have interviewed more people overall, and have asked this question enough times they know the common mistakes.

There’s this belief that FAANG interviews are somehow harder, and you need to study for months to prepare, and it’s not really true. It’s the same MO as the test prep business, but with less obvious metrics for success. (You don’t get standardized test scores to compare, you just get an offer… eventually. Did the interview prep business help? Who knows?)

The interview prep businesses push the specious idea that FAANGs are tougher, and people believe it. (eg Less than 1% of FAANG applicants get an offer! Well, yeah. Do you know how many people apply? A lot. Do you know how many are nowhere near qualified for the job they’re applying for? Probably more than half.) They keep repeating these claims, they end up scaring people into paying for something that’s not needed. That’s the manufacturing demand part.

The low effort part is that technical interview questions and programming puzzles are a penny for two dozen. You give the question and the solution in maybe three different languages (say, JavaScript, Python, and Java) and you’re done. Charge $500 for ten questions, give them a HackerRank link, and you’re done. You’ll spend more on advertising and paid testimonials than anything else.

The interview prep companies don’t focus on the noncoding interviews, because they’re harder to find questions for, and harder to grade. When it comes to personal interviews, you have work with each student one on one to help them talk about their experiences most effectively. That’s high touch. If you’re trying to maximize volume, you don’t do that.

Makes sense, thanks for clarification. But there could be people who are some where in between you and not-qualified, whom this site might be helpful, it's connecting people for specific purpose.

The site says you can request somebody from FAANG for mock interview, without knowing quality of these interviews, I assume that would require this company pay for their time.