The objective arguments are sound, in my opinion. I don't care for the flippant insults like "assholery," but I'm a big boy, I can filter these out.
One thing to remember about interviewers that ask poor questions is that many such people aren't full-time professional interviewers. They are to interviewing as a marketing manager who does some Excel scripting is to programming. They are often repeating what they've heard or read or been subjected to, much as an inexperienced programmer tends to use whatever programming pattern was espoused in the last blog post he read.
A terrible interviewer may still be a wonderful person to work alongside, just as someone who performs poorly under the pressure of an interview may be a fantastic programmer once hired and working on an actual project.
someone who performs poorly under the pressure of an interview may be a fantastic programmer once hired and working on an actual project
Maybe. But then again if I have one spot open for the quarter then I'm probably not going to take the chance on someone who crumbles when asked how to get the duck safely across the river or whatever.
And if a good programmer has a choice of employers (and they do), they probably aren't going to take a chance on someone whose idea of evaluating their skills is to ask how to get a duck across a river.
If that's the only thing asked during the interview then I might agree with you. It really never is, though, is it?
Seriously, do you really want to work with someone who's too uptight to answer a couple of harmless riddles during the course of the interview process that includes a host of different methods for transferring information?
Yes, I do. Too many times I've worked with programmers that were pushovers to inane edicts from management, whereas if just a few had said, "I see what you're trying to do, can we accomplish this in a more efficient manner by ..."
This. Also bear in mind that it is widely publicised that google and MS etc use these sorts of puzzles in their hiring process (whether or not this is true I have no idea).
So there's a certain element of "if it's good enough for.."
My google interview was the best part of the whole time there to be honest. If the work had lived up to the people and problems presented in the interview, I would still be there, happy as a clam.
Instead, it was a complete forced bait and switch onto a team doing something irrelevant to my skill set, which is my way of saying there are plenty of problems with Google, but this is not one of them.
I've heard this a couple times now, and it worries me. I've got an on-site interview with Google soon, and my impression from the recruiter is that I would know which team I was joining at the offer stage.
Can you go into some detail on what happened between your offer and joining Google that resulted in you feeling like it was a "bait and switch"?
If it matters, I am not interviewing as a college hire, but as a senior engineer from another large tech company.
[I apologize in advance, I think I got a bit snarky there at the end]
Historically Google doesn't allocate jobs and then hire to them, rather they hire and then from the accepts various managers 'bid' on those candidates to fill their needs. Clearly I am a bit biased as I joined Google as a 'senior' guy, and went through this stuff, spent four years there, and now I don't work there any more. Its not for the faint of heart.
The reasoning for this is that smart people can do "any" job[1] and the when people join Google its so "different" than any other culture that your first assignment really won't matter anyway. The theory is you accept, they throw you into some random job, you get evaluated (used to be this was when your job level was also determined) and then you are expected to know what you want to work on, move there and work on it.
This system is especially hard on senior folks, it works ok on new college grads. As a senior engineer you can be assigned to write shell scripts that take the output of one program and make it input to another, or clean up performance issues in a code written by someone who had no idea how to write performant code. You are almost assured of landing on a project where the original developers of it have collected some 'cred' for "shipping" it after getting it 90% done and have moved on to something else. It will be the biggest waste of your time that you could imagine.
The good news is that if you survive that gauntlet then your next assignment will be to get yourself out of the cesspool you landed in and into a project that you care about. The bad news if you don't create as much code as the young guy who is in the cesspool next to you but does his laundry at the 'plex' and eats three meals a day there, then your not going to do well on your evaluation. A good defensive strategy there is to do several side projects with folks at Google to build up a 'yeah he's a good guy' kind of relationship with folks on the committees. That way when the question of how many kLoc you produced comes up relative to your live-at-work cube mate your friends on the committee can counter the negative remarks with 'but hey, he's a really great guy.' which will help.
Now that you're successfully "in" learn to fail fast, go through a bunch of projects looking for one that will show up on the radar of some influential (low employee #) folks, there is a great tool called 'percent' that tells you how many folks joined after someone, you want to cultivate the 99.9 percenters. They will always be on the various committees that will be evaluating you at some point and you want them to both know who you are, and have a positive impression. Shine their shoes as they say. If you're an academic many of the tools you used to get your grant money, grad students, or onto the front of the author list on papers will serve you well here.
Once you've reached a level of credibility that your "calibration" score is pretty much not going to get knocked down because some early employee is pissed off at you, start thinking about what sort of problems you would like to work on. Go look for them and get yourself on the project, do the fun stuff (the wild designs, the crazy idea papers, the mocks, the prototypes) get it to the point where it works enough that it is clear it will actually work if someone finishes the code, "ship it" and take the credit, relish in your big bonus that year knowing that some new hires will be dummped into that project, now that you've moved on. to make it work. Not your problem any more, you're on to bigger an better things, your a Googler!
[1] I think of this as the 'fallacy of fungibility' where any employee can be moved to any job, when in fact depending on fit they may do well or poorly unrelated to their skill set.
And this is just it, I was indeed senior level. I do not have the patience to play a cultural game internally just to get to a project that makes use of my skills. My bad.
If that makes me a bad cultural fit, G O O D! If a company isn't smart enough to pair me with a problem I am adept at solving, then plenty of other companies are, and that's why I left after only 4 months. Got a raise too.
Google's hiring process is toxic[1]. It's probably costing them big bucks that they can't quantify properly as a line item in their budget so they probably won't consider changing. All I know is that whenever I recount my days at google on HN, lots of people upvote my story, a lot. I suspect others have similar tales to tell.
[1] Not that other companies don't have their own personal poisons, but yeesh, why not try something new once in a while?
I had an interesting conversation with Alan Eustace (who was in charge of engineering at the time) about this. We had just hired, abused, and lost a guy who had been the CTO of his previous company, got hired in and forced to clean up message catalogs in i18n code, and quit after the slotting committee decided he was really 'junior engineer' level and should be put on a performance improvement plan so that he could learn to "step it up."
I don't know how common his situation was, I was fairly outspoken (no surprise) and he had reached out to me early on when he was trying to figure things out. The PIP (which is basically a pre-cursor to being fired) basically put him over the edge, and he quit. The sad thing was of course this guy was really smart, had excellent design sense, and knew more about the way Java worked than I did and I was one of the original developers of Java at Sun! A real top notch kind of guy.
He had been caught in the 'perfect storm' of which there were many, of a manager whose project was strategic to the company and understaffed, a skillset that waaay out ranked his assignment, so even doing perfect work it wouldn't begin to show his capabilities, and a 'peer review' system that primarily tested social engineering skills rather than technical skills. Everybody lost. He lost his job, Google lost a great engineer, the system lost an opportunity to improve.
The essence of the discussion with Alan boiled down to "Its a complex system and its going to have some failures, but by and large it works well so unless you can come up with something better we're stuck with it."
So in some ways the interview process is a good test to see if you might be the kind of person that would do well at Google.
Well, given that I aced the interview (plenty of evidence besides the job offer I got within 24 hours of it and some of it I probably shouldn't know but I do), I should have been a wonderful fit then, no?
Tell ya what, how about trying one of those infallible(tm) A/B tests where half the incoming people get the Hogwarts hat and the other half get to meet their team upfront before accepting a job? Do this for a year. Now one year after that measure which set of employees is happier/present/more successful.
That does sound a bit jaded, yes, although I completely agree on the fallacy of fungibility. It's a trait shared by my current employer as well, though, so I don't feel I'll be any worse off on that front.
I'm still likely to make the jump if they make me an offer that's a decent bump where where I am now, but I suppose that's because I'm a bit jaded myself.
Well I can completely recommend working for Google as a way of helping to calibrate what you will or won't do for a 'decent bump' :-)
To its credit there are lots of great people there, and the parts that work well are insanely amazing. I marveled at how you could have both the best and worst day of your career on the same day at Google. My failing is that I tend to care too much about problems that aren't going to be solved.
Was the percent tool written with cynical intent? Or was it a simple in-joke, perhaps, among longstanding members of staff amazed at Google's growth? I'm not really sure what, if anything, I should read in to the tool's existence...
I don't think there was any cynicism in the creation of the percent tool, it was a way to see how fast the company was growing. Although when you thought about it you could draw interesting insights from the data, for one if you used it on yourself you would see the number of people hired after you growing fairly rapidly, more rapidly in fact than the total number of employees was growing. From that piece of information you could ascertain the 'stick' rate of hires, which is how many people stayed around for 3months, 6months, a year, 2 years, 4 years. All the usual peaks and valleys.
A lot of people interview thinking they are going to work on Google Glasses and then get allocated to corporate IT. You don't know your role at the company until the day you start.
Yes, I suppose what I'm looking for is where exactly things go awry.
Again, the impression I'd gotten from my recruiter is that I'd have more or less a commitment from Google that I'd be working on a particular team at the offer stage. In particular, that I'd know which team I was going to work on when I accepted the offer.
So it seems like either she's exaggerated that (in which case I would expect it to seem fairly obvious at the offer stage that you weren't yet assigned to a team), or that Google is in the habit of outright lying about team assignments, which I have a hard time buying.
For me, allocation, period. For all the investment made by Google in hiring me, and all the personal debt I accrued in leaving my previous employer and renting an apartment in Mountain View, it all came down to getting hosed by Google's version of the Hogwarts selection hat.
All attempts to address this were blocked by mid-level management, leaving me no other options other than continuing a job I hated or leaving. Even engineers within google who had worked with me in the past and vouched for me couldn't make a difference.
Google's allocation process is akin to Russian roulette and I got the chamber with a bullet in it.
So I left.
Now there is hope. Just like Jamba Juice lets you order off-menu smoothies, Google will let you pick what you want to do if you can find a team that will accept you. They just don't talk about it. Insist on it and I suspect you'll be fine. I wish I'd known that bit before I went there.
My experience interviewing with Google (a couple of times in the last 3 years) is full of what can be considered "riddles". They weren't obvious riddles, but where questions "to know in advance", specially considering the short amount of time to answer them.
The second time I got quite frustrated about that, specially on the last one after doing a couple interviews before that I was happy with the kind of questions I was asked (relevant and intelligent), so I'm not probably going to give attention to Google recruiters any more.
there are definitely questions where you have to think of the right general algorithm and datastructure very quickly, and then spend your time refining it for the details of the problem, but i'd argue that that's not in the same "aha!" class as actual riddles.
Well, knowing the O performance of some sorting algorithms, is not what IMHO can be defined as "we want to know how you think". Or implement, in a very short amount of time, tree algorithms.
I mean, they are not totally 'aha!' things, but they are the kind of things that you could nail one day, and be completely stuck another. And quite irrelevant to your work (as is highly unlikely that you'll ever implement it)
On the other hand, questions about how and why to use this data structure or another, are totally relevant and interesting. And shows way more that you have been using them and know what are the differences.
Again, is just my opinion (and Google can do their interview process as they like, they are obviously doing fine in getting a great team!), but my impression is that gives a lot to chance or inspiration in some interviews, and giving their process, one mistake could be all you need to be out.
Both Google and MS have banned such riddles from their interviews, because they have been proven to be ineffective and results in large numbers of both false-negatives and false-positives.
I mean source that they result in a lot of false negatives and false positives. If Google kept stats on the rating engineers got during the interview and how they went on to do at the company, this would be a good starting point for objective evidence.
I don't have a source for this, but as an interviewer, simply thinking about what I can get from a riddle indicates it's probably true. I have a mental checklist of about fifteen items that I try to get answered when interviewing a candidate, and asking riddles would barely if at all help me answer any of them.
That's not to say they're worthless, but when I have an hour or so to interview a candidate, they're not an effective use of my time (and I imagine that most candidates would think it's a lousy use of their time, too) - I ask questions that can answer four or five items on my list, not one if I'm lucky.
Seems like that was only true in the past. I've even had a Google interviewer tell me something along the lines of "I don't have a lot of questions picked out ahead of time cause they've told me I can't ask puzzles anymore" so hopefully that new state of things will trickle down in time.
Google and Microsoft don't ask those kinds of questions. Both of them primarily ask questions related to algorithms and data structures, sometimes with a bit of software design thrown in.
Source: I work for Google and have interned for Microsoft.
Why, it's almost like you should have programmers program during an interview.
A previous company I worked for did that. Build a small ad-hoc team of 3-4 people (with 1-2 existing employees, as knowledge repositories), and let the candidates work on a sort-of real problem for pretty much a day.
Every team member occasionally came in and watched for a while, every team member looked at the repo for the end results, and the "embedded" people gave feedback on how it felt to work with the candidates.
Yes, it's expensive. But so is a mishire, and it sure did work well to filter people out.
Having spent the last year interviewing for jobs. It has become clear to me that companies have no idea that they're being interviewed as they are interviewing me.
Can't find a time to call me when I've given you 5 dates and times? Red flag.
Can't get my resume into the hands of the folks who are interviewing me? Red Flag.
Tell me it will be a week and it takes two? Red Flag.
Call me 30 minutes after the scheduled time and not apologize. Red Flag.
Tell me I'm a perfect fit for the job, then the HR person calls me 5 minutes later to say that they will not be moving forward with the interview process. Red Flag.
Set up a time to Skype call me, cancel hours before the call, send an email 2 days later saying the job was filled before my interview. Black listed
Tell me on the phone interview that I will be called in for the face to face, send me an email 2 weeks later saying the job was filled. Black listed
Delay the hiring process because you want to hire another position first. Red Flag.
I could go on, and all of this has happened in the last year.
From my experience with interviewing in SF, most companies don't have a Human Resources department. You're mostly dealing with people who are winging it.
The timing issues you described are rampant. In my opinion, that is because there is a tension between companies fearing that they will find no one to hire and trying to find the best candidate for their money.
The textbook way to hire is to publish an ad and set a closing date for weeks later when you will start considering candidates. You interview everyone in an orderly fashion and make your decision at the end of the process.
I think that some companies will argue that they can't wait for 2 weeks to collect resumes because the early applicants will get snatched up by another company. Though, in my opinion, I'd rather know how long I am waiting than to be subjected to delay tactics every few days.
| Tell me it will be a week and it takes two? Red Flag.
The thing that frustrated me the most about dealing with DeviantArt's interview process. No specific timelines, and 'soon' could mean anything from a couple of days to 3-4 weeks (with no response / contact).
So, you'd regard a candidate as lacking integrity if you scheduled an interview with them, but they then cancelled because they'd accepted another offer first?
Yes I would and this happened when I was on the other side. The candidate reached out after 2 weeks and asked if the job was still open and that he had made a mistake. The job was filled.
So, knowing that he was going to take another job, you'd rather he still came to your interview and used up hours of your employees' time? To me, that's the action that would lack integrity.
Your example of the guy who made a mistake is certainly a bummer for him, but presumably he didn't know he was making a mistake when he turned you down. And that's got to be a very small fraction of hiring situations.
I think the integrity test came when he made up his mind and accepted an offer before the interview. If I knew he had already accepted the other position then it would be a waste of time.
The problem wasn't that he cancelled the interview, it was that he made up his mind before a scheduled interview with me.
The difference between a Red Flag and a Black List, is that a Red Flag I might forgive given circumstances. A Black List means I'll never apply again, and often call or email to remove my resume from their database.
I'm not sure the author understands the difference between a riddle and a logic problem, a riddle typically uses misdirection and veiled meanings to hide an answer while a logic problem is one that can be solve by applying logical analysis.
So for example "What has two heads, four eyes, six legs and a tail?" is a riddle because it's so open ended and relies upon linguistic trickery. On the other hand most bridge crossing problems are logic problems, you typically have a finite number of options and by deduction and logical analysis you can arrive at the correct answer (i.e the answer is not a trick answer).
The advantage of logic problems as opposed to domain specific problems is that they let you separate an individuals logical reasoning ability from their experience. When you're hiring you want to make sure that the person you're hiring can deal not only with more general problems of the type they've seen before, but also that they can deal with esoteric problems that are very specific to the nature of your product. And that's when the ability to reason logically becomes much more important.
Obviously if the candidate you're interviewing is already familiar with the logic problem you're presenting then you probably won't get much value from the candidates answer and you need to ask alternative questions to ascertain the same information.
I think this should be taken with a grain of salt, and I say this specifically for this crowd, who I've noticed more and more aren't the prospective founders and outliers that it once contained but young, inexperienced new-grads or almost-grads that are just getting into the business and think starups are a good option.
My advice, to be blunt, is this: Know your role.
It's all well and good to rail against these (frankly) really dumb hiring practices. A lot of us are in the position where we don't have to put up with this crap. Of course a lot of us are in the position where we aren't interviewing at all anymore. Simply saying "I did such and such in the past" or even better "I worked with so and so" is good enough for many of us to land nice cushy gigs. Such is the benefit of a reputation, and you will build one, one way or another, in whatever niche you are in, over time.
However, young Padawan, this is not you. Not now. You - like it or not - are simply a number on a job application. And discounting the few who are lucky enough to have completed a project that means something in your short lives, or to have the fortunate grace to share acquaintance (and high opinion) with someone the hiring person knows and respects, you are NOT "interviewing the company".
You are a nothing. And just like all the other nothings that come through the door, if you want to get noticed you need to find a way to stand out from the crowd. You will likely not always be a nothing, but right now, you are. And so, your lot in life is to jump through hoops and toe the line until you can start to stand on your own two feet.
Please don't take the approach that the interview is an equal transaction unless it actually is. I've 'not hired' far too many of you, to be honest. You'll know when the transaction is equal, and if you are asking the question, it isn't. That isn't to say you should take any offer that comes to you; just that you are in no position to be picky. And if you are bitching about interview questions, this is the position you are in.
By the time I was done interviewing someone, they weren't a nothing to me any more — I had an idea of who they were. The whole point of an interview is to cease being a nothing and gain the respect and interest of the interviewers; if you're interviewing people as though they're nothings, you may notice that a lot of your best candidates turn you down. Finally, everyone is interviewing the company; if the interviewee isn't willing to turn down an offer, someone will take advantage of them.
Of course a person isn't a nothing. The issue is that many recent grads (especially those that are smart/have done well) somehow seem to forget that as far as the work world goes, they are back at the bottom of the pile.
I'm simply pointing out that many of them - particularly in this generation - don't seem to have any idea of their overall place in the grand scheme of things.
There are close to 50 years of "top of the class" grads floating around out there. That's the competition.
if the interviewee isn't willing to turn down an offer, someone will take advantage of them.
While I don't disagree, the fact of the matter is that a new grad rarely, if ever, has this luxury. It's true that it may very well be in their best interests to not take a job despite not having an income. I've seen far to many though that never get the right start because there idea of "being taken advantage of" is so far out of whack with reality that they don't take any viable position. Given 1-2 years of unemployment, they become less and less valuable, and more and more desperate.
9/10, as a new grad, you should take an appropriate offer from the first company that makes it. The experience you need is much more valuable to you than the interview quiz, the dress code, or yes, even the pay.
I'm not quite sure why there are so many negative responses to this, the tone is rather direct and harsh (the author admits this was intentional below), but the general sentiment seems spot on.
The target audience for the OP is people who have leverage in a Job interview situation, people who have experience and who have a number of options to pick from (ie. Any decent developer with a project or 2 of successful practical experience under their belt).
The parent is simply saying, that before you blindly follow the OP's advice, make sure that you are definitely in the category of people who have the luxury of doing so.
You can see by the vitriol in the responses that I've hit a nerve - people know what I'm saying to be true, they just hate that it is so, and they hate me for pointing out that it is so, and being unapologetic about it at that.
Such is life. I'm less concerned about what names people call me than who is doing the name calling. Random people on the internet obviously don't know me well enough to matter, really.
What comes across very clearly is that you talk like a tremendous asshole who I wouldn't want to supervise, let alone work under. Someone getting paid less than you doesn't entitle you to talk in this incredibly abusive way to them.
Get some perspective. Knowing some people doesn't make you a badass. You are a nothing who knows some people. Big deal. Lots of people know some people, including total idiots. Not knowing some people doesn't make your juniors garbage.
Anyone who wants to work with nice, cooperative people will avoid any shop which represents itself in this absolutely toxic way.
I'm going to explain myself further because I truly believe people like yourself are simply ignorant, not stupid, and I'd like to tell you the things I wish somebody told me. It would have saved me a few years of misery.
I'm not here to be your friend. My post is laying out reality for you whether you appreciate that or not. The simple fact of the matter is that the person doing the interviews is interviewing many more people than you are attending interviews. As I said - Know your role.
Keep in mind that all the people over 35 have probably faced the same situations you will face in your first 5 years of employment numerous times. That means that although they don't have all the answers, they do have the benefit of having actually lived through several outcomes. This counts. A lot. You do not have this perspective. Understand this and you will go far. Refuse to accept it and you'll likely make the same mistakes they did.
Knowing some people doesn't make you a badass. You are a nothing who knows some people. Big deal.
I don't see where I said that at all. I said knowing people (assuming knowing also means "receiving respect from") opens doors. Not knowing people keeps these doors inaccessible to you. Don't bitch at me, this is simply the way the world works. If you haven't figured that out yet, you're in for a world of issues.
Anyone who wants to work with nice, cooperative people will avoid any shop which represents itself in this absolutely toxic way
And anyone that wants to work period will understand that utopia is a myth. I'm not seeing my generation under-employed and serving lattes at Startbucks because filing is "beneath them" or "the company asks riddles at the interview". You aren't in a position to dictate your terms (yet). More importantly, you'll never get to such a position if you don't understand this now!
There are times in life to be humble and deal with stupid riddles, bureaucracy, stupid policies and yes, even the asshole boss. When you are young and starting out is probably the textbook example. You can bitch and moan about how the world is awful and life isn't fair or call people that don't support your worldview assholes, as children do, or you can understand that you are once again at the bottom and work a little bit harder, a little bit longer, producing a little bit better results than your peers, and move up the chain a little.
Your choice, not mine. As I said, I'm in a different world now. I can (and have) walked away from things I don't like, been poached by other companies, and don't remember the last time I actually responded to a job ad. You probably will have that too - I'm not exactly special - but not anytime soon.
You are not entitled to verbally abuse other people, and this is not changed by waving your hands at the "real world" or how you are supposedly doing me a favor by explaining that you are not the only asshole (I am likely older than you).
Anybody of any age with a sense of self-worth and morality will not work in the kind of toxic environment you are defending as necessary. Utopia doesn't exist, but avoiding people like you is all too possible.
You are directly calling me an asshole (twice now) and you are mad because I "verbally abused" someone (who, exactly?) by saying they are nothing?
Seriously? Dude, if you can't handle your emotions well enough to handle a person saying something that you find personally uncomfortable, you probably aren't ready for life yet.
Perhaps you need a discussion more to your personal liking; reddit is that way ->
I'm definitely calling you an asshole too and a very big one at that.
You're tone (in your very post here) isn't acceptable at all.
People bullying youngsters (I'm in my 40s, thank you) by telling them they're "just a number", "your lot in life is too walk on your toes", "your are a nothing", "what you've delivered doesn't count", etc. are assholes.
And it's a fact.
And just like the other poster here (pekk), I pitty people who have you "above them" in any hierarchy because you're personality is seriously disturbed to say such things.
Don't try to justify the behavior of your post. Talking like that about people isn't acceptable.
That's why you get insulted openly as being an asshole: you begged for it.
I pitty your wife too: it's a major pain to live with cocksure people who know it all and who feel superior. I had a friend like that (I can't stand him anymore) and after a few years she demanded divorce.
Good luck in life (I leave you the last word because seen the discussion and you're type of personality you're obviously the kind of person who thinks he always has the last word) but remember: karma's a bitch.
The moral of this story is: do not let your career slide to the extent that you go all the way through school and then college, most of two decades including what should have been some of the most productive years of your life, and still end up with no work experience so that someone like the above poster feels entitled to tell you you are a nothing. The time to get proactive about your career is long before that point.
"young padawan", "you're just a number", "your lot in life is to...", "you're inferior"
Really?
Why are you playing the bully here with people younger than you?
You obviously have personal issues: you use the fact that you're conducting interviews to feel "superior", to believe it's not an equal transaction, etc. Who the fk do you think you are to try to make youngsters feel inferior by bullying them with such sentences?
I agree that, when you're experienced and have actually delivered impressive things (technically impressive, that it failed is not a problem as long as it didn't fail because of technical issue), potential employers / interviewers will look at what you did and think: "This guy means business" (as in "he's good").
I've been both interviewee and interviewer and I didn't use riddles to determine people's "way of thinking".
And that's where I disagree with you...
It's not because I don't need to answer to (sadly too often silly) interview questions anymore that I do consider it "normal" for interviewers to do riddles and to consider applications as "numbers".
You don't get it about the offer either: some interviewees won't let you even make the offer because they'll politely (or sometimes not so politely) give you the finger way before you have the opportunity to be the one deciding. If it has never happened to you then you haven't interviewed nearly enough people. If it already happened to you, then it destroys your argumentation...
I can see all too clearly the type of person you are: you are feeling "superior" not because of your skills or what but because of your age and your position in the company, which "allows" you to conduct interviews. Which you love all too much because it gives you the impression to be "superior".
Also be careful with the patronizing: there are still a few of us entrepreneurs around here older than you and you should not generalize about HN being all about people in their 20s or even 30s.
Why are you playing the bully here with people younger than you?
Because a great many young grads need to hear it. A great many have been told they are special all their lives and can't take someone dispensing the fact that they aren't. You only need look at the replies to my (admittedly, and by design, harsh) comment to see this.
My comment is designed to serve a purpose. If it gets one person to realize where they are and what they should do to get where they want, great. I'm personally not concerned if it offends 40 other people along the way - it's a net positive for one young man/woman.
I've noticed that more and more topics are being labeled as inappropriate in interviews for developers. I have heard complaints about interviewers asking candidates to complete short programming tasks, producing past code samples, doing a whiteboard exercise, completing a pairing exercise, and objecting to a wide variety of questions. I understand that highly experienced professionals may get frustrated by some lines of questioning, but it's getting to the point that programmers feel they should walk in with a resume and say 'Trust me, I'm good', and immediately get a job offer.
Keep in mind some interviewers will ask questions that they don't expect you to answer in order to learn something about you. Will you lie, admit not knowing the answer, describe how you'd find an answer, get frustrated and rant (as this author does with riddles), etc? It could reveal how you'd treat a customer or a co-worker.
Candidates obviously have the power to walk out or not interview with places that are going to be more rigorous (or transparent) in the process, but what many candidates are classifying as 'unreasonable' for interviews these days is becoming a bit too long a list.
Given that you are going to work for a company for months or years, and interview with them for hours, you care much much more about the quality of the coworkers than the quality of the interviewers.
First off I am not really pro riddle per say, however we do use some 'riddles' at my current employer.
1) Sometimes they can point out really big gaping holes in basic logic ability, for instance we ask about basic logic with the NAND gate riddle, we explain you can compose the common logical operations just using NAND. Ask the interviewee to construct NOT using NAND, usually if they have never seen anything like this, we walk em through it as a freebie... so now they have NOT and NAND, and we ask them to construct AND. How many Architects we have interviewed, with 10+ years of experience who could not logically figure out how to combine NOT and NOTAND to get a logical AND...
2) Second, we mostly dont actually care too much about getting the correct answers to the riddles. Its partially to look at the way person solves problems, but mostly its psychological. In software dealing with non tech, high level biz people, you get all kinds of bizarre requests. If you throw a hissy fit in the middle of an interview, or storm out because someone asks you a riddle... Are we to expect you to keep your head when the VP of Sales asks you for something 'crazy'?
The same can be applied to pre-interview screening problems as well. I recently send my resume to a company that was advertising on the Hacker New job board (I'm not going to say which company it was). They replied to my email telling me that in order to get to the next step in the process, I need to solve a problem and send them my code. They wanted me to send them a conway's game of life board that, after 1000 generations, could be converted to a GIF and would make up a black and white image they included in the email. Basically they wanted me to take their image, convert it to a conway game of life board, and then figure out how to calculate backwards game of life generations. Sounds to me like a fools errand. I deleted the email and never thought about it again. I have better things to do to fill up my free time. Maybe if they had me do something actually useful or meaningful...
That sounds like a fun challenge, and if it's at all representative of the sorts of problems they take on, I'd love to know who the company was so I can apply.
The fist task is converting the GIF into a data structure. That could take anywhere between one hour and one day. Since I personally have no experience reading data from GIF files, it is probably going to take me one day.
The next step is to figure out how to reverse generate conway's game of life. If you have previous game of life experience, you may already know how to do that. But I'm not a game of life expert. Its going to take quite a bit of research and trial and error to get that working. It will probably take me at least a day.
It all boils down to this: I don't want to waste two days of programming time for something as pointless as this. Especially since they could very easily say "sorry you're not a cultural fit" after spending all that time. Thats actually what happened to me a few months ago when I spent 4 days doing a programming problem for a job at reddit. They called me about a month later and had a 5 minute conversation with me, and then never heard from them agan. Assholes.
My new rule is that I don't spend any ore than a few hours on any one single problem, unless they pay me, or if it's interesting enough.
How I feel about things like this: If you're interested in doing the programming challenge, you should do it, because it's interesting to you (and so that company tries to give its employees problems that are interesting/has employees that find the same problems interesting as you do). If not, then you're right, it's a lot of time to spend on it. But learning how to go about programming that is certainly not, in my view, a waste of time, or at least no more a waste of time than doing an edifying class assignment. So, in essence, they're filtering for people that enjoy solving interesting coding challenges in their free time. If I'm a company, that is probably a reasonably good filtering mechanism, and if I'm a potential employee, I likely want to be around people who like solving these sorts of things on their own.
Also, this isn't as tough a challenge as you make it out to be: writing the game of life is, at most, a 2-hour assignment. So writing a game-of-life-reverser might tack on an extra 30 min. to hour. Then, you just hand-code in the gif into a game of life board, and run it through your reverser. Unless your gif is really large, in which case it might be a little more annoying, but probably not drastically so.
Just to clarify: It was a 800*800 image (or there abouts), and the GIF was pictoral (it was actually lena). It wasn't a typical GOF board. The question even hinted that if you can't get an exact match, then return a board that "comes close as possible". Without posting the whole problem, it definitely seemed like the kind of problem that would take at least a few days.
On the other hand, I once had a company give me a problem that was essentially to build a page that displays products from an API endpoint, and have that page infinitely scroll. That was something interesting, because infinite scroll is a useful skill. I had never implemented infinite scroll before, so in order to complete the task, I'd have to educate myself. And infinite scroll is a skill that I can use again. Conway's game of life in reverse is not a skill I'm ever going to use again, except for the next job interview busy work.
> I once had a company give me a problem that was essentially to build a page that displays products from an API endpoint, and have that page infinitely scroll.
I'd probably have the same reaction to that as you did to the reverse-GOL. Sounds dreadfully boring, if that's the sort of stuff they do every day. I don't want to re-use old techniques over and over and over; I want to continuously discover new ones.
Addendum: figuring at a specific game of life board would be tough, because multiple boards could produce a single result. However, figuring out some board shouldn't be too bad, so you should be able to generate a valid board fairly simply. And now I'm interested in trying.
It's perfectly possible this "riddle" did its job perfectly well, by determining you weren't a good fit for them, and all it did cost them was a single email.
I would have done it, because it seems fun. And solving it proves that you know how to find libraries to do external stuff (reading/writing gifs. Knowing how to use basic ImageMagick or equivalent is a useful skill), and that you can solve some algorithmic task, or at least have an interest in it (no idea how hard reversing game of life is, or if this specific problem is bruteforcable, but if they ask it, I guess there's a solution).
How big was the game board? It doesn't seem like running life backwards would be an obvious thing. If I have a 3 by 3 grid with the center turned on I think there are 8 choose 3 or 56 possible previous boards that would lead to that. I guess you're just looking for any possible previous board not a specific one but it seems like any decent sized board would lead to a seriously large problem space in a hurry.
I also dislike puzzle questions in interviews and never use them when I'm hiring people.
It seems that you can choose the initial state of the game, this implies that the number 1000 is no restriction (if it takes a million steps you take the 999000 as the initial state. You can program some greedy algorithm and since number of steps is not a problem the solution seems attainable by this method (just 3 minutes thought).
This article reminds me to ask a pointless mind-bending riddle to each applicant just to weed out prima donna programmer types who can't handle a little mental poking and prodding during the course of an interview designed to see if he/she will be a good fit for spending a good part of his/her waking day with me every day.
If you're too "good" to shift contexts beyond regurgitating your work experiences or coding a for loop for a few minutes -- then I don't want to be stuck in a room with you when there's a lot of pressure to meet a customer commitment that could mean our livelihood.
I interviewed a candidate that had quite an alphabet soup and buzzword compliant resume. He was pretty much convinced he was the world's greatest programmer.
I asked him if he could talk through how he would write a function that showed if an unsorted-array contained consecutive integers with no gaps and no duplicates. He said he never claimed he was a math major and that such a problem was unfair to ask. In other words, he had no idea what to do.
But what was interesting was that this same guy could answer questions about the O(n) complexity of algorithms and explain how to write quicksort. Apparently, his pre-interview preparation involved memorizing that in hopes we would be dumb enough to mistake that for competence.
If you are hiring a baseball player, you don't hire someone that that can rattle off baseball statistics or that talks about how they read about baseball for 4 years at college, you hire someone that can play baseball. Well, I am hiring a programmer. I don't care if memorized the names of design patterns; I care whether you can you actually use them.
You know, now that you mention it; I have done hiring at a couple of small startups where we had to share a little-bitty bathroom. When you're adding people to the team one person at a time, it's really easy to tell at which point you introduced the one who can't lift the seat when taking a whizz and leaves splatter on the seat for the next person to deal with.
Having been hiring developers, designers, and product managers for the better part of the last ten years ..... I agree.
I also hate the actual interview itself. So little time to try and learn something that for the most part cannot be learned in a high pressure, nervous, anxiety ridden situation (I realize I am also being interviewed, assessed, and reviewed). However, this is a different point altogether from what the author is discussing.
I do think it's great to try and understand how someone
1 - Problem solves
2 - Approaches asking questions, interacting with other people, etc
And quizes can sometimes be a way to figure that out.
I've just found that when using quizzes it's better to openly communicate with the person what you, the interviewer, are trying to better understand. I always pre-amble a quiz (if and when I do use one)
"hey, I'm going to ask you a question/quiz/riddle. It's important to note I could CARE LESS about the answer. I'm really looking to better understand how you would go about solving this. So please, make sure to walk me through your thought process and don't hesitate to ask me any questions along the way".
I also like to make it clear how it ties into what the person will be working on. For example
"the reason I ask, is one of the first projects you will be working on is ___________, so knowing how you approach nebulous problems will be important"
The best response I had to this is
Well, I might do X,Y,and Z, but to your real question, I have a great example, mind if I share that?
Also, this is just a data point. Going back to my second paragraph, I've never once "not hired" someone based on how well they think on their feet in an anxiety ridden, pressure filed, hour of their life in a room with total strangers.
I dunno. That sort of defeats the objective of assessing that person's natural reaction to a little interview pressure. It's not water boarding, it's a simple programming or logic puzzle that requires most people to think.
People (on average) are nervous, anxious, etc during an interview. I don't really care how they "naturally" react in that situation as THAT situation isn't day-to-day (at least not in the software companies I've spent my time) so I'm almost don't really care about that.
I really just care about how well they problem solve, not problem solve in a fox-hole with bullets flying over their head.
It's funny to see that developers have so much leverage on the job market that you can read phrases like "don't hire this employer, you're better than that" and act like that's the most normal thing in the world. I guess it's time for having paid interviews again.
That's a little closer to how it should be. I'm so sick of the fear-saturated drivel that dominates much of 'common wisdom' surrounding employment: "dont' do this! don't do that! They may not like you!"
It's disgusting and emasculating to constantly be told that we have to neuter ourselves into this docile, submissive employee because otherwise our boss might decide he doesn't like us.
When you think about all the time and care most developers will spend on there jobs one should be picky. It is literally one of your life's most important decisions.
What falls into the riddle vs. "acceptable" role? In my mind, it's perfectly valid to ask, for instance, "Given a binary search tree, write a program to return all elements between a low and high." or "Write a program to return whether or not a given string matches a regular expression." Are these "riddles," as espoused by the article? Sort of: they do take some element of an "aha!" moment to solve, whereas the "recommended" questions were mainly just domain-knowledge questions. But if you solve these problems using convoluted coding techniques, then I as an interviewer would be really worried that you'd muddy our codebase unnecessarily, and if you can't see how to solve them, I may discover that you have a problem thinking recursively, or logicing through complex issues. Or, I may find that you tend to dive into a problem before thinking about it and designing your solution. All of these seem fairly relevant to any job, and I've actually turned down employers that asked me too many "domain-knowledge" questions and not enough "how do you think about things" questions, because I don't want to be somewhere where I'm just expected to "know" the answer.
Riddles, logic puzzles, "write some code on the whiteboard" ....
It took me years to realize that these are not tests of technical ability, they are tests of submissiveness.
For example, if you are being interviewed by someone at the same level as you for some position -- and they pull such crap -- now you know how low their expectations of the employer are.
And if you are being interviewed by someone fairly senior relative to the position -- and they ask you such BS interview questions -- you can be damn sure that they themselves would laugh at and walk away from any interviewer that did that to them.
So when you give the clever answer and wait for your gold star... you've established your place in the order of things.
I tend to agree with the author, but there are indeed some things you can infer from the type of response you get. I have a friend who was doing a technical interview, and things seemed to be going weird. It seemed that the candidate knew the answers to most of his questions, but when pressured further he couldn't come up with alternative solutions. It was like those people who know the motions of math, but don't understand what it's for.
So he decided to ask one of these riddle questions: "How many hairs does a dog have?" and the candidate answered that it depended on the dog. So far so good. But then he started rambling: "Well, if it's a dog from the street, the dog might have scabies, and thus this dog has less hair.
Of course, this is a perfectly valid answer, but it is the failure of applying math/statistical thinking into his answer what was telling.
Now, I'm sure some people are thinking "that's anecdotical evidence" and it is, but what is the alternative if your intention is to hire mathematically inclined candidates?
Riddles are useless interview tools. When I am building a new dev team or adding to an existing one, I care about two things:
1. Did the candidate make a critical contribution to a piece of technology that I respect. I will start by asking them for examples of this in a lot of ways including asking them to present something they're proud of to the team. I will not rest until I have verified they did this through my network and back references.
2. Is their chemistry compatible with the team, or as it is more popularly put today, are they a good culture fit? That opportunity to present to the team is an important test. Another one is that the interviewing team has to catch them out being wrong about something and then see how they react to that. You can learn a lot about how someone deals with learning they're wrong about something. Lastly, we look for opportunities to socialize with the candidate. They can't be a good culture fit if nobody wants to spend non-work time with them.
Interviews are a two way street, but in any negotiation there's different leverage. Most of the time, in the current job climate, the interviewer is the one with the leverage over the employee.
For many people, a job interview ends up being "how much crap am I willing to put up with to make a living wage" and whether the interviewer (who may not even be someone you will ever work with again if you're hired) asks stupid riddles might factor very little into the equation.
I think this article would be better suited if it targeted the interviewers to say "Look guys, asking riddles is pointless and might turn off the best candidates who /can/ afford to fire you and look for another company to interview with."
On the other hand, you might consider whether you actually even want an employee who is willing to abandon the whole enterprise when they realize that an interviewer has the NERVE to ask them to solve a riddle or logic puzzle.
Like raganwald said, the interviewer is probably not the best interviewer, and you can decide whether you want to work with him and make the best impression. Or you can decide that you will only work under the strictest of conditions, and if someone asks you a question you don't like, that you may as well just walk out of the room right then, because they're obviously an braying alphadog assholey jackass.
If I was conducting an interview, and felt like asking a riddle like the article ("Four people want to cross a bridge. They all begin on the same side. You have twelve minutes to get all of them across to the other side. It is night. There is one flashlight. A maximum of two people can cross at one time"). If my candidate just said, calmly, and without agitation "Heh, you know, I'm not really good at on-the-spot logic problems like that. I don't know how long it takes for a trip anyways. But 4 people, weird restrictions, would probably take more than 4 and less than 4^2 trips." I would get a lot more out of it than if they blurted out a correct answer.
On the other hand, I'd probably learn a lot if they slammed their hand on the table, called me a braying asshole and stormed out of the interview.
If I am interviewing you, I wouldn't mind you giving me a puzzle. Depending on how you do it, I would think you are either the world's biggest asshole, or a very easy guy to work with, and that's very valuable information.
Maybe you should! You should be interviewing them as much as they are interviewing you. When they ask if you have any questions for them, respond with, "Could you solve this for me?" Then give them a programming problem.
If you're being interviewed by a non-technical person (who obviously can't program), that could be a red flag right there (in and of itself).
I assume he is implying that the technical incompetence caused people to second-guess what they heard when confusion arose. This confusion can be misunderstood by the interviewer as confusion over the subject matter. I know I've had that problem before over poor telephone connections.
People who have any kind of trouble communicating verbally with normal native speakers of the language in which business is to be transacted, are not a great choice for jobs which require clear communication.
People who are poor communicators should generally not be in leadership positions. It actually wasn't just the accent, as his written English was absolutely awful, too.
Exactly this. I've always said the Google and Microsoft "riddle" interview questions were IQ tests using CS concepts as their medium. And this is precisely why so many people dislike them. In many cases its not about what you know or how many years experience, but how much raw brainpower you have.
I agree 100%. There seems to be 2 camps when it comes to what makes a programmer great: aptitude versus domain knowledge. I think both are important but aptitude is harder to train someone on.
I'm a big proponent of tough, small problems in an interview, that the candidate has never seen before. Much like the author is against. This is because it has been the best indicator of performance in my experience.
The author is not against small, tough problems, by all means a well designed generic programming question that doesn't tie in to any specific domain knowledge can be a great test.
What the author was against are the riddles, which are proven to be ineffective in determining the general aptitude of the engineers, and that's why the companies that used to use them (MS and Google, for example) have mostly banned those.
From reading the blog post the author does in-fact seem to be against challenging coding problems. Note that the examples given as good questions where all general that didn't require one to demonstrate any actual ability to solve problems by applying algorithms and logic. This is exactly what programming and logic "riddles" are designed to test.
You can still do it, it doesn't have to involve a complicated CS topics such as self-balancing trees or graph theories or anything, but I've seen plenty of good algorithm questions that the solution involve nothing more than understanding of Strings and for-loops.
You can also test the interviewee's knowledge of Big-O, time efficiency vs space efficiency, etc without going into obscure data structures.
Big O would be something I was much more familiar with out of university, although I could probably muddle through some basic questions around it.
For loops that manipulate strings in various ways however is probably something that most programmers will have wrestled with reasonably regularly I imagine.
No way. In most cases, the company would much prefer to have the candidate work on technical problems that the company actually has, but that almost always requires significant background context and disclosure of not-so-public info.
The riddle should be a stand-in for a collaborative, thought-provoking problem, not a general intelligence test.
To the original author: if the hiring manager or interviewer doesn't see it that way, then fine, write off that company, but don't write off riddles!
How so? You can certainly unintentionally filter out smart people who didn't go to college (or went to a less prestigious college) by this method.
However I imagine people who fit the description of "dumb guy who fluked his way through MIT math programme with a high GPA" are a pretty endangered species.
I imagine people who fit the description of "dumb guy who fluked his way through MIT math programme with a high GPA" are a pretty endangered species.
Maybe.
But people who fit the description of "smart guy who got through MIT math programme with a high GPA but is clueless about the fundamentals of software engineering and aggressively unwilling to learn"? Probably not so endangered.
Besides remember you're competing with other employers, and on average employers currently overvalue paper qualifications. Once you take that into account it's probably rational to place negative weight on them: other things equal, the guy who didn't go to college has a better chance of being good than the MIT graduate, because MIT graduates who were good, have probably already been snapped up.
For the purposes of a given job, let alone the types of jobs discussed in these threads, it's going to dump a bunch of false negatives. Since software is an industry that thrives on overqualified employees, this may not seem like a big deal, but having people who can interview a Big Degree person such that they'll accept these jobs has its own cost and management overhead.
You might certainly have to scale back demands/expectations depending on the job market and how desirable your company is to work for.
I think it goes back to the classic "smart and gets things done". There will often be instances where you will have more evidence for one than the other.
So for example, someone with a good degree probably doesn't need to be asked riddle questions because they have already proved their raw mental aptitude so you're probably more interested in their understand of good programming practises etc.
OTOH, the guy without a degree who has a solid string of practical experience behind him as well as glowing references has proven he can "get things done". However perhaps his past jobs were mainly building CRUD php applications and this position requires some more complex theoretical knowledge that he does not posses.
How can you best test his aptitude for picking up that knowledge quickly if not with something that approximates an IQ test?
Towards the end of the interview the interviewer told me, "your turn to ask me questions". I said, "I have this puzzle for you...". He turned pale for a moment and then laughed at the joke. I wasn't joking.
This is not a trivial career so why trivialize it? I'm more keen on seeing a person's past work or hearing about their experiences. Asking them how they've solved past problems and how they've faced past conflicts gives me insight into if we can start working together. That's all an interview is. There's no guarantees it will all work out and I believe no amount of interviewing techniques will change that.
I recently had a headhunter e-mail me, offer no job description, but directed me to the website of the company, which makes iOS/iPhone apps. Two hours later he pinged me again asking if I read his previous e-mail.
Nowhere in my many online résumés do I say I have iOS experience or that I am even interested in that kind of work. Moreover, I stress, emphasize, my interest in hypermedia and W3C Standards.
This market is saturated with mismanagement, and there is a clear bottleneck. So, for instance, "hypermedia." Most developers and "techs" I mention this term to obviously have no idea what I'm talking about. And just entertain the fact that I made some jargonish sounding word, thus giving me the benefit of the doubt.
But now I cannot find work I want to do because hardly anyone knows what hypermedia is, and that is _not_ my fault. I'm staying abreast with my industry, and now I am suffering for it.
There is a bottleneck here, as with most "recruitment" industries. I don't even want to begin thinking about open source typography, with all the Microsoft Web Safe Fonts flying around.
I think there is some value in trying to see if a person can have a Columbus moment. After all the simplest solutions are hard to find. And it is nice to see how a person deals with problem outside his domain of knowledge. We don't want to hire someone that can have a nickname like Complicator or Rube Goldberg. But the questions must be rooted in reality. The correct answer to how much a Boing weights is check the manual.
Аsk them how to minimize datacenter flooding or how to lift fuel 20 floors upwards with no pumps working - that were real things that real people had to solve just a few months ago. And they weren't hired for that.
One thing to remember about interviewers that ask poor questions is that many such people aren't full-time professional interviewers. They are to interviewing as a marketing manager who does some Excel scripting is to programming. They are often repeating what they've heard or read or been subjected to, much as an inexperienced programmer tends to use whatever programming pattern was espoused in the last blog post he read.
A terrible interviewer may still be a wonderful person to work alongside, just as someone who performs poorly under the pressure of an interview may be a fantastic programmer once hired and working on an actual project.