I worry a lot about this. I don't think it's distrust so much as thoughtlessness.
From what I can tell, Google (and other companies) started using these kinds of questions as a way to cheaply filter sudden floods of applicants, not because this is the way to find the greatest geniuses of our time. Policies implemented under the gun have two unfortunate properties: they are wasteful and hard to change after the fact.
As the tactics of successful companies percolate through the rest of the industry, they take on a third unfortunate property: cargo-cult foolishness. Google asks binary search questions and they have great engineers. I want only the best engineers, therefore I will ask binary search questions. I don't know what else to do so I shall grade strictly on style points, because points are scientific, right?
Bleh. Put it another way: if there are a large number of productive creative people shut out by a culture of thoughtless interview checklisting, that's an opportunity for some smarter company to snap them up. Such a company would by necessity have an outlaw air about them. Who else would hire misfits? But gangs of talented misfits can be a powerful force.
Thoughtful comment, but there's a practical problem with your last point: how can YOU (as a hiring manager at this "some smarter company") effectively filter through the enormous set of screened-out candidates that Google rejected and find those productive, creative misfits that you want to interview/hire out of the teeming throng of vocational misfits?
Of the people actively applying for jobs at any given point in time, the "truly excellent" are under-represented as compared to the total population of programmers.
If I were looking to hire a developer I would do the following :
1) Select a set of candidates based on their resumes making the assumption at this point that their resumes are honest. Good candidates should have at least worked on some interesting projects so their resumes should look interesting. Most lame candidates wouldn't even be able to invent a credible interesting project.
2) Do phone interviews where I would ask knowledge based (ie not problem solving based) questions related to their resumes. The goal here is mainly to filter out fake/exaggerated resumes.
3) Invite the selected candidates to give a presentation on a topic of their choice related to work they've done that is at least marginally relevant to the job. I think you can learn a lot about someone by seeing how they present their work and respond to questions (though it doesn't tell you if they're good coders, that's for the next step). The presentations could probably be done remotely.
4) Hire the selected candidates for short-term contract work. Set things up so they can work remotely. Assign them real tasks that you would expect them to perform in the job.
Make final selection based on evaluation of the candidate's work on step 4 and offer positions to the best.
You are basically filtering for presentation ability. But 3/4 of programmers are introverts, and giving presentations is simply not part of their job. You're therefore selecting for the wrong skills until the contract step.
At the contract step you create another problem. Good programmers who want to be employees probably already have jobs and are somewhat risk adverse. That kind of person won't find the option of a short-term contract with no promises at all enticing.
Remember, as bad as the economy is, the economy for programmers right now is pretty good. And as annoying as the coding interviews may be, really good candidates don't have too much trouble with them.
I think I'm kind of introverted but I can still interact with human beings. A good programmer should be able to communicate with other human beings, and a presentation (which in this case I believe is "Tell me about a project you've worked on recently?") isn't out of line at all. I talk about what I'm doing at work pretty consistently; you're basically being put in the same position during the interview you would be when having to explain your work to a CTO or someone in a similar position.
And the problem with coding interviews is that they filter out other good candidates, and I've seen plenty of companies complaining that "They can't find any qualified developers."
I would not blame the developers for this, I'd blame their selection process for focusing on things most developers don't really touch or care about when they're working on a project.
We do almost exactly this at my company and it works wonders.
Presentations are not about powerpoint. They are about geeks geeking out with other geeks. Every talented programmer I know has a pet project he'd love to talk your ear off about.
The presentations we solicit are often little more than the candidate opening up a text editor and showing off some code, and fielding tame questions from the other developers.
As for the contract position, everyone that is motivated to switch jobs, or to come work for us, can find time to do the really simple tasks we split off for $100/hr.
It is also made clear that if you've made it to the contract, we are extremely interested in hiring you, or else we wouldn't give you access to the repo or the team. The gig is to give both sides a chance to see what working on something real feels like.
We have found only excellent developers after this process. That said, it probably doesn't scale very well, and I'm sure we've unfairly weeded out many good devs.
Also, we skip a lot of the BS if there someone comes highly recommended from current employees or other partners we trust.
Being an introvert doesn't preclude one from giving a good technical presentation. It's common practice in the academic/research world which is certainly full of introverts.
The assumption I'm making here is that of hiring for someone to work on technically challenging problems (ie. machine learning, computer vision, data analytics, large-scale systems design, etc . . . - the list isn't meant to be exhaustive). For those problems you need people with strong general and/or mathematical reasoning ability. If I was looking for a very junior coder I might skip the presentation step.
At the contract step there doesn't need to be any risk for the candidate - there's no reason he would need to leave his current employer during this phase. Of course there would have to be an incentive of some kind if he was hired - better salary, more interesting work, etc.
You are basically filtering for presentation ability.
...unless you are looking to hire someone in sales or someone to represent you. :) But I agree with you.
For something like software development, I think the presentation process can be improved by talking to the candidate as part of the presentation, not just letting them starve in front of an audience. Let's not rule out the presentation mechanism; you can learn about the candidate's ability to give presentations and handle pressure.
For game development at least I've found that a 10 minute phone interview with simple 'these are things you must know or I will not hire you' questions works wonders for screening. I like to think of it as a bounding volume check for the position you're interviewing for. It's simple, and if you're not intersecting at this level there's no way you'll be intersecting at the more detailed levels.
This works because game development is relatively specialized and there actually are things that I expect anyone claiming to be a game developer to know.
Stuff like basic linear algebra (What can you use a dot product for? What can you use a cross product for?) and simple data structure do's and don'ts (What's one advantage of using an array over using a linked list?). Throwing in a few simple domain specific questions for the position their applying for works well too (I wouldn't ask a network programmer to tell me something about shaders, but I would expect a graphics programmer to be able to talk about them for a few minutes)
Some of the questions are designed so that there are lots of right answers, and some of them impress me more than others. For instance, if you mention that an array is generally more cache-friendly than a linked list and you can explain why when I ask you, you get bonus points.
If they do well on most of the questions then follow up interviews (phone or in person) are in order. Occasionally someone will nail all the questions, I tend to get excited when this happens.
Remember the goal is to find high quality candidates not shift though all of the incoming resumes. So if you have 2 open positions and 10,000 resumes just stop when you find enough high quality candidates.
I agree. Resumes are not as useful as a lot of employers want to believe. They represent what the candidate wants you to see of their history, and you get only one thing from that: Talking Points. Resumes put you both on the same page, bringing up topics the candidate is interested in talking about.
A poor salesman will have a hard time coming up with good or enough talking points. This alone is a reason resumes are mis-filtered.
I want to say that you should avoid filtering candidates based on their resumes, thanks to the holes, but that would be wrong: Sometimes, based on what they write down, you can make a reasonable judgment. For example, if you are looking for a software developer and the resume mentions NOTHING about that field, that is an easy filter.
Not quite so easy a filter: "I know C/C#/C++." but I always find that one amusing.
I've interviewed a lot of programmers and I think there are many misconceptions about what an interviewer is looking for or expecting.
I don't expect you to be able to code quicksort from memory. I do expect you to be able to code quicksort given the spec for it.
Just because I point out an error doesn't mean I'm counting it against you. I'm pointing it out to see how you handle it.
I do expect you to ask questions. If you are unfamiliar with an algorithm or forget the details, ask. I may not give you the answer but I'll at least point you in the right direction.
I generally try to make this clear to candidates so that they don't get uncomfortable if I point out some problem, but a lot of interviewers don't, which can be hard on the interviewee. I doubt, however, that there are many who expect perfect code on a whiteboard.
This reminds me of my Cambridge University interview. I thought I'd done terribly because I couldn't provide the answer to most of the questions they asked, but I did explain how I would find that answer if they gave me 10 minutes and some paper. I passed the interview, and many of my peers that were able to recite the formulae by rote when prompted (and thus felt they had done well) did not.
I feel exactly the same. Don't try to make stuff up you don't know, do ask me questions, do just TRY, rather than noodling about and not saying or doing anything.
I believe this was the original intention of the "coding" interview, but it morphed from being used to expose thought processes into a binary checklist (e.g. Can he code a linked list? Yes. Can he code a quicksort? No. Oops, no job).
As the blogpost pointed out, it's pretty useless to require the knowledge of the implementation of these items because 99% of programmers will never need to code it from scratch. If someone on our (web) team was building a new linked list library, they're doing something wrong.
My theory is that many other technical fields have high barriers of entry where a newcomer has to really prove her chops, usually with a certification exam, before being allowed to practice the profession; but once she starts, fellow professionals treat her with respect and take it as understood some minimum capability.
In programming, almost anyone can start on the job - but we play out the hazing ritual throughout entire careers. Every time a programmer has to change jobs, she has to face a barrage of pointless trivia questions from megalomaniacs. Of course, many of them then grumble that they can't find competent programmers.
Well, back when I was at Amazon, we did (and they undoubtedly still do) a LOT of soul-searching about this exact problem. We eventually concluded that every
single employee E at Amazon has at least one "Interview Anti-Loop": a set of other employees S who would not hire E.
If you remember what a linked list is, how pointers (or references) work, and have written more than 10k real world lines of code in your favorite programming language, I would fully expect you to be able to write, not memorize, any of the linked list functions that you mention.
I certainly understand your frustration, but I really don't think either the tone or the content of this blog post is going to help land a job in this era where hiring managers ask Google what it knows about a candidate.
Sure. And a good interviewer should take that into account. I ask this kind of question ("write me code to reverse this linked list, re-using the existing nodes") quite frequently. I don't expect even experienced programmers to have memorized it, and it's (a bit) more interesting than it sounds.
While I do give mental brownie points for people who can just write it in one go, I don't consider it a non-starter if you can't. But if you can't get to the point of having written it, with prompting and help, in half an hour, that's a non-starter.
I feel bad for this lady, but there's a flaw in this logic (and with the logic of many commenters here).
Everyone assumes that the battle is between...
Person 1:
-Great resume
-Relevant work history
-Strong sense of corporate citizenship
-Can't code on white board
and Person 2:
-Can code on whiteboard
-Smokes crack in the bathroom
But the reality is, you're all interviewing for the same job! You're not getting the job, not because you can't whiteboard code, but because someone else has the same qualifications AND CAN whiteboard code.
I do interviews, I care less about the right answer than I do about the problem solving approach. I interview electrical engineers and I make them do simple transistor problems. If someone gave up and said that they couldn't do it without some sort of SPICE program, I'd cut the interview pretty short. But if the fundamentals are there, even if they don't remember something stupid, knowing how they approach a problem and if they know how to ask for help is more important.
Every time someone says "I didn't get the job b/c I couldn't do a linked list on the whiteboard." I'm fairly certain it was more than that.
My point is that a person's inability to code on a whiteboard has little to do with the value they can provide to the business. Some people just aren't good at it, and why should they be penalized for it? There are other ways to get programmers to write code in an interview, and a simple "Do you prefer to code on the whiteboard or on a computer?" can resolve this. It's not as though that's a huge burden on the business or the interviewer.
I've been doing a lot of interviewing recently. When people struggle with a white board problem, I give them a laptop to code on. I have yet to find someone who struggled at the white board, but did fine on the laptop. Maybe they exist, but I tend to think there's a high correlation between white board performance and laptop performance.
Sorry, what? You seriously think some people's coding skill depends on the writing medium? That's not what the OP was saying: they said they didn't know how to create a linked list from scratch, whether they were writing on a whiteboard, a computer or with a crayon on the back of a 4000 year old cuneiform tablet from Mesopotamia.
Is it that you just don't like the kind of problems that are being asked (fundamental computer science) and would rather see more real-world problems? Or do you genuinely think the wide, stubby pen and vertical orientation impairs some people's coding ability? Just to note, I can see the performance aspect of the whiteboard is stressful, but coding on a machine with everyone looking at you is stressful too.
I understand where the author is coming from because many interviews questions are unreasonable and test absolutely nothing.
However, if someone couldn't code a linked list on a whiteboard, I'd be severely worried. Same goes for a binary tree. If you know what a linked list or binary tree is, you should have no issues figuring out how to represent them with code in 10 minutes.
The other trickier problems are there to test problem solving ability, which I believe is a valid thing to test.
I think the reason for this style of interview is that companies are afraid of false negatives. They'd rather reject 95% of the qualified people and 99.9% of the unqualified people rather than 94% qualified and 99.5% unqualified.
Additionally, swearing all over the place never helps your case...
They'd rather reject 95% of the qualified people and 99.9% of the unqualified people rather than 94% qualified and 99.5% unqualified.
And then they complain that they can't hire developers.
I don't think these types of interviews are well conceived. Human memory is extremely context dependent and a whiteboard/interview type situation doesn't establish the right context for someone who's accustomed to working alone with a mouse, keyboard and compiler.
Also the more knowledge you have the more difficult it becomes to retrieve that knowledge quickly. So these types of interviews might be good at selecting people who know all about linked lists and binary trees but not much else.
I disagree. If you know what a binary search tree or linked list is, you should be able to code them. If you can't do something this simple, how can you be expected to actually solve a problem that you can't just look up the answer too?
Well I know that I've solved a few problems in my time: like developing a multi-threaded distributed object-oriented control system, implementing a JPEG2000 encoder, a convolutional neural net, as well as solving a number of debugging problems that escaped my colleagues.
I also know I failed miserably at a trivial coding task in an interview.
So I don't know. If I'm the only one who has that kind of problem, maybe my brain works differently from other people's.
How trivial? What was the task, then? And what where the conditions? Were you required to remember some nitty details? In an interview, you can fail in almost anything, depending on how nervous you are.
The problem was: given the following prototype implement the function
void move( char** colNames, int toColumn, int fromColumn );
The function should move the column name at index fromColumn to the position toColumn. (It does not swap the columns.)
Now I just spent 43 min implementing this with a compiler and some trial and error.
During the interview I was expected to do it with pen and paper.
Now my IQ is above the 99th percentile but apparently there are people who can do this sort of thing in their head without errors and that's what some interviewers appear to be looking for. That's why this post hit home for me, though personally I probably wouldn't have had much trouble with linked lists.
I'll agree with this on one condition: don't hold syntax errors against me. I interviewed for a position about eight months ago. I was rusty with my C (had been doing more java and python around that time), and put "int i = 0" in a for loop on a white board and seemingly had it counted against me. This kind of thing, along with things like missed semicolons, should be ignored by interviewers. Not only is it a simple fix, it also says nothing about the logic in the code.
Unless I've needed a specific language, like SQL for example, anytime I've asked a candidate to code on the whiteboard pseudocode has always been fine.
What makes you think it was held against you? Most programmers can be kind of OCD about code and would want to point out that kind of error, whether they thought it was relevant to your abilities or not.
Code on the whiteboard is counterproductive at best.
Let's hook up your laptop to the projector so I can get a glimpse of how you interact with your computer. I learn more about you by seeing your relationship with your text editor, how you look up information you can't remember, etc. Not watching you sweat with a marker in your hand.
well a programmer that is coding a linked list in c/c++ probably(definitely) should know the pointer semantics. If they are looking that up then they should be a pass unless you are looking for a really junior programmer. Now if you are asking them to connect to a db and update a record with a stored procedure and they looked up the syntax for a db connection to a mysql database then you know they are fairly proficient at that type of coding but just forgot the exact syntax of a db connection because it's not something done every day whereas any c programmer worth their salt should know basic pointer rules.
Any language I have not used for a while get’s tossed out of the buffer, and I need to lookup even the most basic of syntax when I start coding in it. Once I get going I can easily recall if it’s *, &, ->, or ^ but at the start I really do need a refresher.
PS: Oddly enough, I have little issue working on a multi language programs, it's just I think in terms of pointer not C pointer.
My laptop is for reading email and surfing the web in hotel rooms. Occasionally I program on it when I don't have a choice, but I'm far less productive than on my regular workstation, both because of the ergonomic problems and because I haven't invested the time to set up all my usual software the way I like it. (Am I a dinosaur? Does everyone else have a laptop as his primary machine these days?)
As a college student I have noticed many of my peers have to make the choice between a desktop and a laptop. The laptops often win because of their ability to be carried to classes and to collaborate with peers. Having a whiteboard to collaborate on at school and a computer right there to program on afterwards is very nice.
Coding general solutions should be par for the course. I agree that some interviewers are coming up with contrived examples. But of the 6 data points I have now from hiring people, those who could code on the white board turned out to be good employees (4 of them) and those who could not turned out to be a vast waste of time (2 of them). As jconphoenix was alluding to, I would have rather ended up rejecting more of the qualified applicants than ending up with a time-wasting employee.
I don't really understand this mentality. Is is really that hard to get rid of the charlatans that slip through after the fact? Just monitor them fairly closely (but secretly) for a couple of weeks. Have some sort of object measure of performance for that time period. If they don't pass muster, get rid of them. This seems like a better method than spending 6 months to fill a couple of positions.
Training and getting someone up to speed for a few weeks, then getting rid of them (if it doesn't work out) wastes more time and money than spending several months to fill the position with the right person. Laying people off for performance is hard to quantify, not to mention I certainly wouldn't want to be working for a company who is secretly monitoring new hires' performance.
Some organizations openly set out the first few weeks or the first month or two as a probationary period for new hires, but you're right about the cost effectiveness to some extent. A six month recruiting process might cost a few hours or days every so often from a few employees, but won't add up to even a single month's pay for a bad employee. Add in a cultural practice of risk-averse hiring (don't hire any B or C players) tilts the scales even further.
That said, I can imagine some cases where opportunity cost and being more concerned about getting good employees than immediately weeding out potentially bad employees would lend one to the probationary thing.
Amen. Someone in my orgzn was let go very recently. I'm not in mgmt so only had a peripheral view of what transpired, but the orgzn I'm in is very loose and generally hires strong candidates with very high success rate. We don't have a lot of time to spend monitoring performance closely; we expect people to work independently and deliver in a non-sweatshop environment. Once a problematic situation is recognized, it sucks up a lot of time, energy, and karma (heavy HR involvement, PIP programs set up, tracked, etc.), and of course we have tasks which the individual was expected to be completing; now not so much. Also, the months spent bringing up to speed someone who will now never contribute to the team, time and teammate energy which could have been expended on a better candidate. The net cost has been huge. I remember there were some doubts about this individual at interview time (and our interview process is nowhere near as severe as what is described to take place at Google, etc.), and these were ignored (there were "extenuating circumstanced"). I'm reminded of a quote from Ronin "Whenever there is any doubt, there is no doubt." Even though from a fictional source, it's good advice. Also: "no exceptions".
This sounds like risk aversion to me. People place twice as much emphasis on avoiding loss than they place on gaining something equivalent (even though the end result is the same). If you look at it in this light, then of course the good ones weren't as good as the bad ones were bad. The end result is that you end up with employees who definitely don't suck, but aren't really great either because you spent all of your time avoiding bad programmers and not enough finding good ones.
Huh? You're worrying about whether or not what you write on a white board will compile? How do you know? Press a magic button to OCR what you've written, download it into some computer somewhere, and compile it? Sounds like you're interviewing at firms with technology I didn't know existed.
Your interviewers have you code on a white board so that they can evaluate you, not your code. They want to see how you handle a problem, how you approach your work, how you think on your feet, how you deal with interaction, and how your intelligence and experience applies to their business. Anyone who worries about whether white board code actually compiles is missing the point. If they're more interested in perfect syntax than embracing you and your potential contribution, then you don't want to work for them anyway.
I think you're making this too hard on yourself. Memorize nothing. Just be yourself. Programming is like riding a bike; once it's part of your DNA, you don't have to worry about it. Just relax, trust your inner programmer, and let this become a self-solving problem; some jerks may reject you, but the right fit will come when someone sees who you really are.
I agree, though I think, perhaps, the author has a point about something. It's one thing to be asked to write code on the whiteboard for a practical problem. During the interview process for my current employer, I was asked to sketch out a database design for a given application, including actually writing out some of the SQL to generate the tables, constraints, etc. I was then asked to write queries to pull reports against my schema. I was also asked to show some code to pull said queries from the database, in the language of my choice.
Those sorts of questions seems appropriate for the position in question. Asking me to implement a linked list or binary tree? Not so applicable. Might I use these sorts of things? Yeah, but the senior engineers assume I know how to use Google.
It's often hard to ask relevant questions that will fit into the time allotted for an interview. Your DB schema example is a good one - it shows that the candidate can design (and to a lesser extent, implement) an application. Your example (I'm assuming) is missing strong algorithmic problem solving however. It would be good to have an additional question to test this kind of knowledge.
It's also important to realize that most technical interviews are really about weeding out bad candidates than finding good ones.
It may also be necessary to have questions general enough that any given candidate stands a chance at solving it. If a candidate doesn't have SQL experience your example would be bad (assuming the company didn't require SQL experience).
This is why you see questions like "implement a binary tree." Any competent programmer should be able to implement a binary tree. If they have never seen a binary tree before, they are simple enough to describe in 5 minutes.
I once asked a candidate to implement a trie. He had never heard of a trie before so I drew one on the whiteboard and briefly explained it. He asked me a few questions and then proceeded to implement one. We then discussed the pros and cons of different methods to store the nodes (vector, list, map). It showed me that, given a spec, he could code a data structure and the following discussion showed me he understood memory and time constraints.
Good points, but, how many interviewers would severely penalize someone for not even knowing what a binary tree was? I think explaining the tree and asking for an implementation could be a fair question, but only if the question assumes that the implementation is the important bit.
Also a good point. I'd be surprised if a programmer didn't know what a binary tree was and would certainly consider it a warning sign. I would assume that, given a description, they probably wouldn't be able to code one (or code much of anything). However I'm willing to be proven wrong and if they were able to implement one I would be pleasantly surprised.
Of course, I can only speak for myself. I'm sure many programmers would immediately write them off.
I would assume that, given a description, they probably wouldn't be able to code one (or code much of anything).
That's a pretty glaring assumption, especially since it's subject to empirical verification. It also contains an assumption of its own -- that all programming needs a heavyweight familiarity with algorithms. There's a lot of programming contexts where the productive programmer just uses a hash so the mental bandwidth can be devoted to something else.
(FWIW, I do sometimes wish those programmers knew a little more about algorithms.)
I agree that it is a glaring assumption, and perhaps is "culturally" biased. Someone programming in Perl or Python, would probably be very familiar with the built in data structures (hashmaps, dictionaries) but may not be familiar with others.
And this is exactly why I would give the programmer the benefit of the doubt. If they are able to implement a binary tree then I wouldn't hold it against them (and I hope most other programmers would extend the same courtesy).
However I have never met a programmer who did not know what a binary tree was.
Thanks for your support. The reason I mention "on a white board, no syntax errors, compilable" is because I've been dinged at the whiteboard for these silly reasons. No shit ! And Gayle Laakmann, author of "Cracking the Coding Interview" actually says it's important to write nearly perfect code at the whiteboard.
How do you know you were dinged for these silly reasons? Did they actually tell you that?
I wouldn't be surprised if there are programmers out there who ding candidates for silly reasons like that, but in my experience they are the minority.
I wonder how he knows what they're downgrading him for? Most interview processes don't give the candidate any feedback - just "hire" or "no hire".
From the other side, I certainly don't expect perfect code on a whiteboard, especially if they're typical mistakes that even experienced coders sometimes make.
Oh I always know why I'm being downgraded. During whiteboard coding sessions, I often need hints. But given these hints, I get to the answer most of the time. In this economy, everyone is looking for "A" players. My blog post says that. "Today’s interviews seem heavily geared toward software engineers who rarely need to look stuff up. Those who code at an alarmingly rapid rate, who get complex code compiled and running the first time around.". So sorry, but this does not describe me. Nor does it describe the majority of good programmers out there ! But interviews do seem to screen for these whiz kids. Joel Spolsky said it right -- top notch "A" player software engineers don't apply for jobs. They don't need to. Jobs find them. But does this mean that B or B+ players are utterly worthless and unemployable ?
It doesn't, and am against sorting people into A, B etc buckets at all. Nor am a big fan of interview puzzles in principle. Looking at how my grandparent post sunk though, seems like an opposite came across to a number of people.
I've had some astonishing questions asked in interviews lately. Very esoteric and obscure parts of C++ that if you followed good design you wouldn't even see or need to know about - and if you did, it's a short google query away. Testing esoteric knowledge rather than actual intelligence and programming ability is a complete fallacy imo. But then it goes even further at some places where you have to do a psychometric test to get in...!
At least Google's interview questions (from what I saw) made sense in their challenge. It's not stuff you would know from being an everyday programmer but it's stuff a truly great programmer should know.
Coding problems in interviews can be a put off for me (though not a complete turn off if everything else about the job looks good).
1. It shows unfamiliarity with my work. It seems rude to invite me all the way into your office just to be filtered. In a perfect world (or at least the one I knew some years ago) I'd be invited into an interview because you were already familiar with my work and wanted to talk to me -- not just to see if I was worth talking to in the first place.
2. Anxiety. I don't operate normally under conditions where everything I say is being evaluated.
3. They can be easily regurgitated.
4. They don't really tell you anything unless you know what you're asking for. I've been in interviews for web development positions where we started getting into the finer details of C++, sorting algorithms, and file system implementations. These are positions where I was being asked to write web applications in Python. I've been writing web applications in Python for years -- I don't think I've ever actually needed to implement a file system or even write a sort routine (tim sort is pretty good and most sorting in web apps is done by search engines or rdbms's anyway).
The problem is most people seem to think that since Google does it, they should do it too. However, if you don't know how to ask the right questions, you're just going to waste everyone's time. My time has been wasted in interviews as the interviewee. Boring technical questions that lead no-where and have little to do with the relevant skills for the job; often just for the sake of asking technical questions and appearing smart. Anyone can do that even if you yourself don't know the answers.
In a perfect world you wouldn't need to look at my resume to remember my name when I walk in the door. You wouldn't need to bother "screening" me. You want me to be there to meet me and see if I'm the right fit for the job.
But I also understand that businesses get a mountain of resumes and that some large portion of them just aren't worth looking at. It'd be nice if there was some way that you could at least know where to look in the pile for relevant resumes. That way you could spend less time screening (how draconian sounding) and more time interviewing. Sounds like a problem some decent software could solve...
My company is currently in the middle of a lot of college recruiting. Most college students/recent grads have very little to show. If you're lucky they had the forethought to save some of their school projects and post them online.
Even a lot of industry people don't have much to show. Plenty of decent programmers don't have serious side projects (or aren't comfortable releasing them to the public).
As for regurgitated answers, I keep my eye out for those. You can usually tell if someone has seen a similar problem before. If I think they have I ask them. I sometimes ask a different question to see if it was raw ability or familiarity.
They do tell you a lot. They tell you whether the candidate can actually write basic code or not. I'm not trying to see if you are a great programmer, I'm trying to see if you are a bad programmer. It can be really difficult to spot a great programmer, but it's usually very easy to spot a bad one.
Anxiety is a real problem however. I try to take that into account but it affects so many people in so many different ways.
Personally I think resume's are worthless. I think the best form of application would involve some form of code submission - either a simple "screener" problem or perhaps a personal project. That might still be followed by an on-site screening interview (people lie and cheat all the time).
We've been interviewing MS-SQL dba's for months now. Each time, we ask them to rate their SQL experience on a scale from 1-10 and most candidates have said 7-8.
When brought in and asked to do a simple SQL select with a group by, none of these candidates could write any SQL. Any SQL. That's what makes tests important.
Perhaps it just shows there's more junior people in hiring decisions now than it was before. They remember what they had to pass to get a grade in their CS class two years back, and that's it.
All these tests are really assignments from Data Structures and Algorithms class, and being fresh out of college can help here a lot.
Like so many complaints about coding in interviews, this is talking about coding for a bad interviewer. Listening to both sides of the argument I've come to the following conclusion. Just as the unthinking mantra is now "90% of applicants for programming jobs can't program," equally often we hear "99% of interviewers can't interview."
Interviewing is a two way street, and programming jobs require more than just programming wizardry. You will need to work with a team, you will need to communicate with management, and you will need to understand people who aren't programmers.
I dunno guys. Shouldn't the C++/C#/Java dudes be ready for this? I am an SQL Server Dev/DBA and the code/design something on paper type questions are expected for us. Plus it goes even deeper with DMVs, system stored procedures, etc. I just don't get why the dev folks are surprised when an interviewer asks them to implement a doubly linked list or something along those lines.
Its because credentialism has permeated the software business recently. Credentialists love tests, its how they got their credentials, and if they don't keep believing in tests over real world performance, they will have to re-examine the true worth of their credentials.
Interviewers are coming to realize credentials, be they Microsoft certs or computer science degrees, are not great indicators of software engineering aptitude.
The more you believe in the accuracy of credentials, the less you would want to ask coding questions in an interview. Better to simply examine resumes for the appropriate certifications and then ask fit questions.
If on the other hand, you believe nothing but on the spot coding demonstrations can prove a candidates abilities, you would do exactly what these interviewers are doing. Perhaps these tests are not the optimal tests, but they sure beat credentialism.
This is why I don't ask candidates to code. I ask them to describe concepts, articulate trade-offs, and/or walk me through their process of solving a real problem (usually something I've just solved so that I'm intimately familiar with the space).
I hired someone who did brilliantly on walking and talking through all the conceptual issues. Turned out they couldn't code, and they couldn't touch someone else's code without breaking it.
Yeah, but then there's that whole other class of people who are great but can't deal with the pressure and awkwardness of coding on a whiteboard in an interview.
No interview process can be perfect, so unfortunately the trick is in correcting hiring mistakes early.
> people who are great but can't deal with the pressure
> and awkwardness of coding on a whiteboard in an interview.
We try really, really hard to allow for that. We try to get people talking first, and make moving to the whiteboard or paper or whatever part of the discussion, rather than propping them up and saying "Go!".
Additionally, in our line of work sometimes you have to program in a team under extreme time pressures. We've found that most people who can't talk about programming while sketching ideas and solutions in interview, can't do it for real.
The upshot is that you should always be testing for what you actually want. We want programmers who can design solutions, work in a team, get stuff done, ask questions when unsure, make decisions when necessary, change their mind when appropriate, and write programs that work. That's what we try to test for in interview, and before.
What do you mean grammatically incorrect? The singular they was used by Shakespeare for heaven's sake, its not some recent invention. Rather, the prejudice against the singular they (and the split infinitive) stem from when people looked down on ways in which English deviated from the rules of Latin. Personally, I think its silly to call any construct thats been in use for hundreds of years among educated people% and serves a useful purpose "ungrammatical".
%The Chicago Manual of style lists "Addison, Austen, Chesterfield, Fielding, Ruskin, Scott, and Shakespeare."
Using "they" for an ambiguous singular pronoun is perfectly good English. It was deprecated by Victorian grammarians who wanted English to be like Latin (the same people who ordered us not to boldly split infinitives).
Data structures and algorithms are the foundation. If I ever find myself unable to write a list or a tree or a sort, I'd better be doing a different job.
> Those who code at an alarmingly rapid rate, who get complex code compiled and running the first time around.
One word: Emergent design.
Coding shouldn't be done in large patches of perfect code, it should be done in small segments of perfect code that are individually tested for their correctness and build up the whole solution.
The fact I couldn't run my code every few lines would completely destroy my ability to produce anything beyond what I would deem pseudo-code even if it did, on the surface of it, look like real code.
This blog post strikes home. Anyone who has worked with me or seen my work has identified me as a top-tier developer, and yet I rarely nail any interviews because I never "sound" how the hiring manager thinks a good candidate should sound.
I've boiled it down to my salesmanship, or lack thereof. I don't like talking myself up, and therefore I have difficulty conveying myself confidently. And, as it goes with vicious cycles, each time I fail to do so lessens my ability at future attempts.
> Mistrust in applicants runs deep among hiring managers, and I have found that I must still perform Houdini tricks during the interview process, even if an insider vouches for me.
Even though I know I'm accountable for my salesmanship, I get this sense as well. It's incredibly frustrating to sense that you're being looked over as being a phony trying to pull one over on a company (how does this work exactly, anyways?) More often than not though, I've noticed this happens more with hiring managers who are not qualified technically to hire developers.
Yep, I'm right there with you. I know I'm not selling myself correctly, but the thought of putting anything on my resume that even remotely embellishes the truth a little makes me want to hurl.
Also, combine that with the fact that I hate my current job so much that I am afraid that my next just might suck as much, so I am being /very/ picky. I've turned down a couple of job offers that in hindsight I probably should have taken.
I would encourage people like yourself to put enough information your HN profile that you can be reached for networking purposes by other HN readers. Many of us may be in a position to offer interviews for non-suck jobs or pointers towards same, that we aren't going to post in open comments to the entire HN community, but would send targetted to the email in your HN profile.
If you are shy or anti-marketing, you may need to work just a little harder in mediums you are comfortable with to network. (This isn't directed at you specifically, MC.)
Seconded. I'm hiring and whenever I see HN posts I like I check profiles immediately for location information and contact details, or at least info on where I might find out more about someone.
You now have location there (which turns out to be fairly close to one of our facilities) but no contact information, so I still can't reach out to you.
If you're extremely uncomfortable listing an email address (or lisp form that evaluates to one or something similar), you can reach out to me based on my profile, but I'd really urge you to list some contact information in your profile, even if it's a throwaway account that you can easily walk away later from if the volume becomes overwhelming. If you're reaching out to me, add "HackerNews" in the subject line, please.
I mostly like this answer. It depends on the individual's time and how they balance against the needs of the rest of their life. I can judge a certain amount of motivation from outside contributions, but I understand it is not the only angle to learn about that.
I would add that you should hold an intelligent dialogue with your interviewee. This means doing more than just asking a question. Follow up. Not only find out if they have done something, but figure out if they understood what they were working on. Find some specific details in it. If you need a nice canned starter question for this: "What was the hardest problem you ran into when implementing X?"
In other words, interviewers should have filter dialogues, not filter questions. Genuinely learn about your interviewees. You must direct the conversation intelligently. That is how you can find the diamonds amongst the poor salesmen.
Do you think that being able to implement a linked list is a fundamental programming skill? Because if an advanced programmer is lost her ability to relate with novices ("my boss can't even implement a fucking linked list") I'd say that'd be a bad thing.
In my humble estimation, experts tend to be bad teachers because they have lost touch with the frames of novices. The best teachers are ones who have most recently mastered a skill.
It's a pretty damn fundamental skill; even so fundamental that I'm not sure if it even deserves a specific name.
As a linked list is nothing else but pointers and blocks of memory that are the nodes, and setting the pointers of nodes to point to other nodes. This is something any programmer worth his salt would soon deduce on his own even if he, for some mysterious reason, didn't know linked lists.
Many probably have in their younger days. And when they finally read about linked lists they go "ha, what I have written actually has a name". If you just merely keep doing allocations of similar structs or objects that you want to stash some place, you're implementing a singly linked list the minute you think of a "next" member in your struct.
Depends on the position. I have worked, recently, on codebases where that kind of thing was absolutely a core skill and we asked people to write linked list code in the interview process. We were also doing manually-managed core OS and display manager code for a mobile operating system.
In my current job writing server-side Java and Ruby on Rails code, I wouldn't dream of asking that question. It would be pointless.
Amen. I've worked perfectly happily and successfully in software for the last 10 years, writing what most of the software industry is writing - database apps.
I've never, ever, needed to write a linked list, a sorting algorithm, access memory directly and pass around pointers or any of the sample problems that are being cited here. I know the theory, I've done them in academia many years ago but I've got more important and useful things to remember on a day-to-day basis. These are firmly under the category of 'look them up if I ever need them again' and I'd be perfectly happy with a hypothetical candidate (I've not interviewed anyone in years) who said they knew the theory and would look up the exact details. I do that all the time with the more esoteric features.
At my last place, we did have a coding test as part of the interview. We checked all sorts of little things but could usually mark the entire test with some accuracy on the first question.
1. Please write a valid SQL inner join statement.
Seriously. For a position specifying SQL, to maintain an SQL backed custom business application, a majority of applicants couldn't write an inner join.
I suppose I'm saying - do whiteboard / paper coding tests, but do the _right_ ones for your projects. Don't give them a test on something that's clever but unnecessary for what you do, check they know the basics and are up to speed with independent learning and they should be fine.
I'd be interested to know what people think about coding pre-screening tests in general. As is obvious from my profile, I'm working on a startup trying that helps companies and recruiters easily implement coding tests to weed out people who can't code. This is a bit different than asking someone to whiteboard a solution - we're aiming to help companies get from a few hundred resumes to the top 10 or 15. We've commonly heard the problem (and experienced it first-hand) that people can't code, and we think coding tests helps solve that problem. I think it's a better solution than going by your past experience, because that's often fluff.
If I found this article by a potential applicant, I'd be much less likely to hire them. Besides the obvious red flag of the sentiment why should I have to code at a programming interview, the knowledge that they have been rejected by many other companies would make me worry.
I didn't have that impression (and I have been a hiring manager for 10 years+). It gave me the impression of someone senior. What I would then try to determine in the interview is whether that person has grown to become a strong developer, or rather has reached a level of incompetency.
But I wouldn't pass judgment either way based on that blog post.
Sorry you feel that way. Several hiring managers from top companies feel differently than you though, because they have contacted me directly and even asked me to apply at their companies. Does this mean that I've got an instant job ? Of course not. I still have much proving to accomplish -- to these hiring managers and their crew. But they obviously see a glimpse of something special in me -- which you don't.
I speak my mind...I live authentically. Yes, it's a risk to live that way, but I am willing to accept the consequences of my actions.
I understand where you're coming from, and yes, most people would probably do that, but personally, if I found a article by a potential candidate expressing their frustration with not being able to adequately convey their skillets and abilities, I'd make an extra effort to reach out and evaluate them more carefully so that I don't miss what they have to offer.
Maybe you haven't been in their shoes, so I can't blame you for your approach, but the phrase "diamond in the rough" exists for a reason.
From what I can tell, Google (and other companies) started using these kinds of questions as a way to cheaply filter sudden floods of applicants, not because this is the way to find the greatest geniuses of our time. Policies implemented under the gun have two unfortunate properties: they are wasteful and hard to change after the fact.
As the tactics of successful companies percolate through the rest of the industry, they take on a third unfortunate property: cargo-cult foolishness. Google asks binary search questions and they have great engineers. I want only the best engineers, therefore I will ask binary search questions. I don't know what else to do so I shall grade strictly on style points, because points are scientific, right?
Bleh. Put it another way: if there are a large number of productive creative people shut out by a culture of thoughtless interview checklisting, that's an opportunity for some smarter company to snap them up. Such a company would by necessity have an outlaw air about them. Who else would hire misfits? But gangs of talented misfits can be a powerful force.