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

281–290 of 344 posts

Re: Tech Interview Handbook

#281

Post by wcunning »

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'm getting up the gumption to look for a different, hopefully better job in the nearer future (in automotive control software, looking to move to AV), and I had a bit of a revelation when talking to a friend of mine who does interviewing. I cannot talk about the things in my current job that would make me a good hire for the things I want to move into. It's all hunting down an obscure bug buried in layers of technical debt and overly complicated standards, but giving any depth beyond that bare platitude requires going into things that my NDA covers. I even work in driver assist technologies, but I can't go into detail about that because I'm working on unreleased, unannounced features. That means that the only thing left is side projects or whiteboard interviews. To be fair, this is at least partly an industry problem due to long product development cycles and a culture of secrecy, but it makes a lot of the better solutions to interviewing unworkable and causes companies to drop back to whiteboard interviews. And as a candidate, my personal maximizing function is to hit the books and be ready for curly braces and logic puzzles. Sometimes there really isn't a better way.

Re: Tech Interview Handbook

#282

Post by Jach »

johan_larson wrote: post #121
maehwasu wrote: post #86

Earlier quoted context omitted.

Having a way that coders can avoid doing these types of coding problems over and over seems like a positive. Companies that aren’t interested in the approach could not use it. Most companies today are already using a version of this that is way less respectful of applicant time. But you’re speechless, so I guess there are strong points on both sides.

This is my thinking too. Having to prove, over and over, that I understand how linked lists and binary search trees work is just tiresome. Doing it once and then being able to refer to a trusted credential that certifies it would be a blessing. I understand nobody is going to hire on the strength of one exam. Every job is a little bit different and some of them call for particular skill sets. That's fine. By all mean…

It would be a blessing, but I don't have any reason to expect its coming. I mean, I proved I understand how linked lists worked in my freshman year (well arguably earlier in HS CS classes) along with many other people who were enrolled in a CS or related (mine was CE) degree. Why can't I just point to my degree and never have to prove myself on that stuff again?

The issue is trust. No one trusts degrees anymore, and for very good reasons. I don't see any way for something else that relies on the same sort of credentialism to avoid corruption and lose trust unless it's measuring fairly static and not-very-gameable attributes like height or IQ (see: Wonderlic for basically IQ testing in a way that complies with laws against IQ testing..).

Where this gets particularly ugly is that even though no one trusts degrees anymore, they're still very popular, and some employers still require them anyway (or at least make it very hard to even get an interview without one). If a new "trusted credential" gets popular enough, or even a set of them, they'll eventually lose their trust, but because at some point they were popular people will still sink time into them and so the time cost we're inflicting increases when it'd be better to just get serious about hiring and tell smart and interested 18 year olds to just come start working already.

Re: Tech Interview Handbook

#283

Post by TrackerFF »

_hardwaregeek wrote: post #34
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…

Y'know, as someone who went to a very competitive public school, there were a particular brand of driven, studious kids who knew exactly how to paint along the lines, play the game, and get into the college of their choice. They understood the precise combo of grades, extracurriculars and essays to get into a "good" school. I definitely see some of those kids doing the same tactics to get into a "good" company. The s…

That's how most kids get into prestigious universities. Rarely, if ever, do kids just "stumble" into HYPS or Oxbridge, out of sheer intellectual power and luck.

If you want to get into those schools, you gotta know how to game works, and practice specifically for that match.

I went to a school like that, and the majority of my classmates were from upper-middle to upper class families that had poured money into their education since they were young, with the specific goal of getting them into top schools.

Yeah, that's unfortunately the thing, when you start throwing in a ton of different criteria / measurements. The people that know how the system works, will study to maximize those points.

My honest opinion is that you kinda of end up with smart people that are very good at test-taking, but may not be the best people when presented a set of problems with non-obvious solutions, or any guides or road maps on how to solve the problems.

Re: Tech Interview Handbook

#284

Post by mylons »

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…

except there is no standardization at all.

Re: Tech Interview Handbook

#285

Post by shivawu »

matz1 wrote: post #228
yumraj wrote: post #100

Earlier quoted context omitted.

I'll try - a few thoughts: Software engineering is part knowledge and part application of knowledge (problem solving) and part ability to acquire and apply new knowledge. We remain current in our jobs and roles by making sure we're constantly learning. Interviews should be part testing of knowledge, but a lot more discussions to evaluate problem solving and ability to acquire & apply knowledge. Also, knowledge in man…

>I may learn react via books/tutorials, get a great score in the test, never use it and/or forget it by the time Thats one of the point of programming test, there are tons of framework/language out there, every company might use different language/framework, a standardize test streamline the interview process, make it easy for you to interview in many different company. >Given that it's not clear as to what problem s…

> Thats one of the point of programming test, there are tons of framework/language out there, every company might use different language/framework, a standardize test streamline the interview process, make it easy for you to interview in many different company.

As you said, they're very different. The thing is it might not be possible, as the technology develops and diverges, to have this one standardized test.

> It very least shows that you are care enough for the job that you willing to prepare time to prepare for it.

It applies to grinding leetcode as well, so not really related here.

> Sure, life is never fair, but for those who are worse test takers then it just mean you have spend more time and effort to practice it.

It can't be like, because some people are just not good at being tested, sorry, we don't want to work with you. They're of different purpose.

Re: Tech Interview Handbook

#286

Post by shivawu »

Jach wrote: post #282
johan_larson wrote: post #121

Earlier quoted context omitted.

This is my thinking too. Having to prove, over and over, that I understand how linked lists and binary search trees work is just tiresome. Doing it once and then being able to refer to a trusted credential that certifies it would be a blessing. I understand nobody is going to hire on the strength of one exam. Every job is a little bit different and some of them call for particular skill sets. That's fine. By all mean…

It would be a blessing, but I don't have any reason to expect its coming. I mean, I proved I understand how linked lists worked in my freshman year (well arguably earlier in HS CS classes) along with many other people who were enrolled in a CS or related (mine was CE) degree. Why can't I just point to my degree and never have to prove myself on that stuff again? The issue is trust. No one trusts degrees anymore, and…

I like your thinking around the trust issue.

It's a totally different matter between hiring new grads, and non new-grades. cspa.io seems only to target new-grads. But as you said, it's replacing one degree system with another similar, but maybe evenly good/bad system.

Re: Tech Interview Handbook

#287

Post by mixmastamyk »

new299 wrote: post #79
mixmastamyk wrote: post #77

Earlier quoted context omitted.

Not really, innovative thought can’t be done with a gun to your head. Perhaps if you’d written this code multiple times over the years and had it memorized. But, that won’t help with random problem #2. Stick to the basics and a trial period.

Is reversing a string not already "the basics"? What are you suggesting should be covered in an interview/screen prior to a trial period?

Your question was not reversing a string. You also mentioned fizzbuzz.

Re: Tech Interview Handbook

#288

Post by davidjnelson »

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…

What works for me is to consider what work the engineer will be doing, and ask them to write code to prove they can do it.

For instance, a front end engineer can be expected to be able to write a to do list or similar app in a framework (ideally the one your team uses, but not a hard no hire if not) app with minimal googling (although that’s fine as long as not excessive) in ~45 minutes.

Then you have to look at what level of experience they have. Less experience requires more mentoring generally, which may be fine depending on how much time your team budgets for that work.

Lastly, measure their body language and tone of voice to check for red flags pointing to difficult communication styles or people who treat others poorly.

If all three match, hire!

Re: Tech Interview Handbook

#289

Post by closeparen »

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…

>If the person described in this resume fits the background experience the role needs, you get an interview.

This is one way the current status quo might be better than the past: you don't get pigeonholed so much by your past experience into being a "fit" only for similar roles. Sometimes the hiring manager is really looking for a specialist, but in general, we don't care what industry you were in or what tools you were using, as long as you can prove you're smart. Some of the most impressive people we have working on Go microservices were enterprise C# developers before.

Re: Tech Interview Handbook

#290

Post by closeparen »

triceratops wrote: post #133
_hardwaregeek wrote: post #61

Earlier quoted context omitted.

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.

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.
Post reply on HN