Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why are Silicon Valley interviews such a drag now?
66 points by algoal on May 10, 2015 | hide | past | web | favorite | 108 comments
2 people I know and I are in the process of looking for new jobs.

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.

If you are looking for a job, I cannot recommend giving technical presentations at user groups highly enough...

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.

Writing a book is another way to raise your profile. Just don't expect to make a fortune from publishing the book. Making YouTube videos is along those same lines. See Derek Banas or SlideNerd on YouTube.

Just wanted to add. With the videos. Don't give it all away. "Make them pay for what they can't get for free."

How do you go around giving technical presentations? Where do you find the audience? Can you please share links to some of your presentations?

If you live in the SF Bay Area this is pretty trivial fwiw. There's tons of user groups / meetups / conferences. Pick something you're interested in, invest 3-6 months in working all the angles, and you will absolutely be worth listening to for 30 minutes on that subject.

Can confirm! Have been offered several jobs this way.

> But all three of us are very reluctant to start interviewing because we all know how much interviewing really really SUCKS.

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?

> Also, the focus is often on how you approach the problem, not if you write up a perfect solution or not.

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'm not sure how you can be so certain? (99% of interviewers..?)

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.

99% is exaggeration (or "hyperbolation" ), but I wanted to highlight the issue. From my personal experience, and from what I hear from others. In fact, I've never experienced "wants to know how you approach the problem" moment ever.

Do you have any sort of evidence to support this claim? As far as I can tell I've never had an interviewer reject me for coming up with a solution other than the one they wanted. At worst I've had people strongly nudge me in the direction they wanted me to go. I'm certainly willing to believe that terrible interviewers are out there, but I have trouble believing that I've hit the 1% every time.

I have. I once had an interviewer ask me to write CSS code that generated an American flag. I used the nth-child selector to render 13 alternating red and white stripes. The guy asked me why I did that instead of making the background white and painting red stripes over the top of it. I didn't get the job and the reason the recruiter told me I was rejected was because my CSS code was wrong.

Collectively, the three of us have interviewed dozens of times over the last 3 years. The description is based on this, so it is not just hearsay.

I see. Perhaps you applied to a certain type of company? That's my only guess as to why your experiences are different from mine. Company size/age/field might all matter here.

More anecdata: I've also went through several rounds of interviews in the past 3 years and I can confirm algoal's point of view. The interview process absolutely is broken at most places in SV. It also appears to be broken in the most demeaning way possible for the applicant. Harsh criticism I can handle. Gladhanding and well wishes followed by a nuclear "no response ever again by anyone who works here, even if you knew them at previous companies" is more than I can handle.

PS: I interviewed at mid-sized startup companies, all 100-300 people.

This is the biggest myth that you will hear from every recruiter. If you do not get the problem correct, you will not get an offer.

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."

I periodically see posts about how hard it is to get a job as a computer programmer on this forum. I think I have a different point of view on this one.

I previously worked as a classical orchestral musician.

In the entire United States, there are a maybe about 10 full time jobs open per year for any given instrument (excepting strings). For most instruments, there are thousands of music performance majors who graduate from colleges around the US each year.

When there is an audition, people fly to the audition at their own expense from all over the world. If you are even permitted to audition for the orchestra, you will face between 100 and 300 competitors. Almost everyone at these auditions has at least 15 years of playing experience and advanced (expensive) degrees. In the initial round, players have between 3 and 5 minutes to advance. Often the audition will consist of many rounds that will span 4 or 5 days (depending on the number of candidates).

Even if you win the audition, you don't necessarily have the gig. You are often on a six month to one year trial. It is very common for musicians to win an audition, play with an orchestra for a year, and then lose the job, never to win an audition ever again. It is also common for a musician to win a job, only to find that the orchestra is insolvent a few years later.

Often people will spend a decade going to auditions around the US before they win a position or just give up.

The last audition I attended was with the San Antonio Symphony. There were over 100 players at the audition from all around the US. The base salary for the San Antonio Symphony is $26K per year.

By contrast, the last time I was in San Francisco (2.5 years ago), I applied to about 80 web development jobs in 1 week. At the end of the week I had landed a job that paid $120K per year, great health care, free massages once a week, and all the food I can eat. I had 1.5 years of professional development experience and no CS degree.


There aren't that many full time jobs even if you take into account lower tier full-time orchestras. The ~10/year number is based on my experience on the audition circuit. Also, I am not aware of any orchestras that involve one member of the section having a full-time gig and the rest of the section not. You can't have an orchestra with only principal players. You have to hire everyone to have a concert.

Regarding your comparison to number of jobs to a large tech company:

Full time orchestras in the US: ~40

Full Members per orchestra: ~100 (Maximum)

Total Orchestral Jobs: ~4000 (This is a deliberately high estimate)

Google employees: 53,600

Microsoft employees: 99,000

Apple employees: 92,000

Amazon employees: 110,000

You are correct that you can be a part of the "Freeway Philharmonic". You will make between $50 and $150 per service (2 to 3 hour rehearsal or concert) playing maybe 6 services per week. Sometimes you will get paid for mileage. Sometimes the orchestra will arrange for you to sleep at a donor's house. Occasionally you will get a per diem (basically daily pocket money for food and gas). Regional orchestras have between 4 and 12 concert weeks of work per year. There is very little work during the summer. You can pack a suitcase and drive from town to town every week and survive. Nobody has work every week. If you don't work, you don't get paid. I did this for about 3 years. Some people do this for their entire career.

Also, just so you have an idea of the competitiveness level of these lower tier part-time orchestras. A few years ago, the Oakland Symphony had a section flute audition. Over 150 people showed up from all around the world. The Oakland Symphony has 4 weeks of work per year - which would amount to a maximum of about $4000 yearly for that position.

Luckily for me, I have found that I enjoy programming a lot more than performing with an orchestra. Now my life is a lot easier.

You make some very good points here, and I'm fairly convinced. However, I know for a fact that my local orchestra works on a full-time principal, part-time section basis. Just how common that is, I have no idea, but I have an anecdote to show that they do exist. Also the musician's union signed off on the arrangement.

Ironically one of my best hires was just finishing his degree in particle theoretical physics at a top school. No puzzles at all - all questions were focused on would we want to work with this person.

I figured his physics background pretty much proved he can figure puzzles out. I did call his thesis advisor as a reference.

Your comparison with music kind of reminds be of people applying for unique faculty positions in Universities. It sounds like is that there are lots of qualified applicants and not many decent jobs.

Interesting comparison

There are 2 problems these days :

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).

Personal experience/ Ancedote about (2). Sometimes interviewers (may be new or inexperiences) just try to prove that they are hot shit. And feels like they forget that the objective of interview is not to establish who is superior rather if the candidate has the skills what they are looking for. This happened couple of times to me.

I interviewed for Google two times, FB one time and Amazon once. I hated every single one of those interviews. I got another call from Google and I told the guy if he is expecting me to go on a 2-3 month interview loop with one day of hoping to give the answer the interviewer wants (on those situational questions) than what makes sense in the context with limited info, deal with guys who think they are the gods of the universe ... i am not interested.

Good for you. Google can get away with this garbage because so many people would sell their girlfriend to work there. It's good to hear about people not taking their crap. There are plenty of great places to work.

"would sell their girlfriend"

Really not appropriate here.

"Really not appropriate here."

Really not appropriate here.

Karma 6, probably all for this. This community is going to crap.

Karma 854, probably all for this. This community is going to crap.

Please burn more karma for me, loving this.

see reply - are you happy now?

Yes, yes I am. You're showing me good.

Flagged for negativity ;)

Yes, SV interviews can be pretty bad, and I've been through the whiteboard coding style ones myself, and in one case probably faired badly. As I was trying damn hard to remember stuff from 2nd year software engineering class, I was also wondering why the interview was focusing on a skill I hadn't used since University, and not, instead, questioning any of the skills I've been using for the past 10 years -- and which were relevant to the actual job. My regret is not walking out half way through that interview.

Not all companies interview poorly. My Netflix interviews were great, and focused on what value I can bring to the company, down to discussing specific projects and tasks I could begin work on. Note that this wasn't strictly a programming role, but then, nor was the other company who did have me do whiteboard coding.

As for more programming roles: can we come up with a better interview technique? How about this:

  - Ask the candidate for several URLs to code they have written (eg, github).
  - Select some code beforehand and print it out.
  - During the interview, ask the interviewee to explain their own code.
  Explain choices, rationale, how they tested it, how they developed it, etc.
edit: formatting

That's how I got my first job out of college. Actually when I walked into the interview room, they had my program on a projector, the code loaded into an IDE, and asked me to explain everything. Then they loaded their apps on to the projectors and basically did the inverse for me. A very nice interview. The final portion was their most junior developer who told me just to ask whatever questions I wanted that would help me decide whether I wanted to work there.

Funny enough, that's exactly how I got my current job. I have no code up on github or anywhere else, but I sent them a piece of a project I had worked on as a consultant (with permission from all the pertinent people). They were impressed with it. We discussed the decisions I made over the phone as well as my other views on software development and just like that I was hired. No in person interview required. The company is fully distributed, so they didn't have an office I could go to anyway.

It's also important to point out that the interview process went fast and smooth because I had the exact mix of skills they were both looking for and lacking at their company at the same time. Those skills in this case were PHP based CMS's and single page web applications.

So, to OP, if you want the interview process to go better, identify a company that needs the skills you provide badly. Most mid-sized startups in SV who advertise that they're hiring typically just need meat to scale their operations. Sometimes you can get lucky and use those opportunities to switch domains (ie: from JS web development to mobile game development) but most of the time those jobs just suck.

Netflix is a wonderful example of a company doing interviews right. I haven't had the opportunity to complete a full process as I bailed out mid process because of their location but the 2 rounds of process I had, I was absolutely blown away and was genuinely very pleasantly surprised.

If any of netflix employees are lurking around here, Please keep up the good job.

The funny part about this is that the founders of these startups, who in many cases wrote the code that got the funding to start hiring programmers, couldn't come close to passing these interviews themselves. They also in many cases aren't very good programmers, and are looking to hire people better than they are for rewards that won't come close to what the founders receive.

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.

I agree -- the interview process is a direct reflection of the organization you are interviewing for and you should judge your potential employer on how they interview you.

Just a remark, I guess http://getmagicnow.com/ is the correct link(notice the now)

If you or your friends are interested, you should check out Matasano (disclaimer: I work there). Our hiring process is much more focused on work-samples, and the in-person interviewing is pretty laid-back. We're also very up-front with candidates about what to expect and where they are in the process. Check out our careers page:


Feel free to drop me a line if you (or anyone else) has questions - I'm andrew AT matasano.com

Great, spend a lot of time studying your niche (security), all just for one interview. Yeah, your process isn't broken.

For what it's worth, that's a fair concern. I offer two things that make it not quite as bad as you may think, though :-)

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...

Any interview process that requires a substantial time investment by the candidate pre-interview is broken.

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?

It's pretty simple, then - don't apply there.

> Any interview process that requires a substantial time investment by the candidate pre-interview is broken.

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.

It pretty specifically says you need not know anything in security directly when going into the hiring process.

This is not what an interview at Disqus is like. We interview you like we work. This means you are going to code and you are going to lead a design discussion.

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

FWIW, I just accepted an offer from Instacart (my first day is Monday). Phase 1 of the interview process was a 10 minute coding problem on Hacker Rank. Phase 2 was building a small web app in half a day on my own time from my own apartment. Phase 3 was a 10 minute face to face coding problem that I solved using my normal programming environment on my own laptop. There were also conversational interviews with several people. No whiteboards were involved at any point.

They (er, we) are still hiring: https://www.instacart.com/jobs/engineering

That sounds absolutely awful.

Basically, interview questions at such companies test your knowledge of basic algorithms and data structures. If you have problem with answering such questions, I recommend you taking a couple of courses in these fields on Coursera or read basic algorithm books (and of course solve exercises).

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.

> 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.

"reluctant to start interviewing" based off of stereotypes? Am I not understanding this?

As I mentioned above, collectively, the three of us have interviewed dozens of times over the last 3 years, so this is from personal experience.

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.

Yeah, I'm not entirely sure where they've interviewed or read about interviewing. I guess Google and Microsoft might run interviews like that, but I've never had that experience. And I've interviewed in a lot of places (both in Silicon Valley and out of it!).

It seems like maybe they've spent too much time on HN and Reddit reading about interviewing without doing it. ;)

I've proctored a number of interviews for $BIG_COMPANY and they wanted whiteboard coding (yuck), so I made sure that my questions involved the whiteboard but zero coding. Without revealing my own secret interviewing sauce, I take people through an area that most software engineers use but are highly unfamiliar with: the linking and loading process. It works because it's such a black box with most people. I have them figure out how they would write a linker and loader. The people who score well with me never really thought about it before, but with a bit of guidance come up with a pretty reasonable facsimile of what such a system looks like for real.

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.

> Without revealing my own secret interviewing sauce

Why is it a secret?

To be fair, an interview process that's novel and successful is certainly a competitive advantage, at least in companies where they understand their engineers are key to their success and not simply cogs in a machine.

> an interview process that's novel and successful is certainly a competitive advantage

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 never interviewed with Google, but when I interviewed at Microsoft I had a single interviewer (of five) ask me to write code on a whiteboard, and it was a total of ten lines or so.

If you think interviewing is bad now, wait until you're world-class.

Then either the interviewers "know" the wrong answers, or feel so threatened that you're "not a culture fit."

I'm pretty sure i'm not world class.

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.

I get the feeling that at some large companies there is the "front door", geared towards junior staff and fresh graduates, and typified by whiteboard coding trivia, and then the "back door", geared towards opportunistic hires of world class talent. Anyone else get that feeling?

Maybe they're just put off by people arrogant enough to call themselves world class.

Total guess, but picking a "throwaway" account might suggest the writer is uncomfortable saying that, and may never have said that in an interview. But that's a guess. If they did call themselves world-class, then that's sure to come across as arrogant, even if they are.

Sure, but it's something other people say of you. To say it of yourself, even outside of an interview, is rather gauche, and perhaps reveals a sentiment that does manifest in interviews.

When you are an interviewer, remember you are given power to determine whether people get the job and are their gatekeeper. You are determining career paths and opportunity. Don't make the interviewee do things they wouldn't do on the job but find out who they are. Even when you hire you really learn who you hired in action, even if you have a circus hoop based interview process, the real test is the first 2-12 weeks.

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.

I don't think all companies interview like that. In my honest opinion, the interviewing game is changing if you don't interview at any of the giants.

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.

I get many emails from recruiters but ignore them because I simply don't know what to expect from interviews - not really interested in being asked to solve someones' pet algorithm on a white board. I wish there was a list of companies who do project based interviews where they ask you to work on a small but challenging project related to the actual work you'll be doing, and then bring you to an interview to present it and defend it in front of your potential future colleagues.

I'm genuinely curious why engineers would prefer to work on a project for an interview? To be tasked by multiple companies (presumably by as many as you are applying to) to spend 4-8 hours doing unpaid work on a project which is probably inane and most off all - completely useless for everyone involved.

If I've got 8 hours to spend I'd much rather contribute it to something that someone else will actually benefit from.

Because as much as spending 4 hours doing unpaid work may seem to suck. (Which let's face it, I do at least 8 hours of unpaid development a week on side projects.) It's a better and more accurate test of your abilities than doing what can only be compared to that of a trivia based game show.

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.

Yah, I've been interviewing a little lately, and while I understand the need to see if the person can code, white-boarding isn't really it. I've been doing this long enough that i've been the guy on the other end of the table more often than not.

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?

I find that companies don't know how to interview, and therefore the individuals doing the interviews have no clue what they are supposed to be interviewing a candidate for.

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.

This is excellent, and a great reflection for what you'd be like to work with.

I think you'll find startups to be more flexible on this, with the downside that they are often still figuring out their own processes. At Nylas we ask a range of questions from high to low level but all related to the kinds of problems engineers would be working on - for example, if you'd be working on the platform team, we ask you about things like concurrency and locks because we actually use those, not because we read some CS 101 textbook and thought they'd be cool.

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!").

I'm working semi hard at solving this problem right now, but up in Seattle.

Here's what I can tell you and your friends to help until I am running the awesome company that will solve some of these issues:

Interviewing is hard. For both the candidate and the interviewer. With engineers, it's even more difficult. They have to assess a culture fit, a character match, a specific set of already acquired skills, the ability to learn new skills, the ability to solve problems not yet known to anyone...and all in some consistent fashion. It's very difficult to extract hard data out of an interview that isn't a question and an exact answer. So, think from your interviewer's perspective. The best thing you can do is help them get the data they need to extract from you. If the question they ask is too specific, help them see what you do know, how you would find answers to what you don't, what you think the answer would be, how you would reason about it, etc.

I would highly not recommend selecting a company based on their interview process...you might not like the narrow pool you're left with.

As others have said, you're making a fair amount of assumptions about the way the "median" interview in Silicon Valley goes. Interviewers tend to be less concerned about whether your code matches the picture in their head as much as whether your code works and isn't doing anything unduly stupid. (Being aware of performance concerns and how to optimize for best O(n) values is a huge, huge deal.)

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).

Your second point is analogous to companies asking for X years of experience in a language that has only been out for y years, where y < X

The whole hiring process is broken. The recent trend is to put a firebreak of "recruiters" between the company and the jobseekers. These folks know shockingly little. But, descended as they are from bridge-trolls and meter-maids, they are happy to get in the way and throw their puny weight around.

No one is served by this approach but the recruiter fraternity.

I want a site like this too! I've become so frustrated with stupid interviews, I've just started walking out. I feel that if a company can't be bothered to learn how to conduct a meaningful interview, I don't want to work there anyway.

Nowadays, I tell recruiters right up front that I won't do whiteboard questions. I'm more than happy to bring code I'm currently working on to the interview and talk about it with the interviewer, but I will not subject myself to pointless puzzles and demeaning whiteboard tests.

Another thing I've seen companies do in interviews is ask candidates to code something on their own time as part of the interview process. I have then seen that code go live on their site. I won't write production-ready code for companies as part of the interview process anymore because of that clever bit of dishonesty.

How many companies are left after you declare you wont participate in whiteboard questions?

I've never been unemployed during my 25-year career, so apparently enough.

The more you try to emulate reality, the farther from reality you get. That's why interviewing practices are so absurd today -- cognitive tests, personality tests, whatever work test that tries to assign a quantifiable score to an applicant.

Interviewing is a hard problem. I've done many interviews at small startups and big tech firms. Its a bit of a hit and miss to be honest.

You have a long flight and ended up burning midnight oil last night. They might think you're not passionate enough.

You're quite excited about certain things, they think you're trying too hard.

you absolutely suck at writing recursive code on a whiteboard, they think you can't code for shit.

Some dude on the other side is trying to prove his seniority and intimidating, they think you don't fit in culture.

Lesson learnt the hard way: Just gotta keep on trying

Stop looking for jobs in Silicon Valley.

Hired.com. If you don't want to deal with a lot of BS and are able to make decisive choices, you can't go wrong.

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.

i don't think you understand the question. the problem presented is about the interview itself and not about how to find a place to interview.

I do understand. Going through Hired is a dramatically accelerated process of the regular interview cycle. So while you might get those annoying interviews, you won't have time to dwell on them because you'll also get some great interviews and it is all packed into a week or two instead of dragging on for months on end.

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.

Why not actually start interviewing. It may be that your fears don't match up with reality, and you'll do awesome and each get a handful of great offers.

It's a good point that asking so much of someone's time right off is unreasonable. Really there should probably be a quick discussion about what the job is, can the person do the job, what the company is about etc, and then some loose terms, and then a big interview if that is even necessary. Either that or pay people for their time if you are going to require a 5 hour interview.

My interviews are not like that. They focus on your work samples, talking through system design thought experiments, and some light on-the-spot coding just to make sure you are not BSing your work samples (FizzBuzzy type stuff). I posted a job in recent Who's Hiring you can find in my submissions if interested.

Maybe I am in the minority here, but I thought the interview process was super fun! I enjoyed solving puzzles on the whiteboard and the courting process. "Forced to write whiteboard code" ... is that really how you feel about it? In some ways solving well-specified problems (often a few carefully-crafted gems) with a captive audience is a special treat. And then you typically have the opportunity to turn the tables and ask questions about their business and engineering challenges. Maybe just relax a little and try to have fun with it? (I know, easier said than done when your career is on the line.)

If you want, I use to run this service...


Help 3 fellows would be a pleasure...

We desperately need a couple of additional coders to work with our tech leads. However, (perhaps surprisingly) having no additional coders is better than someone who's a bad fit (sorta like it's better to be single than married to someone you cannot stand).

It might be that you're hearing about job openings at companies which are large enough to have a marketing budget or happen to make a narrow range of products which you may use. Candidate and company both prefer candidates who are "walked in the door" by a trusted intermediary. However, for a company such as ours, we're small, our folks are heads-down on their work so don't spend much time at conferences, we sell to enterprises so you wouldn't hear of our product, and we don't use recruiters. There's probably new hiring forums/recruiters/technology stacks which would help this process, but I get a few such offers each week and how would I determine what works?

We've gone through a number of approaches to interviewing and haven't yet found an interview "formula" which reproducibly gets to firm assessments. An interview (typically filled with talking) usually distinguishes between a "probably no" and a "probably yes". In contrast, a day or two of the typical back-and-forth while coding on real problems produces a highly accurate assessment...and enough insight to pay a premium for someone who could really help us get where we're going. However, interviews rarely include such real programming. As some other posts have mentioned, recruiting (and particularly the interviewing aspect of recruiting) is tough.

While it's bad news for a company to hire the wrong person, it's also bad news for the candidate. Assuming you're not looking to hop from company to company, a good job is IMHO for 5+ years--a substantial portion of your productive years. Once you get a good sense a company is attractive to you (and vice versa), why not offer to spend a couple of days (e.g. a weekend) working with someone with whom you'd actually be working if you were hired...before you or the company commits? For our company, maybe we could pay you as a consultant so you could work on real code/real problems. No, don't ask for big dollar consulting fees--the benefit to the company is probably negative given your limited context and the oversight you'll require--this is just to reduce the likelihood of companies engaging in this practice without being actually interested in hiring you. It's a big investment from both sides, so this would be after achieving the "probably yes" outcome.

For both the initial, superficial programming tests and optional 2-day programming projects, how about proposing to the hiring company how you'd like to be assessed? For example, our company develops single-page, collaborative editing and annotation applications for patent offices. If a candidate liked our company's people during the normal interview, tried our software, and proposed to add a feature to an open source project we use, the results would be a pretty clear indicator. You'd also be doing something you find interesting, since you suggested it.

Our jobs are at https://angel.co/edyt

I don't have the answer to your question, but I agree that interviewing has gotten really bad. It's not always whiteboard problems:

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.

Maybe you didn't get it because you lied? What if you'd said you didn't know?

Perhaps - but this is why trick questions are terrible in interviews. They tend to be around trivia, and encourage people to guess at a response.

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.

Over the summer of 1986, I wrote a large chunk of a Common LISP interpreter. That fall I applied for a software engineering job at Microport, a UNIX SystemV vendor.

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.

In what way was I lying?

Not lying per se, but if someone pulls something out of there ass in an interview I'm giving that's a red flag for me.

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).

You tried to bullshit the guy interviewing you, that's how.

They may have been asking you to talk about UIActivityViewController: https://developer.apple.com/library/ios/documentation/UIKit/...

The UIActivityViewController was introduced in iOS 6. That interview took place during the iOS 4 timeframe.



Sorry I don't follow your question.

No worries.

Cisco gave me a written test. I was left alone in a room with the test, some paper and a ball-point pen.

One question asked me to debug some C++ code - without a computer mind you. Another asked me to reverse engineer a hex dump of a network packet. I don't recall what the third problem was.

It was only after I completed the written test, and my interviewer looked over my answers, that we had an actual face-to-face interview.

It is quite puzzling to me that that's not commonly done.

This is my defense of whiteboard interviews.

- 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.

My question is if the candidate did a degree at a good school doesn't that prove anything? If they did a similar job for a competitor that doesn't count or has a giant set of github repos does that not count? My feeling is that pressured puzzles are a cop out unless you are trying to filter out low level employees.

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.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact