Live data from Hacker News

Tech Interview Handbook

yangshun.github.io

321–330 of 344 posts

Re: Tech Interview Handbook

#321
post #54

Earlier quoted context omitted.

I guess it depends how you use it. I started hearing about FizzBuzz in the context of "why can't programmers program" [1]. I.e. that many interview candidates can't solve this problem. It's also my experience interviewing programmers (outside SF) that most candidates can't solve simple FizzBuzz style questions. As a take-home test, I agree I can't really see the value in it. [1] https://blog.codinghorror.com/why-cant…

Back when I did phone screens, I went even simpler: Write a program that counts from one to ten, printing each number out followed by your name followed by a newline. Do not print the line for number 4. It’s astounding how many programming candidates can’t work their way through this.

Also astounding is the number of programmers who program over the phone. Approximately zero.

Re: Tech Interview Handbook

#322

Earlier quoted context omitted.

Can you elaborate? What did he do or say that made you think he could do the job even though it looks like he wasn't able to work with other people code?

Not OP, but there's a group of people who have essentially a good manager's understanding of a project. They understand the trade-offs, they can talk intelligently about technical choices and architecture, and to some degree can even talk about individual modules and classes and language choices. But they blank at code and struggle with the basics. They get lost for hours at the most trivial bugs. It's weird, but it'…

I’ve known many smart IT folks that say they don’t or won’t code more than a batch script.

Re: Tech Interview Handbook

#323

Earlier quoted context omitted.

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. Sure it is. People on our team need to take time to onboard the new hire. That's good and expected. The new hire will work slower and that's ok; they will need extra help, time to learn the codebases, etc. After a couple of months, a particular new hire did not work out. Time had to be taken to document reasons, meet with HR, meeting to talk about expectations, etc. In the end, the new hire is…

A real cost that can be mitigated by breaking work into smaller chunks at first, and firing quickly.

Re: Tech Interview Handbook

#325

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 technic…

“I’m under NDA” is a valid response. Have some hobby project or floss bug fix on github if there is time to fill.

Re: Tech Interview Handbook

#326
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…

You're absolutely right, unfortunately here in the Bay area it's those kids winging it and getting in.

Re: Tech Interview Handbook

#327
post #84

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 absolutely agree, as an interviewee that's what I focus on, and you're right you can catch it if someone is bullshitting.

Re: Tech Interview Handbook

#328

Earlier quoted context omitted.

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…

Part of the problem is how little time one has to prepare for college. If we encouraged people to apply to college after a few years of adult life, I have a feeling the playing field would be a little better. But instead we expect kids to gain the credentials of much older adults while going to school and getting fantastic grades. Unless you understand the game going in, it's too easy to slip up and fall behind. Even then, you don't have time for mental health or sleep.

Re: Tech Interview Handbook

#329
I'm going a different route with interviews and wonder if anyone has input... I'm a senior backend dev with 10+ years of experience. Breadth of projects, masters in CS, open source work, team lead, top contributor, great references, etc. But I cant pass a coding interview, because I kinda freeze up during algorithm whiteboarding questions. I get requests for interviews daily and have been considering starting with a cover letter that basically says I'm not good at coding interviews, but love to talk tech (and see other positives above). Could I do a homework assignment or anything else to show my worth?

Has anyone had any luck with an approach like this?

Re: Tech Interview Handbook

#330
post #152

Earlier quoted context omitted.

Because these problems encourages you to write unreadable code. It makes sense when you write it, because you can fit it in your head, but you never have to revisit it after having passed the problem. It encourages one letter variable names and other quick hacks in the name of speed. They work against creating readable, understandable and debuggable code which is much more important in general than being able to solv…

> I would rather hire someone who can write clean and simple code and teach them how to solve these problems than the reverse. Why? Teaching people to write readable code happens automatically during code reviews, teaching people how to think is a lot harder.

Because producing simple and good code is much more important.

It's quite condescending and narrow-minded to say that solving algorithmic problems is thinking, but writing clean and simple code isn't.

Writing readable code is much more than just formatting code and using decent variable names. It's about simplifying your design just enough. Code reviews is not enough to teach someone this.

Post reply on HN