I despise interviewing for software positions. Engineers love to treat interviews like some kind of hazing. They're gonna make you quiver and sweat and if you can still solve their stupid brainteaser maybe they'll give you the honor of working with them. Problem being, this has basically nothing to do with how good you'll be at the job. I spend 0% of a normal day with someone I don't know staring me down and judging every line of code I write in realtime.
I much prefer medium sized offline coding challenges, both for myself and for hiring my team. You give a good engineer a small project to work on, an he should crush it. Because that actually has something to do with what engineers do on a day to day basis. Personally, I get the job pretty much every time if I am told to build a small project, and I crash and burn almost every time if I get the SWAT team of surly technical interviewers.
It's worked fine for me because the small companies I like to work for are more apt to give out the projects, but still I could do without some of the awkward interviews I've gone through with companies who use the Google-like process.
I remember one such interview. I had to write a relatively small and simple routine. I was supposed to start talking/coding immediately, when I stopped doing that for maybe 5-10 seconds (I think it's pretty normal that you might need a little bit of private time with your brain...), I was asked to tell what I'm thinking about. This question was being repeated throughout the whole interview. But how can I think about anything, when I have to constantly blabber?
I'm a software developer. By far the best interview I've had in the past few years was with a very small startup in NYC with some cool tech. We had a fairly extensive and relatively detailed tech interview over the phone that included mostly general questions like explaining how DNS lookups work. They then gave me a fun, throw-away programming project to do offline in a day or so that utilized their preferred stack, and they PAID ME with for it with a $150 Amazon gift card. I can't tell you how many bonus points they earned with me, both for the enjoyable, puzzle-free interview and for signalling that they understood that my time had value. I was ultimately told that they had "changed direction" and weren't going to hire at all, and I have no reason not to believe them. I don't feel like my investment in time with them was wasted or that I was insulted/abused in any way, quite the opposite and that was refreshing.
I actually enjoyed the few times I was asked to do a small project, and I think it's much better way of evaluating someone, if done right.
First off it's a sign of commitment from the candidate : as small as the project can be, it will require on his/her part to invest more hours than the one/two of a live technical interview.
Second, it's much closer to what your real job will entail : being given a task, committing to deliver on a definite deadline, and doing it using whatever tools and sources of information you are more comfortable with.
A live interview should still be the final step, but in this case the candidate should defend and discuss how the project was realized, possible improvements and problems : this way the company should be able to confirm that the project was actually done by the person being interviewed as well as judging his ability to explain, communicate and work with other people.
I believe this is exactly how it should be done. I don't think it very likely that someone could cheat on the project and then still be able to speak intelligently about the solution.
Nowadays when recruiters ask me more than two algorithmic questions in the same interview I just tell them gently to fuck off because "I'm not an algorithmic dictionary and when I need to use one i google it and it's done."
I agree with you that a lot of SE interviews are frustratingly pointless, but I disagree that coding challenges alone are adequate. A very important aspect of being on a team of engineers is collaboration, which often comes down to solving tough problems as a team at the whiteboard. I spend maybe 5% of my work time doing this, yet it's some of the most efficient use of my time - the hour I spend fleshing through an idea with a coworker often saves me 10 hours meandering through a problem on my own.
Interviews are not collaborative. They're intensely hostile experiences, even when interviewers are trying hard to be nice (many don't). It's silly to suggest that a job interview is a venue to evaluate how a candidate collaborates.
Admittedly, I don't have a huge interview experience (on either side), but that hasn't been my experience. Apart from the implicit pressure of the fact that you are being evaluated, most of the interviews have given me the impression that the opposite party are really trying to learn about me, not putting me through a hazing experience.
I think there is a lot of negative bias here, because people who do badly in algorithms and data structure questions, or dislike them for some other reason, are more likely to speak on the issue.
I think that these questions are good because they are difficult, and a smarter more capable person is much more likely to get them right. Notice that big tech companies have stopped with the "brainteaser" style questions like how many potholes in Manhatten, but there is no move away from algorithms and data structures questions. And I don't consider the format to be high pressure. Apart from the pressure inherent in having to answer the question on the spot, I never felt any pressure from the interviewer, they tended to be very polite and mild mannered. At worst they didn't understand or agree with my solution.
Telling people that these interview questions suck and they should look for jobs where they don't have to answer them, is really bad advice. Some of the best jobs (for most people) require them. If you face such an interview, the very best thing you can do is study. I probably did 100 interview questions in preparation for my job interviews.
Consider this scenario, your company will never need an algorithm designer. The jobs they need are to do basically glorified component integration. You have a candidate who is awesome at gluing together various libraries and other odds and ends into a working product. The things he's worked on are well known and well regarded, and he has 15 years out of college doing these things. He's never even had to think about the complexity of a red-black tree in all that time let alone implement one. He's solid, a great team lead, personable without any difficult to handle "quirks". He's been the core to the success of several products. In other words, he's the perfect match.
So why filter him out by testing how much of an algorithm encyclopedia he is? It'd be like interviewing an algorithm guy by asking him how well he knows some web framework. At best it's non sequitur, at worst you won't get the employee you need.
>Notice that big tech companies have stopped with the "brainteaser" style questions like how many potholes in Manhattan
My understanding is that they did this due to a number of lawsuits. The courts felt that it presented a discriminating playfield, and most large companies have stopped this due to recommendations form their legal departments.
Interesting point of view, which I don't share by the way. I think the right person for the job is not per definition the smartest or the best at solving equations during an interview.
Finding the right person for the job is more about getting a good fit with the rest of the team. Being the smartest guy/girl on earth doesn't help you when you have a shitty personality or can't work together with the rest of the team. If I were to recruit a programmer, I'd look for past work (Github repos, online projects), accomplishments and personality, rather than test results that don't reflect the reality of the job in any way.
Well it's hard to quantify the relative importance of personality and cultural fit vs intelligence and programming ability. You can turn what you said around, and say that you can be the nicest, coolest person in the world, but if you are a fucking moron who can't code, you won't be very useful.
But the big tech companies seem to have settled on the current process, and are therefore probably fairly happy with the people their interview process is giving them. As to looking at previous projects, that makes sense but it might be more time consuming to properly evaluate someone like that.
The big tech companies haven't been happy with the people the interview process have been giving them – all we heard about for a long time is about how they couldn't find anyone to hire. Perhaps this settling you speak to marks the end of developer shortages in the industry?
Not really. These are two separate issues. If I am a gold panner, I might be very satisfied with my gold panning technique, and yet complain that there is a shortage of gold in the river.
The fact is that the companies failed to communicate when he explicitly asked for feedback. That has nothing to do with his performance in the interviews, unless these are people who simply don't reply because they thing the candidate is bad.
I'd recommend "Cracking the Coding Interview" by Gayle Laakmann McDowell. It's cheap at around 25 bucks on Amazon and has a pretty good cross section of questions. It isn't comprehensive by any means but I feel it's a good place to start. I think there is also a companion website that has more questions.
I personally would quite like an interview where I work with the interviewer to solve a problem or puzzle that he himself has not solved--as opposed to the traditional setup where the interviewer acts as the all-knowing oracle who happens to withhold the solution to this one problem. This could be difficult to set up on a regular basis, though.
I actually had an interview somewhat like that recently. The team was about to start working on a new feature for their software. We had a sort of round table discussion of the feature and how to go about it. They actually didn't have me write any code at all. We just discussed approaches to the problem, algorithms, architecture design, potential problems, etc.
Another place had a pretty cool interview process. They were going to give me a take-home project with a week to work on it and pay me market rate for it (in the form of an Amazon gift card for a few hundred bucks). I didn't end up doing it, though, as I took another offer right before they gave me the project, so I voluntarily withdrew. Still, I think it was an interesting and worthwhile idea.
I'm not a fan of puzzle interviews at all either, and I agree that they're usually not very relevant except as a sort of specialized intelligence test which may or may not really be indicative of job performance. That said, working with the interviewer on something neither of you have solved does sound more enjoyable, interesting, and informative for both of us than having the interviewer sit behind a facade of perfect technical knowledge. At least that way you'd get to experience some sort of teamwork with the person, whom you'd presumably be working with.
I've heard of places having a candidate sit down and do some pair programming with one of the developers. That seems like a similar approach which emphasizes concrete development and coding over algorithms or puzzles.
Well written piece that shows what to me is the SV recruiting paradox: there is a massive demand for programmers, yet companies make it really, really hard to get a job. It's easier to start your own company without the interview hassle and condescending attitude of some HR managers.
I might be out on a limb here, but it seems it's almost easier to raise money for your startup than to get a job. Of course it gets a lot easier once you have established a network of people so you can bypass the whole recruitment process.
Hiring the wrong person is potentially dangerous for your business, there's no denying that. However, the tendency today is the demand for hiring 'rockstar' programmers for essentially pretty mundane jobs. This poses two problems: an artificial shortage of qualified programmers, and if you manage to find one, you hire an overqualified programmer who is likely to get bored and unmotivated within a couple of weeks.
> It is much better to filter out some perfectly good candidates than accidentally hire the wrong candidate.
If the companies OP cites were operating under that principle, they should be able to say Hire or No Hire after the last interview. Waiting over 1 month to decide won't make the candidate improve; the only reason to do so is to look for a better candidate, or hire OP if no better candidate is found, but in that case they aren't exactly using the principle above.
In California, to avoid litigation lawyers get involved, the whole process gets documented, orchestrated, and some kind of separation agreement is negotiated.
But mostly it's emotionally very hard and very stressful. The decision is not taken lightly.
It definitely isn't easier to raise money than to get a job. People just expect it to be nigh-impossible to raise money, and that everybody deserves a job, because that's how it used to be.
Also, there is a massive demand for code that works, but most people seem aware that just hiring whatever the cat drags in seems not to result in code that works, so they make these barriers.
I honestly have no idea whether said barriers do a good job, and it seems like basically nobody is trying to measure it. You'd have to record the outcomes for hires and no-hires, i.e. admitting that you wish you never hired someone, or that you wish you had because they went on to invent sliced bread, and that requires testicles of carbon fiber.
I am in grad school and live with roommates in the SV. Amongst the six of us, we have interviewed at a cumulative of 20 big SV names in the last month and of course we discuss the interviews frequently with one another.
Companies like Broadcom, Cisco, Juniper, Anritsu, Apple etc. solely rely on the programming problems the OP talked about.
HP focuses on riddles and puzzles to a point where it is ridiculous and mind-numbing (1 hours interview, two interviewers, about 15 riddles :-/)
There is however a marked difference in the way companies in SoMA, SF interview you -- conceptual discussions, chatting about previous projects, finding out about your open source contributions, asking you about what you like about a certain language, talk about editors a little, etc. And I'm also including companies like SCEA, who although a part of larger companies, behave in this way.
Unfortunately none of us interviewed at Google or Facebook, so I have no comments there.
P.S. Most of us have accepted offers at smaller companies in SoMA, SF.
> Most of us have accepted offers at smaller companies
You'll probably be happier, more challenged and learn more this way. Having worked from ultra-small to ultra-big, I learned the most from the small to medium-small places. There's fewer people to fall back on, so you end up cross training.
The urgency to interview, followed by the abrupt halt in communication isn't something that is unique to Silicon Valley or engineering positions. I had it a lot in London a couple of months ago for mostly product jobs.
It's incredibly unprofessional / downright rude - especially when so much pressure is put on to get you through the interview process quickly. It also means that I now have a negative opinion of a number of companies - and advise friends against applying or interviewing there if approached.
I've been in a position of hiring before, and while it's not nice to tell someone that they haven't got the job, it's the polite thing to do. Most people are reasonable, and it increases the chances of them recommending your company to others.
I have had similar experiences as well with the slow feedback on the interview. Although I cannot confirm this, but I have heard that the lack of communications is their way of avoiding any litigation action from the candidate. They fear that any rejection can be mis-interpreted by the candidate in such a way that litigation is possible. So no communications equates to no chance of litigation.
This echoes my experiences about a year ago almost exactly (although I was looking in London). The obscure programming problems are largely a waste of time, but fairly non-threatening and generally ok (there were a few companies that did group problem solving exercises instead which really impressed me).
The biggest issue that I found by far was communication. Especially in the Silicon Valley based companies that were looking to hire in London at the time. Communication times of a few weeks seemed fairly commonplace (with contact still extremely positive after such a long wait). One company (I suspect the same as the non-profit mentioned in TFA) took more than a month to get to my second interview, during which time one interview was cancelled about an hour before it was due, and one interviewer simply failed to turn up with no explanation.
My limited experience is obviously no indicator of any wider issue, but if that's generally how companies interview, then I'm really not surprised at all that they find it difficult to hire talent.
> [ Lots of coding puzzles and vague about that "very difficult problem" they're working on that requires expertise in 20 different technologies ]
I get it now. Silicon Valley job interviewing is white-collar gang initiation: you have to show you can bear the pain and humiliation of getting metaphorically beaten up and humiliated. It's not about getting the questions right anymore than taking a fist in the face qualifies you to be an expert Crip, it's about impressing someone of rank by the way you bleed.
> I emailed them back asking if they had any feedback from
> my interviews, but I’ve failed to receive a response.
I've been bothered by this as well, because we want to improve ourselves, and the best way to do so is through feedback. At the same time, you have to understand that not everybody is like us, and enough people that where given that feedback in the past have used that opportunity to "argue" that they really should have been hired or argue that the feedback was wrong. Between helping a stranger improve and avoiding a potential headache for themselves, as much as I would like to have had feedback on some interviews, I can't blame anyone for avoiding the issue altogether.
> Almost all interview questions I take a long time with. I
> probably have a 85–95% rate of solving puzzles—using almost
> all of the allotted time—on my own, and the rest I’ve needed
> a very small hint to get me in the right direction to begin
> with. I can’t think of an instance where I’ve been given the
> answer because of being unable to solve the problem.
Well, that's one problem right there. The kind of companies that ask you the kind of questions that you say are beyond Fizz-Buzz, are usually just starters, to get the ball rolling, give you confidence and keep iterating after the first solution is reached if it isn't perfect, or by adding new constraints to make it so you have to keep thinking.
The interviewer most likely has allotted time for 2-5 of these questions in his interview, if you are taking all this time on the first one, then most likely you are not going to be highly regarded, as the interviewer hasn't got enough information to say wether the one question you answered is representative of your skills.
> Is a total of eight cumulative hours of interviewing with
> around seven different people not enough to get a good
> signal? What does this say about the interviewing process?
It says that they want to make sure they hire somebody who's "a good fit" and the hiring pool is high enough that they can get away with false negatives.
> Don’t sell me your product, sell me your challenges
The fact that they talk about the business instead of the tech, at least gives you some confidence the company will not go belly up because they are selling cuecats. Of course it's not the best way to entice a developer, but it's not as much of a red flag to me as you make it out to be.
Of course it depends. Getting the ball rolling is probably not best done by giving an NP-complete problem (subset sum) as a first exercise.
When presented with an interview question, I usually say "well, it can be solved by doing $NAIVE_SOLUTION, just to get that out there, and I know you're looking for a better one." By doing this, I've established that there is a naive solution and that I'm going to spend time thinking of a better way. Unfortunately, with these kinds of algorithmic puzzle problems, it's usually a waste of time to give the naive solution in full detail, because no incremental development will ever make it monumentally better unless some cheap trick, like memoization, can be done.
> The interviewer most likely has allotted time for 2-5 of these questions in
> his interview
This is usually the case when the problems are easier. For example, "compute the square root of a number" where the solution is, for the most part, cut-and-dry. (Though I would never blame someone for taking longer if they have to re-do the calculus by hand to rediscover the solution.) FizzBuzz is another. Simple binary tree exercises are another.
As said, it entirely depends on the questions. To some interviewers, asking "how do you traverse a binary tree" on-site probably would be a waste of time; that is expected by a first-year CS student.
> It says that they want to make sure they hire somebody who's "a good fit" and
> the hiring pool is high enough that they can get away with false negatives.
This is the easy way to explain it, but I don't think it's a very good answer. I don't think someone is a good fit if 7 people across 8 hours couldn't come to a consensus. If there's that much controversy, what is another coding question going to tell?
> The fact that they talk about the business [...]
This isn't an issue. In fact, it's good to talk about the business and mechanics thereof. But spending half an hour preaching to an interviewee about why the product is so good from a consumer standpoint isn't the best way to capitalize on either person's time. I think, aside from a brief introduction, that propaganda should be disseminated when the interviewee asks questions about the product.
In addition to the above, I think it's a problem when the scales tip way in favor of talking about the product instead of the engineering. If the product gets a 30 minute talk and engineering gets a 5-10 minute talk, I think it's indicative about the priorities of the company toward its employees.
> "well, it can be solved by doing $NAIVE_SOLUTION, just to get that out there, and I know you're looking for a better one."
I'm at the very beginning of my career, having just accepted a new grad position, but I thought I'd offer my opinion on this: just implement the naive solution. If you're really unsure, ask them if they're OK with you doing that. In my very first interview I took the approach you just described and the interviewer actually stopped me as I was brainstorming other ideas and said, "Just work on the basic solution and we can talk about ways of improving it later." In subsequent interviews I've implemented the basic solution first then talked about the drawbacks of that approach with the interviewer, possible improvements that could be made, etc.
Now, most of the problems I was given were far simpler than what was described in the OP. I do think I was very fortunate to get interviewers who weren't just looking for an outside-the-box solution to some brainteaser they'd concocted. Nonetheless, I think it might be worth considering just taking the naive approach (and telling them what you're doing any why) rather than spending a lot of time trying to come up with a perfect solution.
I absolutely agree. As both an interviewee and interviewer I prefer this approach. There's nothing worse than having someone spend 5 minutes waffling or doing very little, then tell you they're going for the complex solution without having shown you the simple one.
Honestly, when I interview and ask a question like this, it's a leading question. I want the simple solution as a FizzBuzz style test of your abilities, then I'm going to ask "and what problems can you see with this solution?" and we'll go from there.
If they request I spell out the naive solution, I certainly oblige. But if it's clear to both the interviewer and me that they are looking for that particular solution, then I won't spend time writing it out. So far, this approach of assuming they want the best solution—while acknowledging the simple solution exists along with a brief sketch of it—seems to be agreeable.
Why's that? I've used that technique in places from which I've received offers (from small non-profits to large multi-billion corps). I think it's a realistic thing to do. If they want me to code the naive way, they can just say so. If they want a better solution, and I sketch out verbally the naive solution and they're happy, why magnify into it?
The non-agreeable part is the difficulty with finding a better solution, and spending inordinate amounts of time searching for one.
> Of course it depends. Getting the ball rolling is probably not best done by giving an NP-complete problem (subset sum) as a first exercise.
2 things:
1) Being asked to solve an NP-complete problem would actually be very simple for a person with CS knowledge - just brute force it! Your solution will be reasonably close to the best-known algorithm for arbitrary input.
2) That isn't actually the subset-sum problem since they are specifying that the subset must be of size n.
The whole interviewing process is ass-backwards for smart people.
I have little interest in working for a company where I'm going to struggle to do the job. I'm not going to apply for a job where I'd be out of my depth for any more than a month or so, because that sort of "if I don't get better at this soon I'm going to be fired" sort of stress is horrible. I want to find a job where I can succeed right off the bat, learn new things and get better over time, and where I can see myself staying for several years at least. No one wants to be a job hopper; it's a symptom of poor interviewing on the interviewee's part.
From my point of view then, I know before I even get to the interview that I'm perfectly well suited for the company and can do the job - if I wasn't, I wouldn't have applied. So I approach interviews in reverse: I'm going to grill you, your team, the baristas in the nearest coffee shop, and anyone I can find on LinkedIn who's recently left. If you ask me stupid puzzle questions that have little to do with what I've come to understand the job entails, I'm going to take that as a sign that your company is less than functional in the interviewing arena, and I know from experience that that extends to the actual engineering too.
Interviewers seem to treat these types of questions as shit filters. I do exactly the same. If you ask them, that's a smell.
I know before I even get to the interview that I'm perfectly well suited for the company and can do the job - if I wasn't, I wouldn't have applied.
You do realize that just because you think you are perfectly well suited for the job, that doesn't mean that the prospective employer has any way of knowing that or that it's even true, right?
Sure, the company needs to show that they are a place you want to work at, but you should realize that you also need to show the company that you are someone they want to work with.
Oh absolutely - but both parties need to work this out. They need to work out that I'm suitable, and I (already knowing this, or at least thinking it) need to work out whether they're suitable for me.
I personally have had a better experience working with companies outside of SV. Better pay, hours, and less stress. Plus gasp!, actual profits (which are important for long term contracts and or employment).
I've been interviewing a lot of candidates over the last couple of months and I also despise trivia question interviews. The approach I've been taking is using a FizzBuzz type of question, but a bit more complex. I couldn't believe the number of candidates that have trouble with things like manipulating two arrays, which I feel is a basic level of expectation for a programmer. If I spend all hour on this relatively simple question, they are a "no" from me. About 10% of the interviewers pass this problem quickly enough to warrant the second question I ask. Frankly, I'm shocked at how under-prepared people are for whiteboard questions, regardless of how stupid it is. You would expect that by now, people would know to expect them.
The second question is something that is hard, but I tell them upfront that I don't know the answer to the question, to put them at ease, and that I want to work with them together on the question. I also ask for pseudo-code, I don't care about syntax. I think this usually gives me a lot of insight into how good the candidate is. I had one recent candidate that wasn't a spectacular coder (he had bugs in his code and he couldn't see them until I almost had to point it out to him), but he had this intuitive ability to zero-in on the most efficient algorithm for both questions that I asked. I felt he was good enough to be hired.
However, some other members of the team, while agreeing with my technical assessment, rejected him because of culture fit. He was a bit aloof and kind of weird. Some of the team felt like he might not be pleasant to work with, so they thought it was better to be safe than sorry. So sure, technical chops matter, but so does personality.
I code all day. I don't have a whiteboard, I don't use a whiteboard. I can expect whiteboard-questions but that doesn't help anything. Am I supposed to practice them? Why can't you be happy just giving me a laptop, or a pad and paper, or something I'm used to?
I can code on a whiteboard, but it's certainly not something I enjoy. So when interviewing, I often ask for pen and paper. Just like a whiteboard, I have to write code without a computer and IDE, but unlike a whiteboard, I don't have to stand and write code in a position I'm not used to, with a tool I'm not used to (and let's be honest, whiteboard markers are kind of a pain to write with).
If I'm going to be disqualified based on my choice of writing medium, well, I probably wouldn't be that keen on working there anyway.
All of the above is fine with me. It doesn't have to be a whiteboard, it's just the term that I use to coding on the spot, which admittedly probably isn't accurate. When I interviewed at my current company, I did everything on a pad of paper.
Let me posit a couple things to my fellow interviewing engineers here:
1) I like to ask questions during interviews. I hate the whole "I'm a brilliant guy charade." I'm not. You're not. Einstein was. Deal with it.
2) And I especially don't have a care for rote memorization bullshit for things I can look up in less time than it would take me to remember. I'm a thinker, not a fucking textbook.
So, if you said to me "do whatever using x algorithm", and I said to you, "I don't know x algorithm by heart; could you tell me what it is, and I'll implement it in one of the languages I'm proficient in?" would that just completely turn you off to me as a candidate?
I tend to say, and this has not worked well for me, "Uh, I would google it, and see what other people have done, and learn from their experiences, and either use their license appropriate code, and or their knowledge and experience and consider that and how it would fit into our architecture and start from there".
Because that's how I engineer. I try to stand on the shoulders of others. And Google provides such an excellent step-stool.
But as I've said, that doesn't seem to go over well.
Implement your favorite sort algorithm? I don't know that algorithm, I tend to use the sort algorithm that comes along with the libraries of the language I am using on the assumption that a) it's good enough until proven otherwise, b) it's well implemented and mostly bug free by the language designers, and c) schedule is paramount, the most bummed out, tweaked out, sort is not.
Yeah, but this differs in what I'm talking about, in that I am going to prove to you that I'm good at doing the most important part of the task: implementing an idea into code.
I think, regardless of memorizing a specific algorithm, if I can prove that I can understand something after only knowing about it for a few seconds, and then actually create a mechanism that works with that understanding, that's really what an interviewer would want to see.
I thought that by telling them I would use google to learn what other people have already learned about the task, I WAS proving to them I know how to implement their ideas into code.
I am more worried about the folks that just jump into a complex project without seeing if someone has already done this beforehand.
Followup: (I can't edit my old post anymore), it's informative to actually read lots and lots of after-interview writeups where the candidate had an overall negative experience. Consistent problems emerge:
Glassdoor is awesome for this:
Some SV-companies with higher than average negative experience ratings:
Unbelievably disorganized hiring process by the sounds of it. Numerous, detailed reviews of interviewers simply not showing up, poor communication with the recruiting staff, etc. Weird cult-like experiences. It sounds like a cattle call. I actually couldn't find a company with a higher negative experience score.
Unbelievably poor communication. Amateurish interviews. No follow up from the recruiters, candidates are simply left in limbo.
There's a fair number of obviously bad candidates who were miffed. But there's tons and tons of people who were probably good candidates, but were simply jerked around for weeks on end. In some cases, the company's own internal processes are so broken they couldn't even conduct the interviews correctly.
> I am especially bewildered by the fact hard CS questions are given to prospective interviewers who will only be doing boilerplate PHP development for the actual job.
I agree. I think it's fun to solve these puzzles, but often they're of no relevance to the actual job. Better if they asked me questions from their domain or about the technology they're using.
I've long since abandoned trying to do programming tests when interviewing coders. Instead, I work through a problem with them in a sort of socratic method; I play devil's advocate to them while they flesh out how they'd approach the problem.
It's far more illuminating, and a far better reflection of their worth as a candidate, than their ability to go off into a room somewhere and work through a problem alone. I'm much more interested in someone who thinks well than who codes well (since the latter can easily be trained).
This is the same approach we've taken with candidates. We start with a phone screen and then a simple coding problem submitted via email. When we bring them in for an interview they spend time with with a few developers working collaboratively on a problem. If possible, it's a bit of work from the current iteration. Working together on real-world code has been surprisingly effective. I was skeptical at first, but it has been very helpful in weeding out candidates who had good cv's and probably could have coded a really great algorithm to traverse a binary tree but weren't great with solving real world problems.
Don't spend all of your time studying coding puzzles to answer questions correctly to people who are unlikely to hire you anyway. It's just a ridiculous waste of an intelligent mind. Spend your time building something interesting that actually helps the world. Build fun and interesting projects with this time. These projects might give you a career or a job that is smart enough to realize that you don't need to be given the fizzbuzz test.
It might not be advantageous to spend all of one's personal time figuring out coding puzzles, but I wouldn't be ignorant of the fact they will be brought up. Unless you develop an open source project which gets love from thousands of people and becomes very popular, few companies are going to use just that as a basis for hiring you.
Unfortunately, this also conflicts with the fact most people do need to make a living in order to survive. Unless it's possible for one to live without income from a job, then relying on "being noticed" will probably not be a fruitful avenue.
Yeah, the "be an open source coder to get a job" really doesn't scale. It already feels like I'm in a maze when I look for a tool to solve a certain problem, and have to wade through a bunch of projects that it takes a while to evaluate. The search costs are huge.
You probably aren't making the world any better by adding yet another open source project to it. If we want people to do this to get jobs, we are encouraging them to help drown us.
> In most interviews I’ve had, engineers and recruiters I speak to spend a great deal of time gloating about their product, almost as if they are trying to sell me their product. The fact of the matter is, I am not interested in being spoken to as if I would be a potential consumer of your product. I want to be spoken to as if I would be a potential employee working on your product.
Actually, as soon as you've decided not to hire someone, it actually makes sense to shift the whole conversation to "selling the product" and otherwise making it likely the person, who takes a job elsewhere, will either refer other (hopefully better) candidates, or use your product.
The product, like the customer, is a big part of the company and its history. As engineer, you can not just ignore it. I prefer say that the speak must not be limited to the product.
From reading the post, my takeaway is a guy who's probably going to struggle for awhile to find a position. When an engineer says that they only care about the technology and not the product, that would set off my red flags immediately. Frankly, in 99% of the cases, it's the product that pays the bills including the salaries of the team. If I had interviewed him, I probably would have suggested he look for a position in a R&D group in a large company with the funds to do that sort of software engineering.
I find many of the interview puzzles that people have posted on the Web that they've encountered at the Big Name companies as often a bit silly. Having said that, asking software developers to implement a solution to a common programming problem - "navigating a tree using recursion", etc. is perfectly reasonable. I've found more than a few software devs who have great looking resumes but who have no idea what recursion is, what a tree is used for as a data structure, etc. And I consider this the basic, easy, 1st year undergrad type stuff.
If there's an undercurrent to all of the comments here, it's that we still don't really have a good way to sift through the good from the really-not-so-good developers quickly. The programming tests and puzzles are a proxy for this and they only work so far - some people like to think through issues more before coding, or tend to freeze under this on-the-spot pressure. Doesn't mean that they aren't a good, competent developer you'd want on your team; my experience is that the guys who blurt out very quick answers can sometimes write the worst code.
I've seen so many posts about interview rants, including one I wrote myself, that I feel like the problem lies in the higher demand than supply of positions, and that interviews, not matter what bad feedback they seem to give, aren't that poorly designed.
You raise a valid point. Back in the old dotcom days, a body that could this thing called HTML got a job. While it seems we are in a tech boom (based on stories of 150K salaries in SF, oodles of stock options at established social media companies, etc.), perhaps we aren't. In the NYC area, my jaw has dropped when I see the large number of smallish startups working from co-working spaces. Are these people who shunned lucrative jobs or just couldn't get one?
I agree with this article that communication with companies is getting absurdly poor. With all these communications channels available, why is it so hard to send a quick email? Don't have time because of too many candidates? Maybe you shouldn't have more candidates than you have time to handle.
I've reached a point in my career where I'm not interested in engineering positions anymore (a great motivator has been to avoid the absurd SV-style interview). SV-style companies don't know what to do in these situations, they have an open position, I have the experience and skill set, let's have a conversation about the work I've done and what your needs are.
Problem is, nobody in the company knows how to hire for these positions and they seem to be done based on word of mouth or through the networks of the investors or other seniors in the company. In a couple of interviews at these companies, they plan for the usual all-day interview, and then I sit there in front of an interviewer who is simply at a loss for what to ask me.
On occasion they haul out a brain teaser, but I usually stop that with a "you do realize the position that you are hiring for is not one where solving brain teasers will be a reflection of the kind of work I'll be doing". This rings some alarm bells as some of the larger SV companies have found themselves on the business end of a law suit for this. Asking prospective project managers nonsense questions during an interview offers no information to the hiring committee about the suitability of a candidate. This can create a legal liability for the company if the unhired candidates feel they've been discriminated against -- especially if the company just hires somebody they know anyway -- proving that the position wasn't filled on a level playing field for all the candidates.
One other problem I've faced, I simply make too much money these days. In an interview with a now very large company that exactly matches the format in this article, I made it through the interview gauntlets and finally got to the compensation round:
"So what kind of compensation are you looking for?"
"Well, I made this much last year, I'd like to make at least that much this year and going forward."
blank stare of shock "y-y-you made how much?"
"Well, it was a mix of sources, my base was this, I made this much in bonuses and additional grants, and I was helpful in a few sales and earned this much commission. I don't expect that this job is commissionable, but I'm open to alternate mixes of compensation so long as my base stays about the same."
"y-y-you realize not even the CEO is pulling down that much base?"
"I'm afraid I'm not privy to your company's compensation packages, but I know that the CEO reported a few tens of millions in stock grants last year, I'm not expecting that much, but if you feel the need to offer a lower base, I'd like to expedite the vesting schedule by a year then"
"I-I-I.....I'll see what I can do."
And that ended that job right there. I received a very nice call with a rejection a week later.
Another anecdote, a friend of mine interviewed for a VP position with another major SV company, he got through the initial rounds based on his education (Ivy-League) and other credentials. During the interview they decided to do the equivalent of an engineering-style interview...the recruiting team had clearly dug deep into the bowels of some undergrad finance textbooks, and asked him to derive a number of finance formulae he hadn't seen or cared about in 20 years. It was utterly random and doomed to failure. He went on to other companies where we was quite successful, while that position remained open for the better part of two years before finally being filled with a friend of one of the investors.
The best places I've worked (as an engineer and otherwise) have been the ones that don't engage in this nonsense. I can see a simple fizzbuzz test being a prescreen as being useful, but just sitting down with a candidate and having a conversation about their resume seems to work best. Bonus, it's respectful of the candidate. Unlike a great many companies, you've actually taken the time to look at their resume. If you recognize something on the resume, ask them some penetrating questions and dig into what they know. If you don't recognize something, engage them to teach you about it. Competent people are competent at talking about their job. Ask them things like "can you give me examples of where you applied algorithm design or at least some complexity theory in a job?" If they give an example, probe deeper, have them talk in depth about the algorithm, see what they remember from their undergrad about big-O. Or "what was the most difficult integration you've ever faced?" followed with a "why?". Dig in, make it a conversation. Let them become a teacher during the interview, where they teach you about what they know and about their life. Ask questions like a student would. It's respectful, humble and draws unbelievable amounts of information from a candidate.
You'll quickly learn what kinds of things they know, what they don't know and what they're weak at. You'll also learn about their soft skills, like communication. Instead of playing an insipid game of cat and mouse, you'll learn about the person you're hiring. Ain't that what YC looks for?
This is a good comment. Some nits I'd like to pick:
* Companies aren't required to provide a level playing field to applicants. I think you've alluded here to discrimination against protected classes; that is, you're suggesting that someone could get an unnecessarily hard interview and use it as evidence that they were constructively rejected for their race or gender. That could happen, but most companies probably use the same terrible interview for everyone but their friends, which, while unethical, is lawful.
* In our experience, the resume conversation is the second-worst hiring signal, after the trivia interview we're discussing here. The ability to sound smart while talking about your experience involves a set of skills usually disjoint from those of the job. Every hiring mistake I've made in my career has involved someone who could "talk the talk"; in fact, many times, those people can also, if forced at gunpoint, "walk the walk", which makes their unsuitability all the harder to spot.
I'm an advocate for work-sample tests: have a standard set of (reasonably small) problems that are representative of the work you do and give them to all candidates so you can grade them. After we started doing this, it quickly became apparent that I didn't even need to have much insight into what reasonable or "good" solutions to our challenges were, because I could just look how good hires/candidates had solved those problems in the past.
That could happen, but most companies probably use the same terrible interview for everyone but their friends, which, while unethical, is lawful.
Wait, why is it unethical? It's frustrating and inconvenient and sucks for everyone but their friends. But, unethical? On what grounds? I don't have an obligation to give strangers the same favors I give my friends, do I?
You have an obligation not to waste people's time, especially if you are putting up the facade that they might actually be in the running. The modern interview process can take weeks or even months to get through. If you're just going to hire your friends, can you give the other candidates those weeks or months of their lives back?
The whole premise of interviewing and opening to the pool of candidates is to evaluate and give every applicant a fair chance after passing a minimum bar. If the whole point was to favor or employ someone (pre-decided or friend), then why this facade?
If you have a preferred candidate for a role and that candidate isn't being vetted by exactly the same process as the rest of the candidates, you're obligated to disclosure something to that effect. You might not come right out and say "you should know, we have a preferred candidate", but you need to say something.
I like to partition companies with products that gain traction into two groups. In the first group are technically mediodcre founders who cobbled together a product that's almost unmaintainable. The second group consists of relatively experienced founders who cobbled together a product that's maintainable.
The two groups use distinct interview styles. Since the group with nearly unmaintainable code has many more members than the latter we see their interview style far more often. This is the familiar all-day brain teaser and relentless quizzing interview style. This interview style makes sense for these companies because they need warm bodies to throw at legacy codebases. The quality to seek in employees is perseverance and obedience. And this familiar interview style tests for just that.
The second group of companies uses the more thoughtful interview style. The founders value insight, creativity, and experience more than obedience. Hence their interview style focuses on these qualities.
> The quality to seek in employees is perseverance and obedience. And this familiar interview style tests for just that.
I know some actual interviewers who ask these types of CS heavy, puzzle based, brainteaser type of questions. They say that their rationale for asking questions like this is to gauge the candidate's attitude and to see how they behaviorally respond when presented with this kind of problems. In many ways, they are testing for submission in candidates. Basically, if you up and leave when asked how many manhole covers there are in New York, their system worked perfectly: they weeded out a candidate who they think would be an entitled prima donna. Corporate environments often require foot soldiers who will do the job without complaining, hence the testing for absolute obedience.
I disagree with this tactic but unfortunately it is quite widely employed during the selection process.
If the bar for "absolute obedience" is not storming out of the room when asked a dumb question, then yay for absolute obedience.
Someone who really was the superstar candidate who shouldn't be bothered to answer pointless riddles would surely have the communication skills to tactfully change the subject to how they're the best candidate for the job.
This is why I don't respond to any solicitations anymore. It's apparently against the laws of the universe for a job candidate to initiate the discussion about money, but there are a lot of inexperienced hiring managers that don't know that people might be already making more than the position could possibly pay.
One interview in particular, I got past the phone screen, got past the technical interview and got past the interview with the CIO. He starts talking about when I can start, setting up my PC, etc. He says, "oh, oh, what do you make now?" I told him and his smile literally melted away and he said, "Well thanks for coming in."
> I made it through the interview gauntlets and finally got to the compensation round
Unless they have a rigid compensation banding structure or are on Glassdoor, recruiters/HR usually ask ballpark salary requirements at first contact to avoid this kind of thing, which I think is a legitimate inquiry. Though, if they insist on current salary they're probably looking to low-ball you.
It's almost always at the end. I wish it were closer to the beginning to save everybody time and hassle.
For regular 'ol companies it's more about seeing what you want, most places will actually try and hit your desired salary so long as they can make some money on you.
For SV-style companies it's different. It feels different. When you get to that point, it's almost like the tone of the conversation becomes "now that you're really impressed with us, and we've decided that we'll let you into our exclusive club, how low can you go? We'll reward lower salaries with more options that'll probably not be worth anything by the time we hit a point where you can exercise them. It'd be even better if you could pay us for the honor of working here."
You could do things like consultants, and ask a binary "Do you have budget of at least $XXX,000" up front, particularly if you have the flexibility to not worry about chasing away marginal prospects.
I only know of a few that I've heard of through my personal network, but don't have any specific citations I can point at. Even if the candidate loses the lawsuit, the cost of handling them is probably more than any company is willing to take on, just easier to drop the riddles instead.
I wonder what would happen if perspective job seekers just say that they won't do coding questions in interviews? Moreover, if they insist that interviews can't be longer than 1 hour total, with a maximum of 1 phone screen. Oh .. to top that off, candidates insist they get told their fate within a week or less by email. If only ...
As a candidate, I like coding questions. There are certain jobs where coding questions are usually not worth it ("we need someone to code up this website in PHP"), but I'm not looking for those jobs.
"Don’t sell me your product, sell me your challenges"
I actually care about the product equally if not more than the engineering challenges. I write code to build products and businesses, not for the sake of engineering. I'm a bit different though :)
>>Almost always, communication is done over email with a recruiter, and the average response time is several hours to a day.
How about trying a different method? Instead of emailing a recruiter (or the company), try calling. This is signaling that you're more serious than someone who's just following up with an email (think of the volume of the candidate pool you're in) and distinguishes yourself. Even better, at the end of the interview you could plant the seed for a follow up, like "It's been great meeting you, blah, blah, blah…I'd like to check in with with you next Tuesday (or whatever) at 10am with a brief phone call, as I've got other positions to consider and I know you've got other candidates…"
>>They then emailed me asking if I’d like to stop by their office for a few hours for an on-site interview. I responded after a couple days…
then later the OP says
>>larger companies, such as Facebook, Amazon, or Apple, are very expedient with scheduling and setting things up, and keeping the loop. This is extremely to their advantage.
Time is of the essence, but I understand you might have been busy. Probably not too busy for a quick follow up email to set up the interview. And, if you don't hear back anyway, be tenacious and call them.
>>A friend told me that I should take the strategy of sending email after email until they give me some sort of response. (“Stop sending us damn emails. We don’t want you.”) I’ve not really done this, but I’ve done more than what I think I am responsible for doing…
Responsible for doing? A different way of thinking about it would be to think about being responsible to yourself, not them. You want the job; are you doing everything you can to get this job? See stuff by Ramit Sethi for interview tips.
I have also encountered this while interviewing for the couple of jobs. I thought I did not study well and that's why could not solve the problems in front of the interviewer! In fact, when I am able to solve bigger problems while developing live projects. Nice post and it echoes something which has happened to all of us at some point in time.
I much prefer medium sized offline coding challenges, both for myself and for hiring my team. You give a good engineer a small project to work on, an he should crush it. Because that actually has something to do with what engineers do on a day to day basis. Personally, I get the job pretty much every time if I am told to build a small project, and I crash and burn almost every time if I get the SWAT team of surly technical interviewers.
It's worked fine for me because the small companies I like to work for are more apt to give out the projects, but still I could do without some of the awkward interviews I've gone through with companies who use the Google-like process.