Ask HN: Why are Silicon Valley interviews such a drag now?
My first friend is almost 20 years my junior, but a fantastic coder. He is someone that every company would want. He's smart, curious, has initiative, and has a lot of wisdom behind the way he codes despite his youth. He's fluent in Java, Scala, Python and has built everything from simple web services to entire parsing engines and he does it because he's genuinely interested in the work he does.
My other friend is 10 years my junior, but also great. He's an official Apache committer, and has worked on some really great projects for some well-known companies. He also has worked on a lot of side projects that got picked up by his employers in various forms and he works his butt off every day.
My two friends are people that any company would be lucky to have. But all three of us are very reluctant to start interviewing because we all know how much interviewing really really SUCKS. Basically we are forced to write whiteboard code for 4-5 hours on topics that we may or may not know. If we don't know it, we're fucked and we might as well give up because everyone appears to want perfection. But the range of questions we can be asked on an interview is so wide, you can't expect someone to know EVERYTHING.
It seems to me that interviewing in Silicon Valley is really broken if my friends are reluctant to start interviewing, despite how great they are and how much of an asset they would be to ANY company.
Is there a site besides glassdoor that details or rates a company's interview process? It would be sad if we all end up choosing companies based on their interview process, but it's a lot better than wasting our time and PTO days going for interviews and then getting blown out of the water because one interviewer wants us to code a particular dynamic programming question the way they are picturing in their head.
113 comments
[ 2.9 ms ] story [ 129 ms ] thread"reluctant to start interviewing" based off of stereotypes? Am I not understanding this?
It seems like maybe they've spent too much time on HN and Reddit reading about interviewing without doing it. ;)
Then I interviewed at a bunch of places. Most of them were fairly small and they universally used whiteboard coding, except when I interviewed for a specific team at $OTHER_BIG_COMPANY and didn't touch a whiteboard at all. I expect that if I wasn't interviewing for a specific team, I'd have had to use the whiteboard.
So yeah, sadly IME whiteboard coding is alive and well.
Why is it a secret?
That's true, but... it's pretty sad that it's true. There's so much to be learned from good interviewing practices.
I've personally interviewed many dozens of times over the last 20 years I've been in Silicon Valley. The expectations from interviews have definitely changed, especially after Google (I interviewed their twice and never made it past the hiring committee). At one well-known company, I went through 15 whiteboard interviews (3 different days x 5 interviews per day) and finally got the job. I'm not sure why I stuck with it, but I did.
If the nature of interviews have changed over the last year, I'll be thrilled, but I doubt it based on the reports I've heard from other friends of mine that have interviewed over the last few months.
A few days before I moved to Portland, I applied for some iOS coding jobs from San Jose. I scored two interviews, on the day after I arrived, the other a few days later.
"iOS" coding, mind you.
At that second company, I interviewed for four hours with six people. There were no whiteboard questions, it was all talk. My last interviewer was the president of the company. He asked me what an "activity" was.
I had no clue. Quite unwisely, I pulled my answer right out of my ass.
I looked it up later: iOS Apps don't have activities, that's an Android concept.
I am dead certain that I didn't get that job, because I didn't know about an API that's only used for a platform that I would not be working with.
If you want to test someone on whether they can admit they don't know, just ask increasingly tough questions and see how they handle it.
Chuck Hickey, the president, asked me to write down the fastest possible implementation of strcpy(). Honestly, I had no clue. I wound up with a six dollar per hour telephone technical support job.
This despite that at my previous job, I designed then - in one long night - flawlessly implemented the Common LISP symbol scoping rules, as specified in Guy Steele's book of the same name.
This leads me to assert that it would be more productive to challenge applicants, during interviews, to write some of the same kind of code that their resumes claim they have previously written. At that LISP job, we were not concerned with performance, rather we were concerned with complying to the Common LISP specification.
My resume doesn't make the claim that I studied computer science. It is quite clear that I have a BA in Physics from UC Santa Cruz, that I majored at first in Astronomy then changed to Physics at Caltech, and that I attended grad school in Physics at UCSC.
Despite that it is quite common for interviewers to ask me questions that only those with graduate CS degrees would have any clue about.
This finally lead me to pointing out, well before the interview, that I regard myself as a Software Engineer and not a Computer Scientist.
The two, while conceptually related, in reality are quite different. Consider that a mathematician can derive the catenary curve by solving a differential equation, while a civil engineer is the reason that the Golden Gate Bridge isn't likely to collapse anytime soon.
If I am interviewing I don't do that without explaining that I don't know exactly what they mean, and if I have some idea of what they might mean I say that. Otherwise I say I'm sorry I don't know, and list it as something to ask about at the end of the interview (typically when you're given a chance to ask the interviewer some questions).
Sorry I don't follow your question.
Then either the interviewers "know" the wrong answers, or feel so threatened that you're "not a culture fit."
That said, twice in the past few years I've been in the situation where the interviewer was wrong (recently like over a dozen times in the interview on different topics!). Most of the time I just brush it off, but I'm not the type to let things slide on technical issues with black and white answers.
So sometimes if pushed i will try to gently backup my statement with concrete examples (goggleable if you will). But, still if you piss someone off by telling them to google it, you definitely get the "culture fit" answer.
So, i'm not sure how to crack that nut.
Maybe the best answer is you probably are not going to fit in, and terminating it early is a good idea. Its like the crazy member of the opposite sex who breaks up with you, and all you feel is relief.
BTW: When I got the culture fit answer recently, I almost sent the hiring manager the "your techie is presenting himself as an expert in the following areas critical to your success but he thinks a,b,c,d. These aren't even areas subject to disagreement by knowledgeable people. Here are the actual answers complete with hard references you can verify." But when I cooled down, I figured the best response was the pleasant thank you for your time answer.
You can also ask about what the on-site interviews are like before you commit to them. If they mention white-board programming, just pass on them. I am super against horrible interview practices (I'm all for phone screens being you and the interviewer SSH'd and in the same screen session together), but you can find companies that have good ones, and part of that task lies on your shoulders.
Really not appropriate here.
Really not appropriate here.
If I've got 8 hours to spend I'd much rather contribute it to something that someone else will actually benefit from.
Option A) Spend anywhere from 2 to 12 hours interviewing for a position with little to no break. While being asked to solve problems, that may very well actually be unsolvable, under the pressure of rotating team of people. And for bonus if you suffer from any sort of test taking anxiety in school you'll get to feel the blood drain from your prefrontal cortex, as your fight or flight instincts kick just enough to make sure that doing high cognitive work like programming is next to impossible.
Option B) Spend a few hours solving a hopefully interesting programming challenge at home where you're probably not wearing pants.
Anyway, over the past couple years I've steadily moved into the take home test camp. These can be tweaked such that its apparent if someone tried to google an answer and use it.
But that said, I'm not sure I want to be implementing a "challenging" project for a job that I might never get. How much time do you think someone should be expected to put into a project for a job they might not get. How about if they are interviewing at a half dozen places?
- They are aimed at identifying smart people who know the basics of coding and algorithms. They are intentionally not domain specific. In my experience, smart people can pick up all the other details over time. I've worked with many people who switched languages and within a few months were (for the purposes of their job) as good as someone with years of experience. Similarly, version control, testing etc. are things you can learn on the job.
- They have worked for major companies. Look at the share price of Google and Facebook over time, or the general feeling that they are successful in their goal of hiring the best people.
- They are fast and scalable. They only take as long as the interview, and they scale well because it's easy to compare the notes of different interviewers. The process takes about 5 hours for the interviewee, and about 10 hours combined for the interviewers.
Also your comparison with share price is not necessarily accurate - #1 company in the past 100 years is Exxon (profit per 100 years). I would argue that they manage their existing employees better than their competitors and fire the weak ones. In 50 years I'll bet no one knows facebook or google - just like no one knows DEC or any other tech company from the 70s except IBM and Oracle. Currently they just have the Zeitgeist going for them.
They (er, we) are still hiring: https://www.instacart.com/jobs/engineering
1. Companies think they are hot shit.
2. The interviewers are all pretty junior and actually have no idea what they are looking for, so instead they try to grill everyone in some perceived gauntlet.
The reality is that companies need experienced people (of all ages). And that the gauntlet exercise is supposed to do 2 things - first of all, demonstrate that people know a bit about some kind of software development / CS experience. Second of all, and this one is missed a lot, its a chance to see what someone's personality is like trying to solve a problem.
Experienced interviewers know that its not about trying to throw problems at people until you exhaust them, its about determining if you want to be on the team with someone when a difficult problem arises (and uses as a proxy for this, how do they react to solving a problem right now in front of you).
Companies are about culture - there are still companies out there that do have cool engineering cultures (and some of them are hot shit).
It is sad some pedantic people can determine your success on a one off trick question and whiteboard exercise interview judgement like a rogue war tribunal rather than your work.
Sometimes, the goal of an interview is to get you to think about something you don't know. If you knew every answer to every interview question perfectly, what does the interviewer learn? It's quite enlightening to get out of that comfort zone and see whether someone pulls an answer out of their backside, honestly says that they don't know, or somewhere in between. I'm not saying all interviews should be like this for everyone, and I think interviewers should be very much aware if that's what they're doing -- which I think is less the case ("oh, the candidate didn't use a linked list but solved the problem some other way? 0 points!").
As you have pointed out the dynamic of interviews sucks. A potential employer will be seeing dozens of people for a position and comparing you to all of them. You will be talking on a topic decided by the employer which you may or may not know anything about.
Giving technical presentations inverts this dynamic beautifully. Instead of one position and many candidates, there is one of you and potentially dozens of people in the room looking to hire. Instead of doing white board problems in a domain you may not know about, you will be talking on a topic that you KNOW MORE ABOUT than anybody else in the room! Instead of speaking off the cuff in an interview, you can polish your presentation for weeks in advance.
I am a freelancer. Every time I have done a technical presentation at a users group I have picked up at least one job out of it. Many of the people at the users group are looking for employees. They are always disappointed to find out I'm not looking for a full time position.
Case in point: I recently emailed a simple question to the Magic (getmagic.com) folks. I asked why they didn't make the short code on their home page (which used to be a 10 digit phone number) a clickable SMS link. It seems obvious right? They are asking people to send them an SMS. Why make people either memorize/type or copy/paste? But not only did they not think of it, they didn't respond to my email and haven't implemented it. These guys basically got a check for $12M at a $40M valuation after 1 weekend of buzz and couldn't figure this out on their own - and either could the VC's that wrote them the check apparently (and they're in charge of billions of dollars).
So walking into these interviews (especially at recent startups), understand that if you have a bad interview experience, then the people that are already there probably aren't very good at what they do. Bad interviews tend to be conducted by bad managers/coders that are suffering from extreme bouts of justifiable impostor syndrome. If you are not hired after a bad interview experience, it's probably a good thing, because you wouldn't want to work everyday with the people that designed that experience in the first place.
Have you interviewed much recently, or are you going on what you hear about bad things in the interview process? (The bad stuff tends to get more mentions.)
It might not be as bad as you think. Yes, some amount of whiteboard work is common. But it shouldn't be about "topics you may or may not know" - that sounds bizarre to me. You should be tested on a language you know, and on a problem that a reasonable person would be able to solve. Also, the focus is often on how you approach the problem, not if you write up a perfect solution or not.
Overall, what you describe sounds like a horror story ("one interviewer wants us to code a particular dynamic programming question the way they are picturing in their head"). I don't think that's as common as you appear to think.
It sounds like you are reluctant to even start interviewing. Why not try, and see how it goes?
This is a common misconception. Unfortunately, most (read 99%) interviewers expect you to come up with exactly the same solution they have in mind (or in paper/screen in front of them). Even if your solution is correct but different, as soon as you start to diverge from their solution, you're red-flagged.
I interviewed a bunch, but not for a few years. More recently, I've been on the other side of things. In all my experience: yes, some people expect a very specific answer from you, but not most.
Most people look at how you approach the problem, how you solve it, and what questions you ask about it if you need any clarifications. You can often tell someone is a good programmer even if they don't fully solve a problem, or if they happen to pick an approach that doesn't work out.
Again, that's my personal experience and knowledge, so I can't be sure how common it is.
PS: I interviewed at mid-sized startup companies, all 100-300 people.
If you go through a 3 person loop and get 2 problems right and 1 wrong, you might get an offer, but I guarantee that the voting would be two "hire" votes from the questions you aced, and a "no-hire" vote from the one you failed.
There are a couple of reasons for this. The most obvious is that, given two candidates, the better choice will (at least appear) to be the candidate who got the most questions right.
The more common scenario that I have seen is that engineers simply work backwards. If you got the solution wrong (or didn't finish) their thinking will go something like: they got it wrong -> they went down the wrong path since they chose a hashmap instead of a tree -> they are weak in data structures -> no hire
I am at one of the bigger tech companies, and it really is a roll of the dice on if you get a question on a topic you have studied. Especially if you have been out of school for awhile.
The worst part is that bigger tech companies force hiring on the engineers. Hiring candidates becomes part of your own career advancement. If it is a big company, you will go to a day of training and suddenly be a professional interviewer. It is even worse since my opinion (that this system is awful) seems to be the minority. All of my colleagues think they are great at hiring, pontificate over lunch on what makes a good candidate, and discuss their favorite questions (well, their favorite questions from the standard set of questions from the company bank. This is science here, obviously we use standardized questions.)
Of course, if you fail in the interview, you can always come back. It's not like I've ever heard a colleague say, "sigh I am not looking forward to this interview; We've already turned them down once."
http://matasano.com/careers/
Feel free to drop me a line if you (or anyone else) has questions - I'm andrew AT matasano.com
1. We don't expect applicants to be amazing at this already. Having a background in security is good, of course, but not necessary. As a data point: in the office I work out of, we have someone who used to work in a bakery, someone who worked for an insurance company, and several people who had never done security before applying to Matasano. It's my opinion that you generally learn more "on the job", as it were, than you would preparing for an interview anyway. @tptacek's post at [0] is a good example of the type of people we have working for us.
2. We generally send candidates resources to help them prepare - I believe a couple recent applicants got free copies of "The Web Application Hacker's Handbook" [1].
[0]: https://news.ycombinator.com/item?id=8395627
[1]: http://www.amazon.com/The-Web-Application-Hackers-Handbook/d...
Why would I spend some time learning the security niche just for one interview? I could instead work on Android development, Python, Scala, or a whole bunch of other things. Those would be useful for many jobs, and not just 1-3 employers.
Why is putting in a lot of time researching security for your interview a better use of my time than learning more widely applicable skills?
What if I put in all the time, pass the pre-screening, and then when I meet you, it turns out you aren't the type of people I'd want to work with?
I disagree, but accept that this depends largely on the desired outcomes. If the candidates goal is to spray-and-pray by applying at dozens of companies and hoping one makes them an offer they can accept, I'll grant that requiring more time may be a hindrance. If, however, the candidate's goal is to learn something, improve their skills, and demonstrate to the potential employer that they're capable of doing this on a short time cycle, they may welcome the opportunity, and many have.
> Why would I spend some time learning the security niche just for one interview? I could instead work on Android development, Python, Scala, or a whole bunch of other things. Those would be useful for many jobs, and not just 1-3 employers.
Because you want to work in security generally, and for us specifically? I fully accept that not everyone shares career goals which align with our needs, and encourage them to pursue other avenues. If you're dream in life is to be a broadway actor, we're unlikely to be able to help. That doesn't make this goal less important to you or valuable to the world at large, it just differs from what we do and offer.
That said, if you think that security skills (and web app security specifically, which is the typical path for those learning for the interview) are relevant only to "1-3 employers" I fear you drastically underestimate the size of the market both within security consultancies and enterprises that have a security team (or just appreciate security-minded developers).
> Why is putting in a lot of time researching security for your interview a better use of my time than learning more widely applicable skills?
It may not be. There's a lot of paths to self improvement, and their suitability to a specific individual will vary, depending on that individuals goals, desires, and learning style. I don't think anyone is trying to prescribe 'the one true path to self improvement' but rather one that we've found to work, and one that we help our candidates advanced down.
> What if I put in all the time, pass the pre-screening, and then when I meet you, it turns out you aren't the type of people I'd want to work with?
Then we shake hands and each go our own ways, hopefully having learned something about each other and ourselves in the process. Maybe we've made contacts that'll be mutually valuable in the future whether it be for future employment, a business relationship, or simply someone to chat with at some developer meetup, conference, etc. and bounce ideas off of. Choosing not to continue a relationship is a perfectly viable outcome of any interview process.
Otherwise, you end up interviewing at places were recruiters are just trying to get another body in the door and half of them are not prepared.
I was very skeptical but it got the job done.
http://join.hired.com/x/XfELvW if you want to toss me a referral but honestly, it doesn't matter to me either way. The quick decisive moment is the hard part but Hired.com really does take care of the rest.
Also Mattermark is hiring and I would encourage anyone interested in full stack or dev ops to apply: http://mattermark.com/jobs/ (other business roles are on there too)
Why Hired.com is good: if you are a bad negotiator, you'll learn very quickly that you need to filter out jobs early on based on salary expectation. Nobody talks to engineers/geeks about that. But once you go through the hired.com process, you realize that hey, it's an open field -- you can establish up front what your criteria are in terms of compensation and discuss that early in the potential interview process. Because time is money, hiring is complicated and compensation is all over the place. You are the best judge of your value. It's complicated. But you are also the best judge of what you'll accept in terms of tradeoffs (cash vs equity).
Everyone single person who contacted me via my Hired.com profile was a founder (or a recruiter pretending to be the founder). Either way, I got a great summary of what they were looking for along with up front knowledge of the compensation (so I knew we were on the same page). I got 11 or 12 offers and I did 4 on-site interviews. I ended up at a company that I am very happy with.
So I recommend it to those that don't have a perfect network. With a great or perfect network, you can likely do better. But like online dating, Hired.com exposes you in a way that optimizes presenting your value to potential employers. I think that most of us engineers do not have a perfect network and/or do not know how to leverage that network so it is a huge win.
Perhaps in other words, you are guaranteed a few bad interviews. Interviewing is very random. I have sat on both sides of the table. I have sighed when other interviewers have bought up minor quibbles about otherwise excellent candidates. There are a lot of really bad interviewers. Getting interviews at a bunch of places that really desire to hire you somewhat lowers the crappy interview percentage.
Yet another way to put it is you are practically guaranteed a bad interview. It is best to accept that and move on. I had what started out as a really great interview process go bad when I went on-site. It happens. The randomness of the interview process and the fact we're all human/fallible practically guarantees at least one bad experience. My bad experience really bruised my ego but ultimately, I realized it was a good experience too when I framed it in the context of the overall experience.
I interview people a lot, and I always ask such questions. I just don't want to have people who don't know how data structures they work with every day work and which time complexity they have. You would be surprised, to see how many people don't know the basics.
Often companies, like google, and facebook ask brain teaser, i.e. tricky questions with tricky answers. I agree with you that such questions are mostly useless and make people feel stupid, especially if they didn't have experience with them.
P.S. It would be nice if you provide examples of tasks which you against, so that everybody who reads this is on the same page.
The biggest challenges I've personally noted are these:
(1) Despite all the (probably sincere) claims many startups make about not looking for computer science degrees, coding questions are absolutely, positively optimized for computer science majors. I have lost more than one job because I'm "not strong enough with algorithms." For certain kinds of positions that's assuredly correct -- the engineers where I work now, who are building a high-performance realtime database, for instance -- but the number of times I've needed a routine to return a list of strongly connected components in a network graph as part of my 15-year web development career is exactly zero. (I have, however, needed it for a coding interview; as it turned out, writing that and a shortest path method and a simple parser just got me to the final face-to-face interview, where I was asked three or four more algorithmic questions. I did not get that job.)
(2) I increasingly see jobs requiring experience that I literally cannot get without already having one of those jobs, i.e., "must have already worked with high-performance clusters and web sites serving millions of hits a day." It seems like the only way to get that experience is to either start a startup that gets to that point, or get an internship at a company that already has it (which is not an option once you're out of college).
Coding is done on a computer you bring with your tools in a language you know. You get to use the Internet to looks stuff up, you know, just like you can when you are really doing your job. And the questions we ask are problems we have had to solve at work.
The design discussion is collaborative, the interviewer is an active part of the discussion playing a sort of devil's advocate.
If this seems like a process you would like, we have a bunch of python positions open right now, check them out here: http://grnh.se/vj71bo
If teams would prepare ahead of time, they would create a schedule for the process with specific steps for specific areas of interest: personality and fit, general algorithms, design approach experience, domain expertise If core to the role, ability to work well with others, general approach to the craft, approach to quality, money expectations, check for previous projects, references, etc. I have been in interviews where 8 people try to compete to see who asks the most bad axx question with no flow whatsoever. Or other times is the "big shot" with experience on the latest framework of the day who has no experience in other things at all. What a waste of time.
My approach sometimes, particularly with the younger interviewers, is to pause the interview, ask them what they are interested in knowing, and then give them some hints, through comments, about the questions they should be asking me.
For "how many balloons fit in this building" question, I ask what is the purpose of the question. Sometimes they don't know! Then I say "let's figure this out together." And then have a little fun together while showing estimation skillS or asking clarifying questions: is it regular children balloons or hot air ones?
For coding questions: pull out the laptop and show them.
People: prepare your interviews.
Candidates: take control of the interview if the company didn't. You already invested the time so might as well help turn it around.