Today's Coding Interview Game

http://www.shubharamani.com

by grayhairmomma • 16 years ago

132 118 16 years ago

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

tkahn6• 16 years ago

I think you mean that companies fear false positives which, in turn, causes a high false negative rate.

tgflynn6• 16 years ago

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.

jchonphoenix2• 16 years ago

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?

chollida1• 16 years ago

> Also the more knowledge you have the more difficult it becomes to retrieve that knowledge quickly.

I've never heard this about the human brain before.

I'm not saying you're wrong, because I don't know, but statements of fact like this deserve a good reference.

Do you have anything to back up this assertion of fact?

rsl7• 16 years ago

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.

ssp• 16 years ago

I learn more about you by seeing your relationship with your text editor

Are you sure you are not just learning whether the candidate is superficially similar to you?

aaronkaplan• 16 years ago

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

grayhairmomma6• 16 years ago

Bill Maher is my hero. Sorry if my swearing offended you, but it's just who I am.

KevinMS• 16 years ago

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.

Dilpil• 16 years ago

It is the opposite.

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.

nowarninglabel• 16 years ago

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.

j_baker4• 16 years ago

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.

wtracy• 16 years ago

Given how hard it can be to fire people, I don't blame managers for being risk averse.

hackinthebochs• 16 years ago

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.

hc5• 16 years ago

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.

mikeklaas2• 16 years ago

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.

AndrewMoffat2• 16 years ago

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.

alain94040• 16 years ago

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.

rimantas• 16 years ago

If the job is to code on whiteboard: definitely don't hire.

grayhairmomma6• 16 years ago

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.

mikeklaas2• 16 years ago

Good luck. I hope those leads work out for you.

sblom• 16 years ago

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.

blahedo• 16 years ago

But possibly not error-free the first time at a whiteboard. Talk about unrealistic conditions.

angelbob2• 16 years ago

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.

AndrewMoffat2• 16 years ago

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.

MetallicCloud3• 16 years ago

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.

sokoloff3• 16 years ago

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

Revisor• 16 years ago

I want to deliberately look for people like you. How do I tell it's you? The skilled but modest/unsociable/shy/... programmer.

varjag4• 16 years ago

Look at their hobby projects. And/or contributions to the public projects. Good programmers nearly inevitably leave some visible trace.

Swizec• 16 years ago

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

JoachimSchipper• 16 years ago

It's a linked list. It is a small segment of code.

skybrian• 16 years ago

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.

varjag4• 16 years ago

> I wonder how he knows what they're downgrading him for?

She. And yes, probably she knows. One usually has the feeling which part of the interview they fail.

grayhairmomma6• 16 years ago

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 ?

zackattack• 16 years ago

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.

angelbob2• 16 years ago

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.

eftpotrm• 16 years ago

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.

yason2• 16 years ago

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.

aplusbi7• 16 years ago

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.

It's as much about the process than the result.

timcederman• 16 years ago

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.

mech4bg2• 16 years ago

The thing that sucks is when the interviewer doesn't care about that, but instead cares about specific answers to their particular list of questions.

It can be astonishingly random who gets through an interview. Bizarre that just a few words can tip the balance.

ZoFreX• 16 years ago

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.

misterbwong• 16 years ago

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.

aristus• 16 years ago

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.

Natsu• 16 years ago

> Policies implemented under the gun have two unfortunate properties: they are wasteful and hard to change after the fact.

You've just described how we ended up with many of our problems in the government, military, education & private industry all in one sentence.

A single upvote doesn't seem like enough.

sokoloff3• 16 years ago

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.

I'm not a Joel fan boy, but I think http://www.joelonsoftware.com/items/2005/01/27.html states this problem more clearly than I can in a few paragraphs on HN.

Retric2• 16 years ago

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.

tgflynn6• 16 years ago

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.

davidsiems• 16 years ago

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.

Evansbee2• 16 years ago

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.

Which would you choose?

j_baker4• 16 years ago

Unless I was hiring a professional whiteboard coder, I would find another method.

Evansbee2• 16 years ago

I believe that /this/ is short sighted.

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.

msie• 16 years ago

It's hilarious that some commenters here refer to the author as a guy.

mmt• 16 years ago

Your amusement seems to me to be based on a false assumption.

"He" could be gender-neutral, and perhaps they're encouraging equality by ignoring the sex of the referent.

http://news.ycombinator.com/item?id=1795518

grayhairmomma6• 16 years ago

Trust me. I'm all girl.

mech4bg2• 16 years ago

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.

mavelikara• 16 years ago

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.

Also, I think that the interviewer anti-loop that Steve Yegge mentions (http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...) is real.

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.

csjohnst• 16 years ago

How good a programmer can she be when there's not even a Hello World post on her blog, just this rant... just saying...

ericflo3• 16 years ago

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

RiderOfGiraffes3• 16 years ago

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.

I need to see someone code.

ericflo3• 16 years ago

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.

darwinGod2• 16 years ago

Like the subtle use of the word 'they', incorrect grammatically,correct politically

RiderOfGiraffes3• 16 years ago

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.

Start by understanding interviewers.

aarp• 16 years ago

and you, you're just too f*cking, blond!!!

blond = old.

varjag4• 16 years ago

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.

edw519• 16 years ago

on a white board, no syntax errors, compilable

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.

bmj2• 16 years ago

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.

aplusbi7• 16 years ago

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.

grayhairmomma6• 16 years ago

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.

aplusbi7• 16 years ago

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.

agentultra• 16 years ago

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

aplusbi7• 16 years ago

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

pitdesi• 16 years ago

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.

z0r• 16 years ago

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.

davidjhall• 16 years ago

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.

golgo13• 16 years ago

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.

Today's Coding Interview Game

Related Stories