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…
Tech Interview Handbook
71–80 of 344 posts
Re: Tech Interview Handbook
#72I don't think I've ever seen anyone explicitly recommend against using a custom domain for email.
Re: Tech Interview Handbook
#73Having 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…
Re: Tech Interview Handbook
#74Some 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?
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
#75Given 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…
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
#76Earlier 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…
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
#77Earlier 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?
Stick to the basics and a trial period.
Re: Tech Interview Handbook
#78Earlier 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.
Re: Tech Interview Handbook
#79Earlier 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.
Re: Tech Interview Handbook
#80I 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’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.