Live data from Hacker News

Tech Interview Handbook

yangshun.github.io

71–80 of 344 posts

Re: Tech Interview Handbook

#71

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…

[deleted]

Re: Tech Interview Handbook

#72
> Get a proper email account with ideally your first name and last name, eg. "john.doe@gmail.com" instead of "angrybirds88@gmail.com"... Avoid emails like "me@christi.na" or "admin@[mycooldomain].com" -- because it is very prone to typo errors.

I don't think I've ever seen anyone explicitly recommend against using a custom domain for email.

Re: Tech Interview Handbook

#73

Having hired dozens of devs, I can confidently say there is absolutely 0% chance to consistently successfully identify good developers in any reasonable amount of interviewing / assessment time period. The best way is someone brings in an existing code portfolio and discusses it. The second best way is someone completes multiple design and development exercises of varying complexity, constraints, and use cases. The t…

How often are you hiring people whose professional work is open source? How often are you hiring people for roles where their professional work will be open source?

Re: Tech Interview Handbook

#74
post #9

Some of these "questions for the interviewer" are very good. In particular I like some of the "tell me the negatives" ones: > What is the most costly technical decision made early on that the company is living with now? > What is something you wish were different about your job? > What has been the worst technical blunder that has happened in the recent past?

These are good questions, I like how they are phrased so concretely instead just asking “do you have a lot of tech debt?” They’re interesting for getting to know the team and getting a piece of insight you usually wouldn’t have until a few weeks into the job.

But I would be careful how you interpret these. In fact I would almost factor in these answers in the opposite way of what I think you intended. The company that admits to the worst technical issues is at least honest and self reflective. The company that doesn’t admit to any serious issues might be just as bad or worse, but their strategy is to tell employees to lie about it rather than be open to addressing it.

Re: Tech Interview Handbook

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

I mean it's all a game as much as it sucks. One of my best friends in high school was a salutatorian because the school didn't wait grade. She took zero AP classes and very few honors classes. She knew what she was doing.

Friends in college took less challenging majors to boost GPA for med school (business admin, environmental policy, etc) to boost grades and there core classes were easy so it gave them more time to focus on med school pre-reqs.

It has been and always will be a game. Few things in this world come down to meritocracy because the way we socialize and the way we interview does not beget that in absolute terms.

Tech did a better-than-most job as a meritocracy for while, but I believe those days are done. Most areas f tech are too mainstream with too much obvious money at stake.

Re: Tech Interview Handbook

#76
post #45
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…

No, a fizzbuzz test is entirely about whether somebody can do it. That's the definition of a fizzbuzz test. When you hear others talking about a fizzbuzz test, they're not talking about the specific algorithm, they're specifically talking about a simple single-function problem that should take no more than 5 or 10 minutes.

If you're dealing with user input or linting, then that's not a fizzbuzz test. I'm not doubting that maybe somebody asked you to do something larger than that including the fizzbuzz problem, I'm just saying that nobody else here is talking about take-home problems when we talk about fizzbuzz.

Re: Tech Interview Handbook

#77
post #58
post #44

Earlier quoted context omitted.

I never had any technical interview prep when I started. I could code just fine. I demonstrated that at my other jobs and in school well enough. Then I started interviewing for SF positions that did these interviews. I froze up. I couldn't talk and think at the same time. I didn't have the skillset for doing this in a very intense scenario. In my case, I was homeless and needed a job ASAP. Every interview felt like l…

This is a really interesting observation, thank you. Is there anything they could have done differently to make the situation easier? (I would guess perhaps giving you more notice about language requirements?). Or is there a different interview format that you feel would have worked better?

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.

Re: Tech Interview Handbook

#78
post #64

Earlier quoted context omitted.

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.

Please do start? I'm kind of curious what you'll say because it's not at all obvious to me that it would be a bad idea.

Re: Tech Interview Handbook

#79
post #58

Earlier quoted context omitted.

This is a really interesting observation, thank you. Is there anything they could have done differently to make the situation easier? (I would guess perhaps giving you more notice about language requirements?). Or is there a different interview format that you feel would have worked better?

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?

Re: Tech Interview Handbook

#80

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 agree a code test is necessary. I’ve seen several panels neglect to do a code test, the candidate was hired, then within a month fired because it was clear they couldn’t do anything (other than, well, argue).

I’ve been in a panel where I was the only person who asked a code question, the candidate flunked, and then the VP of Engineering went over my complaints and hired the guy anyways. He had been a Professor of Software Engineering and had a graduate degree from Princeton. Within three weeks, the VP of Engineering had to fire him because he couldn’t make it through a simple code review.

BUT the extremely negative sentiment here towards the technical interview process is very well-deserved.

Assessment of code (and the selection of problems) is most often no less subjective than any non-technical assessment. Sometimes the interviewer doing the grading is flat out wrong. Several times I’ve been asked the famous “given an array of stock prices, find the optimal buy and sell indices for the biggest profit.” One interviewer was not aware of the linear time solution to this problem, and didn’t believe me when I wrote and tried to explain it to him.

But sometimes, the interviewer doesn’t even want you to do well. Once time I was interviewing with an injury that prevented me from typing efficiently. I had a doctor’s note and the injury was quite conspicuous. Nevertheless, three start-ups made me solve problems by typing on a keyboard, which guaranteed an excessively long completion time. Those companies held those results against me. (An it’s not like there is anybody to hold those panels accountable).

And then there are those who just don’t care. I had a phone interview with Airbnb that was literally as bad as the stories on Glassdoor: the guy answered the phone in a noisy office (not a conference room), gave no introduction, then simply stated the problem and dumped me into Coderpad. I literally thought it was a prank, since I had met with people at Airbnb face-to-face prior to the call. But the recruiters confirmed the guy was a real employee.

The root problem here is there is no feedback loop back to interviewers. The candidates get “feedback,” but people asking code questions, especially new grads, typically get zero assessment on how well they are doing as interviewers. What’s worse is that recruiters and hiring managers both have incentives to deprive ICs of such feedback, since it would invariably make ICs more aware of opportunities outside the company.

Until the incentive structure of technical interviewing changes dramatically, we’re stuck with Leetcode and hope for the best. People like Gayle Laakmann are helpful (especially when Facebook gives candidates a live hour-long session with her for free), but these people are ultimately invested in their own income and not the task of fundamentally fixing this broken process.

Post reply on HN