Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tech Interview Handbook

yangshun.github.io

Post reply on HN
Print view View original

61–70 of 344 posts

Re: Tech Interview Handbook

#61

Post by _hardwaregeek »

triceratops wrote: post #39
_hardwaregeek wrote: post #37

Earlier quoted context omitted.

Because you get the college applications problem, where you stop getting the people who have a real passion for programming and coincidentally have problem solving and algorithms skills, and start getting people who are really good at problem solving and algorithms and may or may not have a passion for programming.

> start getting people who are really good at problem solving and algorithms and may or may not have a passion for programming. Why is "passion" so important? And what even is passion? For professionals in every other field, competence, ability to deliver results, and getting along with people, are what matter. Many pros are passionate, in the sense of loving their work, but passion isn't a prerequisite for being a p…

Oy vey. I didn't mean passion in the "I'll work 80 hours a week for little pay mister!" kind of way. I mispoke. I meant that before, if you based your interview process off data structures and algorithms, you'd get competent professionals who just happened to be good at algorithms. While now you'll get a bunch of people who have specifically trained to be good at algorithms. Which has no bearing on competence.

Re: Tech Interview Handbook

#62

Post by agentultra »

dmoy wrote: post #23
DavidWoof wrote: post #11

I realize everybody's going to jump in and rant about algorithms in interviews, but I wish you'd all add something constructive as well. I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot. Resumes are meaningless, and often re-written by recruiters to match the job anyway. Everyone has the same canned answers to the stupid behavioral questions. And as for the code, w…

> Is this kind of code problem too complicated in your opinion? For all I join in when complaining about irrelevant algorithmic No. Just programming is actually not easy and a lot of people apply for jobs they can't do. Plus, a nonzero number of people freeze up in any interview situation. I once failed an interview loop because I forgot how bucket sort works.

Also 95% of job descriptions list skills candidates will never use and screen candidates with problems they will never encounter.

At the final interview to join the SRE team at Google I was asked to implement the kNN algorithm. I barfed at implementing a kD-tree after regurgitating the brute force solution.

Has any SRE ever had to implement a kD-tree in I asked the interviewer at the end. They had never implemented one on the job.

As long as companies insist on these inane rituals I think it’s fair game to optimize for it as an interviewee.

It’s stupid but what else can you do?

Re: Tech Interview Handbook

#63

Post by Consultant32452 »

DavidWoof wrote: post #40
triceratops wrote: post #31

Earlier quoted context omitted.

Sorry what I meant was US companies could treat the first 3 months of any full-time/W-2 employee as probationary because they can fire anyone for any reason other than protected characteristics. It doesn't even need to be an official company policy documented anywhere.`

They could in theory, but nobody wants to. I used to see probationary periods, but I haven't seen a company use that for salaried staff for a long time. HR and Legal have put an end to that kind of thing. So Jim is right, in practice the only way HR is going to let you have a probationary period is to use contractors, and that limits your hiring pool significantly.

Every decent sized contracting firm I've ever worked with offered benefits. It's more expensive, but you just price that into your rate. So I don't understand what the concern is. Is it the risk that after 3 months you won't be brought on full time?

Re: Tech Interview Handbook

#64

Post by yumraj »

sthatipamala wrote: post #12
yumraj wrote: post #7

Given the current state of tech interviews, they have more or less become like standardized tests, such as SAT, ACT, GMAT, GRE... with guides, cheat sheets and perhaps neighborhood coaching institutes on the horizon with instructors who have cleared tech interviews in FAANGs. Are we going to see tech recruitment become more and more like college admissions where a top score in the interview is just one of the criteri…

There's a YC company that's literally making a standardized test for programmers: https://cspa.io/

I really hope this fails, something I have never wished for any other startup.

At least personally in my hirings I'll never use or trust anything like this.

There are so many things wrong with this approach that I'm kinda speachless as to where to start.

Re: Tech Interview Handbook

#65

Post by yumraj »

closeparen wrote: post #57
yumraj wrote: post #7

Given the current state of tech interviews, they have more or less become like standardized tests, such as SAT, ACT, GMAT, GRE... with guides, cheat sheets and perhaps neighborhood coaching institutes on the horizon with instructors who have cleared tech interviews in FAANGs. Are we going to see tech recruitment become more and more like college admissions where a top score in the interview is just one of the criteri…

Bright high school students are vastly oversupplied compared to seats in elite colleges. Graduation rates are in the high 90s. There are many more than 5,000 kids who can handle the workload; which 5,000 you pick is arbitrary. Engineering competence is not even slightly oversupplied compared to useful engineering work. Project failures, incompetent people, and systematically incompetent orgs are still very much alive…

Replace high school students with engineering graduates and elite colleges with elite employers in your first para.... And see..

Re: Tech Interview Handbook

#66

Post by craz8 »

So, as someone who’s been out of school for a million years, after my name and contact info, my education info is the second most important thing?

I don’t think so

Maybe this should be titled “Just Graduated? Some Useful Tips”

Re: Tech Interview Handbook

#67

Post by closeparen »

yumraj wrote: post #65
closeparen wrote: post #57

Earlier quoted context omitted.

Bright high school students are vastly oversupplied compared to seats in elite colleges. Graduation rates are in the high 90s. There are many more than 5,000 kids who can handle the workload; which 5,000 you pick is arbitrary. Engineering competence is not even slightly oversupplied compared to useful engineering work. Project failures, incompetent people, and systematically incompetent orgs are still very much alive…

Replace high school students with engineering graduates and elite colleges with elite employers in your first para.... And see..

Elite employers are nowhere close to getting all their projects done successfully or with reasonable quality. The subset of engineering graduates who can do that is small.

Re: Tech Interview Handbook

#69

Post by [deleted] »

bpchaps wrote: post #45
new299 wrote: post #41

Earlier quoted context omitted.

I'm curious to hear the opinions of people who think that the question is too hard (i.e. it's too complex of a question to ask in an interview situation). Perhaps some people might feel that while they could write code to solve this problem (or similar problems) outside of an interview. However, under the pressure of an interview they would not be able to solve the problem (due to anxiety, stress etc.). If that was r…

The fizzbuzz test is not entirely about whether someone can do it. It's also about figuring out the style of the programmer. There's a surprising amount of flexibility to fizzbuzz; how is user input handled? Do they use a linter? How are variables managed/named? There's a lot going on, and it can be gamed just like anything else on both ends. That said, the last time I had a fizzbuzz take-home test, it was infuriatin…

[deleted]

Re: Tech Interview Handbook

#70

Post by codingslave »

triceratops wrote: post #18
codingslave wrote: post #4

Two outcomes for the technical industry: 1.) Everyone is studying these problems all of the time and they finally disappear. 2.) Other outcome is a dystopian field fueled by a race to the bottom where everyone is practicing algorithms problems all of the time. If you read the blind forums, some people are completing 500-1000 leetcode problems before heading into interviews. I'm putting my money on number 2, which is…

> Can only imagine what this is doing to code quality... Why would studying algorithms and data structures affect code quality? They would similarly be able to learn to write quality code once they're inside the company, no?

Because these people are just memorizing coding problems. It's like a spelling b
Post reply on HN