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.
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.
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.
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 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.
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.
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.
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.
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?
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.
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.
> 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?
[+] [-] balloot|13 years ago|reply
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.
[+] [-] wowoc|13 years ago|reply
[+] [-] brightsize|13 years ago|reply
[+] [-] Kurtz79|13 years ago|reply
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.
[+] [-] negrit|13 years ago|reply
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."
[+] [-] rm999|13 years ago|reply
[+] [-] mc-lovin|13 years ago|reply
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.
[+] [-] bane|13 years ago|reply
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.
[+] [-] dirktheman|13 years ago|reply
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.
[+] [-] manish_gill|13 years ago|reply
[+] [-] abhiv|13 years ago|reply
[+] [-] nilkn|13 years ago|reply
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.
[+] [-] ecspike|13 years ago|reply
[+] [-] k__|13 years ago|reply
I mean, what puzzles can I give a recuiter to test things relevant to me?
[+] [-] dirktheman|13 years ago|reply
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.
[+] [-] stevewilhelm|13 years ago|reply
It is much better to filter out some perfectly good candidates than accidentally hire the wrong candidate.
The wrong hire can be very disruptive, and in some cases fatal for a company. Firing the wrong hire is very, very hard.
>> but it seems it's almost easier to raise money for your startup than to get a job
Raising money is like interviewing for three jobs at once: CEO, CFO, and CTO.
[EDIT] removed some platitudes and fixed fatal.
[+] [-] ecuzzillo|13 years ago|reply
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.
[+] [-] ultimoo|13 years ago|reply
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.
[+] [-] bane|13 years ago|reply
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.
[+] [-] wowoc|13 years ago|reply
[+] [-] jmaskell|13 years ago|reply
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.
[+] [-] yitchelle|13 years ago|reply
[+] [-] danielweber|13 years ago|reply
I think this is just the "shit rolls downhill" version. Companies don't want to ever say no to a candidate. They can always come back to you later.
But, really, if anyone should know how much the "never say no" routine sucks, it's the companies hunting for VC.
[+] [-] bengillies|13 years ago|reply
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.
[+] [-] woodchuck64|13 years ago|reply
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.
[+] [-] ttrreeww|13 years ago|reply
[+] [-] estebank|13 years ago|reply
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.
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. 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.[+] [-] reikonomusha|13 years ago|reply
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.
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.
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? 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.
[+] [-] Schwolop|13 years ago|reply
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.
[+] [-] lutorm|13 years ago|reply
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.
[+] [-] orangethirty|13 years ago|reply
[+] [-] steven2012|13 years ago|reply
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.
[+] [-] nfoz|13 years ago|reply
[+] [-] dclowd9901|13 years ago|reply
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?
[+] [-] jerrya|13 years ago|reply
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.
[+] [-] bane|13 years ago|reply
Glassdoor is awesome for this:
Some SV-companies with higher than average negative experience ratings:
http://www.glassdoor.com/Interview/Zynga-Interview-Questions...
Lots of "after the interview I appeared to have been dropped into a black hole since nobody's told me if I've moved on or not".
http://www.glassdoor.com/Interview/Palantir-Technologies-Int...
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.
http://www.glassdoor.com/Interview/eBay-Interview-Questions-...
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.
Some with more positive ratings:
http://www.glassdoor.com/Interview/Facebook-Interview-Questi...
http://www.glassdoor.com/Interview/Google-Interview-Question...
http://www.glassdoor.com/Interview/Amazon-com-Interview-Ques...
http://www.glassdoor.com/Interview/Microsoft-Interview-Quest...
See the difference in the candidate responses? You're doing something right if people get rejected but say they had a positive interview experience.
[+] [-] maaaats|13 years ago|reply
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.
[+] [-] robmil|13 years ago|reply
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).
[+] [-] leklund|13 years ago|reply
[+] [-] dsowers|13 years ago|reply
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.
[+] [-] reikonomusha|13 years ago|reply
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.
[+] [-] krat0sprakhar|13 years ago|reply
Spot on!
[+] [-] rdl|13 years ago|reply
[+] [-] olivier1664|13 years ago|reply
[+] [-] lutorm|13 years ago|reply
[+] [-] bokglobule|13 years ago|reply
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.
[+] [-] bluepanda_|13 years ago|reply
[+] [-] throwaway1979|13 years ago|reply