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

311–320 of 344 posts

Re: Tech Interview Handbook

#311

Post by triceratops »

closeparen wrote: post #290
triceratops wrote: post #133

Earlier quoted context omitted.

Why can't people who study to get good at algorithms also study to write better code? They've already demonstrated their aptitude for learning difficult things.

Maybe they can , but why would they? Algorithms interviews are the only thing with an actual bearing on their future earnings.

> Maybe they can, but why would they?

Professional pride? Wanting to get better?

> Algorithms interviews are the only thing with an actual bearing on their future earnings.

Do they not want promotions or pay increases at their current jobs before leaving? Usually you have to do good quality work to get promoted.

Please read my original comment: https://news.ycombinator.com/item?id=20727948. People who lack these skills can learn after getting hired. Any software company worth working at has a code review and design review process.

Re: Tech Interview Handbook

#312

Post by triceratops »

closeparen wrote: post #292
triceratops wrote: post #243

Earlier quoted context omitted.

> Because these problems encourages you to write unreadable code. First off, no, writing good code in an interview wins you additional points. Second, why do you think candidates can (or will) continue doing that on the job? New employees aren't allowed free rein to check in code from day 1 at most places - trust has to be earned. And I don't think any decent company allows check-ins without review.

Code reviews are good at catching oversights and at giving design & implementation pointers to people acting in good faith. Senior talent doesn't have the time or energy to push back on all of a systematically incompetent person's code until it's good. See the bullshit asymmetry principle. And once you hire two of these people, they'll just review each other.

> giving design & implementation pointers to people acting in good faith

Why automatically ascribe bad faith to people who study for coding interviews? They went to all that trouble to get better at something, so they're obviously diligent and seek self-improvement.

> Senior talent doesn't have the time or energy to push back on all of a systematically incompetent person's code until it's good.

That sounds like a problem with the company's timelines or priorities. If senior talent is so strapped for time that they can't insist on decent designs upfront, then they likely can't hire the right people either. Because even that takes time and energy. Mentoring juniors is part of the job for senior engineers.

Re: Tech Interview Handbook

#313

Post by Aperocky »

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…

This.

I loath writing algorithm on whiteboard, especially the 'catchy' type. But I've interviewed people who can't even write a for loop.. the amount of brain drain in the flyover country is insane.

Re: Tech Interview Handbook

#314

Post by Aperocky »

jjav wrote: post #84
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…

I can tell you how I do it and would certainly recommend it as the way it should be done. For some context, I've been interviewing software engineers for about 25 years in companies ranging from established multi-nationals to tiny startups in very fast headcount-growth mode. I'm in silicon valley. I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction. It'd be nice to think I…

I think fizz-buzz is still an appropriate screen.

While it maybe easy to hire dev who have been on the market for 10 years. You still have to keep in mind that new developers are still a very large proportion of the dev population.

Re: Tech Interview Handbook

#315

Post by Aperocky »

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…

Judging from the people I work with (FAANG). I would say that this screening is successful, if someone truly awful got in, then there's still PIP. But those are relatively uncommon.

Re: Tech Interview Handbook

#316

Post by nunb »

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…

Even worse, engineering management is desperately in short supply. However the beauty competition nature of the project and vendor selection process is the root cause of failure imho. And that's not fixable in tech, in fact, the problem is so meta (and metastatic) that only the PG recommended "end-run" to provide value to end users can cut through the BS.

Re: Tech Interview Handbook

#317

Post by james_s_tayler »

goatinaboat wrote: post #197
EliRivers wrote: post #150

Earlier quoted context omitted.

My immediate reaction is that the problem with that approach is that it’s simply too expensive for the hiring company Is it? The cost of hiring the wrong person can be huge. Not just agency fees if they came through a recruiter (those aren't cheap!), but also all the time people then spend on the bad employee and all the damage that person does before the mistake is rectified. If this system of reading the resumes an…

The cost of hiring the wrong person can be huge. This just isn’t true. Every company has a “probation period” usually 3 months where either party can terminate the agreement. That’s more than sufficient to cover this risk. You don’t pay the recruiter until probation is passed - everyone knows this. This meme comes from Spolsky who somehow also convinced the world that the hottest programming talent was beating down h…

>This just isn’t true. Every company has a “probation period” usually 3 months where either party can terminate the agreement. That’s more than sufficient to cover this risk.

Yeaaaah no. I've seen people nope out of a job within anywhere between 30 mins to a couple of months. I've also seen people that knew it wasn't right for them stay 1 to 2 years.

Re: Tech Interview Handbook

#318

Post by nunb »

closeparen wrote: post #134
seventhtiger wrote: post #89

Earlier quoted context omitted.

Admission at Georgia Tech has spoken on this online. Per their analysis, they can definitely differentiate the top 30% of applicants from the rest and it makes a difference in performance. Within the 30% they have found no differentiator that significantly impacts their academic performance. So they have a full 30% of their applicants qualified to be there but they have to narrow it to 1%. Whatever method they choose…

Every person you hire is technically competent? So every system you build on or integrate with is high quality? Every architecture choice you have to live with is a good one? Every bug report you file is investigated well? Every coworker's code is a joy to read, and their reviews of your code and designs are insightful? Every person on your team is capable of the most difficult work in its pipeline? Every system you…

It's actually that you aren't qualified to say who's competent. The CEO can't hire a tech competent CTO and that multiplies down the line. In the absence of a tech savvy judiciousness they fall back on fluff like "devops culture fit" and "growing the team" to be like "silicon valley culture". Hundreds of recruiters will sell them that story (those recruiters are really in the PR industry) and you end up with incompetence all around except everyone has become good at selling their own incompetence as the highest form of tech savvy. Most prevalent in older enterprisey firms.

Re: Tech Interview Handbook

#319

Post by james_s_tayler »

rhizome wrote: post #151
jishnum wrote: post #111

Earlier quoted context omitted.

I'd argue that this is a resume overindexed on getting past recruiting filters looking for specific JavaScript libraries or UNIX commands. Even the recruiters action may not be necessarily bad - startups with a decided tech stack might decide they are not able to provide the time for a new hire to ramp up. Effectively you penalise not catering the candidate resume to what you are looking for or deem important.

Does anybody even know anything about these resume filters? They seem legendary, or I'd think there would be a best practice by now.

The trick is there are multiple resume filters.

One will filter you out for having too many keywords. One will filter you out for not having enough keywords. One will filter you out for including a picture. One will filter you out for not including a picture. One will ... ad infinitum

Your resume is being evaluated by different filters constantly. Different filters filter different things. There is no "right" answer. There are only answers you will or won't be filtered out for depending on which filter is being applied.

Which filter is being applied?

It's random.

Hiring is essentially random.

Re: Tech Interview Handbook

#320

Post by alchemism »

fogetti wrote: post #211
username90 wrote: post #204

Earlier quoted context omitted.

MBA holders is a bad example since many of them happily work many hours of overtime, so I am pretty sure that they work more hours than software engineers even if you include the time it takes to study for interviews. > It turns out that the median number of hours racked up by an MBA in his or her first year of employment is a whopping 54 hours a week https://www.forbes.com/sites/poetsandquants/2018/03/06/the-6...

I am confused. Why do you think software engineers stop working as much as MBAs when they land a job? That's when they have to start studying even more beside working. 54 sounds about average for an engineer anyway. In Germany for example it's not rare to have 9 hour working days, with 30 to 60 minute lunch breaks in between. If it's so then basically one week comes to about 45 hours / week. If you study 2 hours a da…

Or maybe you put that time into raising your family, or otherwise being a well-rounded individual. It’s easy to do, if one assumes that the employer pays for the time required to keep an employee’s skills current.
Post reply on HN