Fog Creek Software
Discussion Board

Interviewing for Senior Position (again ...)

The topic of interviewing on both sides of the table seems to come up quite a bit here and I'd like to bring it up yet again.

My colleague and I are doing phone screens of people applying for a Senior Engineer at our company. We've done a handful of these phone interviews so far and haven't found a single person to invite for on-site interview, even though the resumes looked excellent (someone else is doing the first pass resume screening). We're a very small shop and the person we'll hire will have ownership of all aspects of a a significant subset of one of the products and should be able to teach the more junior people how to do "the right thing(tm)."

Most of these phone interviews seem to follow the same pattern. First,  the person describes a project that he or she worked on and it looks great.  Then, we ask a couple of simple technical questions and the responses are really poor. These technical questions focus on very basic skills - understanding the language features, oo concepts, and data structure selection. Yet most of the candidates I see applying for a Senior Engineer position are unable to give statisfactory answers. This is despite claiming 5-10 years of experience, including a number of years leading development of real products.

I have two possible explanations for this - we're not seeing good people or we're asking the wrong questions. I don't know how to address the first possibility because even with the resume bullshit filter on, these people had the right experience. However, I can try to gage the latter.

Just today I interviewed a person with 10+ years of dev experinces, last 3+ doing J2EE development and C++ before that. It was another bust. The person couldn't clearly describe diffrences between checked and unchecked exceptions in Java, tell me why you would want to use one or the other and whether having checked exceptions is a good thing in the first place. He wasn't even sure if or why you can use finally without a catch (he definitely sounded like he's never used it). On the data structure selection question, he could not explain why hashtable is a right choice for a lookup by key. He wasn't sure where the hash code comes from and told me he never had to override hashCode() in any of the code he's written. Should I not expect someone with this much experience to know how hashtable data structure works?  Anyone I've worked with who I conisder a good senior engineer could answer these questions in their sleep.

This pattern has repeated itself over and over, so I'm a bit concerned that we might be rejecting some good candidates by asking the wrong questions. There are always some false negatives and false positives, and, I realize, the cost of hiring the wrong person is very high.

Is the great majority of people who have seemingly relevant epxerience just clueless? Or, are we looking for the wrong skills? I'm of the opinion that if you can't do basics well, you can't solve more complex problems, either.  Of course this is just my opinion, I could be wrong. What do you think, America (and beyond in this case).

Frustrated Interviewer
Friday, March 28, 2003

I've seen some doozies in the last few years.  Once I was interviewing people for a senior technical position, and had one candidate who verifiably had 10+ years of develeopment experience and looked great on paper.  We asked him some simple math and analytical questions just to get a feel for his critical thought process, and found that he couldn't tell us what 2^3 was, or chart the equation x=y.  The work I do doesn't require much math background, but the guy couldn't do highschool level algebra. 

Another time, I was interviewing people for a software manager position.  The candidate was a senior software manager at HP, with a great resume.  I met him out on the street in front of our office so I could show him where to park, and he SERIOUSLY did not know how to operate the parking meter.  "Oh, you put money in it?  How do you know when your time is up?"  Again, the job had no requirements for parking meter skills, but for me it was a huge red flag that the guy was lacking in simple basic thinking skills.

Colin Evans
Friday, March 28, 2003

The 2 questions you listed sound a little like trivia questions to me (though I'm not a J2EE programmer).  Obviously, I don't know what other questions you asked, but I'd stay away from asking very narrow questions like the ones you mentioned.  You need to find out if the person can think, not whether they know x piece of information.  Unless you need them to implement x piece of information immediately a smart person will figure it out quickly enough.

Also, just because someone has been programming in y language for 10+ years doesn't mean they know every detail of y.  Maybe they were doing simple data access web pages the whole time.  That doesn't mean they're not smart, just that they had a job that didn't give them the opportunity to learn skill x.

Friday, March 28, 2003

Be *very* careful about judging someone based on your experiences.

Over the past year I've been in the internals of the ASP.Net datagrid like you wouldn't believe, and I'm sure if I was interviewing someone I'd ask them what event allows them to format a control in a datagrid based on the data. But I find that lots of good .Net coders have never used the ItemDatabound event.

This doesn't make them bad coders - they just haven't needed to, or haven't found it.

Maybe I'm wrong, but I'm not positive that identifying that their sphere of knowledge doesn't overlap yours makes them a bad coder... Why don't you ask them to bring some sample code to the interview then grill them about the code they've done?


Friday, March 28, 2003

It's my opinion that asking specific ( especially but not limited to obscure ) questions about a language or any aspect thereof, (THAT YOU MAY KNOW OR HAVE USED ) is a very fickle way of determining a candidates ability.

If you want to determine if they know those things, give them a test that asks those questions AND give them the resources to find the answers.  If they still can't determine the answers in a reasonable length of time THEN you know they are not motivated and probably will not step up to the plate if hired.

I am not saying that there aren't things a candidate should know off the top of his head, but I believe that most employers expectations may be a bit over-emphasized in their quest to find the 'ideal' candidate AND the job-seekers view of themself is skewed also.  This has to be taken into account.

I think it's important to remember just because you know these things does'nt mean everyone will.  Sure the guy may have been 'programming' J2EE for 3 years and C++ before that, but what EXACTLY did he program?  Does he have proof?  Was he a maintenance programmer?  What did the company he worked for actually do?  Was he a PC Tech/Help Desk/Programmer?  Did his previous supervisor say he surfed the web all day?

I think the key here is UNDERSTANDING and COMMUNICATION.  It's frustrating for both sides and labeling candidates as CLUELESS is not very professional and does not help either side.

As for the parking meter incident?  Who cares.  I had not seen or operated a parking meter, until I joined the service and got 'out' of small farm town USA.  Did you ever think the guy was a little nervous because he actually had never used a parking meter not to mention he was probably nervous about the interview?

As for the guy that could'nt do the math, maybe he had FORGOTTEN IT.  Maybe he only worked on web pages or database access and did'nt use math.

My point is there are reasons why people act the way they do and for you to judge them outright without knowing them, their history, their situation, their personality etc... Well I think the Bible says something to the effect of You see a speck of dust in another mans eye but fail to look at the log in your own eye.

Friday, March 28, 2003

Understanding the difference between checked and unchecked exceptions seems pretty fundamental to calling yourself a Java programmer.  I don't know about the hashtable thing, but everything I've seen indicates that at least if you have a CompSci major you should know about hashtables; if you're self-taught, though, perhaps it's more questionable.

For the sort of position you're looking to fill, the questions don't seem unreasonable.  Someone with as much experience as you're seeking should have been programming since at least early 1998, so his/her entry into programming should have preceded the dot-com boom.  I think it's probably just that hard to find qualified people, as the ones who don't know their stuff are without jobs while the ones who do are kept happy at their current workplace.  Either you'll have to lower your standards or just expect it to take a while.

Friday, March 28, 2003

As for the parking meter guy, it's one thing to be fiddling around with a program to figure it out on your own PC; it's quite another thing to be trying to figure something out in public.  Don't write the poor guy off just because he doesn't know how to do something that "everybody" should know; any situation like that where there's the potential for people staring at you while you try to figure something out can be nerve-wracking for anyone.

Friday, March 28, 2003

I like Joel's approach to interviewing; all he wants is someone who is

Smart, and
Gets Things Done.

Now, which of those do you want to replace "Knows how hashtables work" with?

Three years experience with Java? Great! Show me what you've done! Bring me code! What have you delivered?

If you were interviewing me, would you care more that I don't know how a hashtable works, or that a system I built single-handedly has processed over four million dollars in live transactions in the last four weeks?

I'm kinda talking around my point here - does it matter if he knows the nuances of the specific things you ask about, so long as he can produce good code or design capable systems?


Friday, March 28, 2003

>> "I think it's probably just that hard to find qualified people, as the ones who don't know their stuff are without jobs while the ones who do are kept happy at their current workplace."

Not a true statement.  There are qualified, honest, knowledgeable people who are still looking for work.

Friday, March 28, 2003

If you don't ask for what you want, you are unlikely to get it.  Do you know what you want?

I've been around a number of people who have been programming for quite a while that would probably fail your screen.  It's not the years, it's the work they've been doing.  Most of us are paid for "make our inventory system work", rather than "learn the art of programming".  You certainly hope that people pick up the latter along the way, somewhere....

Maybe it's just me - but don't most programmers end up following the standards (if any) established by the few members of the team skilled in such things?  And if somebody upstream of you has set up things so that they just work, would you notice?

(Silly example: how can you not already know everything there is to know about Bresenham Line-Drawing Algorithm?  You've been watching it on your monitor every day?  Well, it just works).

You could try making the questions more general (is there some trade off decision experience that you would accept that isn't specifically exceptions?  Can you ask that question instead?) but it sounds like the candidates you've seen wouldn't fare any better with that.

Can you improve the job description, to clarify the sort of candidate that you want?  If resume screening doesn't work, perhaps ask for something instead of a resume?

Friday, March 28, 2003

To address "Frustrated Interviewer"'s questions:

I'm an experienced Java developer (working on J2EE stuff) and I can tell you right now -- those questions you asked are not only very reasonable -- they're also very basic. Every one of the cited examples is an excellent question.

These questions are not the trivia questions that some people would seem to think they are - they in fact are testing the candidate's basic understanding of the fundamentals of the Java language. For example, if they can't explain why overriding hashCode() (and equals()) is not just a good idea, then I can absolutely guaranteee that person is not qualified to be a senior Java developer. It's simply a question of having the basic knowledge required to make sound design decisions, let alone writing code that actually works the way they think it does.

An example of a useless trivia type question would be to ask questions about some esoteric API or something that is not used by a lot of people -- e.g. asking questions about JTable or the JDPA. I've worked with both in the past, and frankly if someone asked me a question about them, I'd say "I have no idea. Give me the documentation and I'll tell you".

If you're working on something interesting and are near good skiing, you could always drop me a line... :-)

Friday, March 28, 2003

EVERYOne should be able to at least GUESS what a hashtable is, and how it works.  I think its unreasonable to expect someone to know all of your trivia questions, but they should be able to make very educated guesses.  We ask "trivial" questions like that quite often to 1: see if they lied on their resume and 2: to see if they can make an educated guess, or say "never used that, but I did program in Perl and we used hashes there and they worked like xxx ...".  I think there are way too many people who think they deserve senior positions because they are above average.  The problem is, being above average does not make you good enough for a Senior position.

Vincent Marquez
Friday, March 28, 2003

Unlike most of the others here, I think it's reasonable to expect at least passing knowledge of the core system if that's what you're using and what they claimed to use. I don't see how you can use Java without knowing what exceptions are, given checked exceptions.

*shrug* Defining "smart" in Joel's list could very well include seeing that they knew something about the things they claimed to. Or maybe that's "honest", and it needs to go onto the list, too.

Brad (
Friday, March 28, 2003

Thanks for asking the "checked vs. unchecked" exception question.  I don't use Java very often, but I do a lot with C++, so I decided to figure out a good answer, searched with Google, and found Bruce Eckel's critique of them.  That jogged my memory of how they worked, and now I've got yet another bit of language fluff in my head. :)

BTW, unchecked exceptions seem to be problematic based on what I read, with unintended consequences because its easier to catch them and do nothing just to get your code compiling, and now you've lost the exception at a higher level.

Bruce's article is at

Ben Combee
Friday, March 28, 2003

I like the question about try/finally with no catch.  It's not trivia, and it certainly isn't covered anywhere I have looked, but it is *so* helpful for writing correct code.  I would go so far to say that this idiom is necessary given the existence of unchecked exceptions.
It would be like asking a C++ coder about RAII.  Maybe you don't *need* to know what it is, but if I were doing the interview, it would be *major* bonus points.

Friday, March 28, 2003

First, let me say that if you are looking for a very specific type of candidate (just like Mike who left to go work for XYZ, inc.) then you should choose a candidate who fits at least 80% of your criteria and then hire him/her on contract-to-perm basis. This way if the person doesn't seem to be working out after a week or two you can let him/her go without incurring a substantial financial loss (except in time).

FI wrote, "teach the more junior people how to do the right thing"

Everyone is looking for this type of candidate. The problem of course, is that every company and every job candidate has their own idea of what the "right thing" actually means.  Another problem, is that employers tend to interview candidates who possess this type of knowledge just like they would if they were interviewing someone for a junior coding position.

Analytical thinking and communication skills tend to be the skills most employers REALLY want, however, it seems like many technical interviewers cannot get past the "I nead someone who has read all the volumes associated with Donald Knuth's The Art of Computer Programming" type of thinking. On most jobs, most people will be asked to do things they haven't done before, and for talented IT professionals, this is no big deal.

Please clarify the following for me:

* Senior Engineer - is this simply a fancy title for someone who has held a coding position for several years or does it mean something more at your company? Most people that I know who call themselves software engineers are able to competently talk about all the various aspects of the software development process (not just the construction phase).

* What type of "products" are we talking about here? Your company shouldn't be looking for a C++ or Java programmer who has extensive in-house business application development experience if your company produces commercial software products. Genarally speaking, these two work environments tend to be very different. While still in college, I interviewed for a non-coding position inside an aerospace firm that did work for the government.  I looked at the work (i.e. code) some of their software engineers had written and I can tell you that the stuff they needed to know is very different from what a C/C++ coder would typically need to know when working for an insurance company.

* Un-statisfactory answers to technical questions that focus on very basic skills - When a candidate doesn't provide the answer you are looking for to a particular question what do you do? Do you simply move onto the next question on your list or do you temporary veer away from your script and engage the candidate in additional conversation, such as, mentioning "it sounds to me like you have never used X it is this true? [wait for an answer]. Why .......? [wait for an answer]. I have to honest with you John your responses to this question really concerns me because....

FI wrote, "This pattern has repeated itself over and over, so I'm a bit concerned that we might be rejecting some good candidates by asking the wrong questions."

Yes, this could be the case, however, it is hard to tell from your short post what you REALLY consider a good enough candidate to be. You are not giving us a complete picture here.

One Programmer's Opinion
Friday, March 28, 2003

One final question.  Who is doing the first pass resume screening at your company?  Could it be they are filtering out the right job candidates?

Maybe you and your colleague need to take over this responsibility? 

One Programmer's Opinion
Friday, March 28, 2003

I think your ability to interview is poor and that the approach demonstrated by your questioning probably indicates poor, not good, software development practices at your company or workplace.

If someone has ten years experiencing producing good product, they are by definition probably pretty good.

Your focus on narrow gotcha questions that you and your circle of like-minded friends consider to be the arbiters of competence suggests an inability to analyse problems well.

Anyone who's developed product for ten years can easily adapt to using exceptions the way you consider important. He might even explain to you why your way is problematic.

Friday, March 28, 2003

"If someone has ten years experiencing producing good product, they are by definition probably pretty good."

Agreed.  But how do you figure out that they *did* produce good product?  Even if you have personal knowledge of the product, and know that it's good, how do you determine that this candidate contributed anything significant to it?

Years ago I was interviewing microprocessor designers, and happened to talk to a number of people from Intel.  Several of them claimed to be chief architect of the same good product.  At that point, substantive technical questions are in order.

Hardware Guy
Friday, March 28, 2003


I don't think asking basic question is "gotcha". Every Java developer I've talked to knows about exceptions, and every good architect has been able to discuss their feelings on checked vs. unchecked exceptions.

I suppose in some circles, the "top tier" of development just designs but doesn't write code, but that's never been the case anywhere I worked (even for medium-large orgs).

Brad (
Friday, March 28, 2003

I would look at your screening process, and all the way back to your advertisement.

While everybody slants their resume to improve their job prospect, many inflate their qualifications and a few outright fabricate them.

I remember when I was looking to change jobs in February 2001 the typical job ad asked for 10 years Java and 3 years .NET. Hmm, Java's first public beta was fall '95 and .NET at that point was about six months worth of marketing hype in search of a technology. So, the only people who got interviews were the bald-faced liars.

Make sure your ad is realistic. That the requireds are really required and everything else is a "nice to have".

Examine your screening. Makes sure that the screener knows what is realistic. IE anyone with more than eight year of Java is a liar.

Make sure the screener understands what other technologies are related. IE not just C++, but Objective C, Smalltalk, Delphi, CLOS, OCaml, etc.

Have the screener look for other signs of skill. IE familiarity with multiple paradigms such as functional (Lisp, Scheme, Haskell) or declarative (Prolog).

Unfortunately the sad fact is that there really aren't very many seniors out there. The internet boom turned every semi-competent junior into an overnight senior.

Anonymous Coward
Friday, March 28, 2003

When I'm hiring, I don't phone interview. I phone *screen*. My objective is to answer one question in ten minutes or less:

Is the person on the telphone the person described in the resume?

I have already decided that if they are, in fact, the person in the resume I wish to invite them in for a face to face interview. (If I look at a resume and I'm not sure whether to interview them, I usually follow Joel's dictum: no hire.)

For that purpose, I usually use technical questions that are non-trivial. If someone claims Struts experience, they absolutely positively know the difference between an Action and an ActionForm. So I ask them.

If they claim to know Design Patterns, I ask them to name their favourite three patterns and describe when to use them. This is stuff *they* put on *their* resume!

There definitely are certain things everyone knows. Those questions won't discriminate between a good coder and a bad one, but I'm not trying to accomplish that on the telephone: I just want to screen out those who are dishonest or desperate enough to lie.

FWIW, if someone is junior and confesses to exaggeration, I usually give points if they follow up with an email answering my question after the fact. I give latitude for junior people because I know that this industry as a whole values "X years of Y" more than "Smart and Gets Stuff Done," and juniors are often too green to avoid such places when they're starting out.

Reginald Braithwaite-Lee
Saturday, March 29, 2003


that seems like a great way to go.  We tried that during our interviews, but your way seems even better.  I bet you screen out almost all of the applicants who lie on their resume.  I think if more people screened like you do, there would be a LOT less exageration going on in resumes.

Vincent Marquez
Saturday, March 29, 2003

You are a bit slow, you are interviewing quite a number of senior developers and are of the belief that somehow THEY don't measure up.

My guess is that you've worked in this one company for too long.

Can't you see what's really happening?

You don't measure up.

Sunday, March 30, 2003

Part of the problem in asking for specific details about how something was solved in the past in order to gain some insight in whether they did what they claim, or they even understand what they did is that once a project is past, its dead. To get back inside it and exhibit enthusiasm for it can be difficult and so only the surface detail comes out.

Often then the person comes across as hesitant possibly even evasive.

I'm confused about Reginald's approach, if someone fell at those kinds of questions their CV would likely be inconsistent and I'd not consider them anyway.

If you're going to talk to someone about a job, its an interview, I don't care what you call it.  If it is an interview then it has to have all of the controls that any other face to face interview should have.  This means if you're going to ring them up, either warn them in advance and tell them the nature of the call, or be prepared to get bad results.

If you use the phone to interview someone remember you're getting a very specific idea of the person, their telephone manner might be appalling but their competency high; they may have a winning way on the phone and be adroit and lubricious with the right phrases, but be totally useless ~ except in sales.

Any interview has to be a conversation, I've found its better to be enthusiastic about the nature of the project and then encourage them to express ideas about it, if its led into naturally then they'll call on past experience and introduce it themselves.  Then you can be more specific in your questions (still conversational).

Doing this by phone is hard, not least because in order to be fair to all candidates you have to present those same questions, make it formulaic and you'll get formulaic answers (or none); make it free form and you have monitoring problems.

Simon Lucy
Sunday, March 30, 2003


IMO your questions are ok, I don't see anything disproportionate there.

Typically when I ask this kind of questions I don't really care if the answer is right or wrong, instead I expect a well thought opinion which makes for a  good interview start. "How do you use checked exceptions?"  does not ask for an exact answer but a summary of exception handling best practices. Same with try/finally ... one should at least figure out this is the only way to provide robust resource management (even when exceptions are not caught ... although IMO one should at least catch and log)

In all cases, with 10+ years under the belt, a true programmer can come up with a decent answer.


Monday, March 31, 2003

echidna, I'm not sure what you mean by "gotcha" questions.  In my way of thinking a gotcha question in java would be, "Under what circumstances should the 'extend' keyword be used in Java?".  The point of the question being that it's 'extends', not 'extend'.  _That_ is a stupid gotcha question, because the compiler will catch an obvious misspelling, and you can easily look up how something is spelled.

On the other hand, telling the original poster that the questions he asked are gotcha questions indicates that you don't know Java.  I'm just a Java learner myself, but I know enough to know if you don't know the answers to the questions FI asks, you have no business calling yourself a senior Java developer.

Many of the responses here seem to indicate that there are a lot of bitter people around here.  Maybe someone should start a "stupid interviews I've experienced" thread so people can get it off their chest there instead of here...

Monday, March 31, 2003

To clarify my approach, I'll describe the overall idea:

1. Given a reasonably competent candidate, I can only determine whether they are "smart" and whether they "get things done" face to face.

2. There are always more resumes than time.

3. Therefore I set up a filter system.

4. Stage zero is attracting good resumes. I won't go into a lot of detail, but participating in forums like this is definitely part of the process.

5. Stage one is filtering the resumes. Most of the crap ones are, as Simon suggests, easy to filter by eye. But still, I want people who are smart at programming, not smart at writing good resumes. So I reject as many as possible without calling or emailing the subject, but if they look like they could be smart, I don't reject them yet.

6. Stage two is the phone screen. It isn't an interview, and I usually distribute this 'chore' across the whole team (to be conducted outside of thinking and programming time). This is where we ask one, maybe two questions and reject those who obviously lied their faces off.

7. Stage three is the technical audition. This is solving a Microsoft style problem and writing some code on a whiteboard. No, we don't provide a computer and a net connection. But we also don't care whether they get all the semicolons or parantheses right. Here's where we determine baseline "smart".

8. Stage four is the interview. This is where we ask about real world problems and how they solved them. That's where we determine "gets things done."


In the context of this larger process, the phone screen exists only to make sure that we aren't wasting our timne setting up a technical audition. It takes ten minutes or less, and it usually knocks half of the candidates out. And I have tried, but I can't spot those candidates from their resume alone.

Reginald Braithwaite-Lee
Monday, March 31, 2003

Maybe we should question the value of interviews as a means for hiring people. I've found interviewing an extremely unreliable means of finding talent and everyone I know who has systematically reviewed the results of hiring based on interviewing has had the same negative experience.

I don't think I've every hired anybody dumb or incapable after interviewing them, but I've certainly hired people who were very smart and lazy or very smart and uncontrollable, etc.

The only sure-fire method I've every found for hiring is to only hire people I've worked with personally or only hire people with a strong recommendation from someone I trust. I just keep working my network for all its worth.

I understand that my method is limited to my network size.

Monday, March 31, 2003

I find that people are often not honest in their
appraisal of people they have worked with that
are considered friends. I am often disapointed
when interviewing people that are highly recommended.

So i don't put a lot of stock in recommendations.

Monday, March 31, 2003

< 6. Stage two is the phone screen. It isn't an interview>

Umm how is it _not_ an interview?  Its direct communication with the individual, its asking them questions, its formulating some kind of view of the candidate.  So, one has to be careful all of the non-discriminatory legislation (in whichever jurisdiction), phone interviews, as I've said, are difficult to monitor for this.

Simon Lucy
Tuesday, April 1, 2003

I don't think you're out of line on the Java questions.  I'm a Python programmer who's never written so much as a Java applet, and I could answer both the exception and hashtable questions.

But, I don't know that they're the most useful questions, either.  I'd ask those kinds of technical knowledge questions for a more junior position.  (Yes, my standards are incredibly high...)

Here's the classification scheme that I use to sort seniority:

Level 1: Has shot self in foot repeatedly, or had it shot by management.  Doesn't really notice that there's any problem.  (No hire.)

Level 2: Experiences pain from foot shooting.  Will talk about previous shooting incidents.  Is slightly wary of firearms, but hasn't necessarily made strong cause-effect connections yet. (Junior position, if technical skills are good and willing to adapt to shop practices.)

Level 3: Seeks to avoid being shot.  Discreetly inquires about firearm safety practices at our workplace.  (Hire!)

What's interesting is that I've found the simplest way to accomplish this screening is to be blatantly up-front with people about what I'm doing in the interview and why.  Fakers and idiots don't actually listen, even when I give them the answer to my question in the preamble to the question.

For example, I sometimes will give people a programming puzzle (an acyclic graph sort) after telling them that I am looking for people who can solve problems *without* writing any code.  In the introduction to the problem, I further imply that the structure of the problem is identical to the problem of a "makefile" build process.  But at least 4 out of 5 people then try to solve the problem by writing code - without even asking for more detailed requirements or inquiring whether they could just use "make"!

"Gets things done" would demand that they ask about requirements, or that they would suggest looking for existing libraries they could use to do the graph sort, etc.  I make it quite plain that I am not trying to test their ability to write a graph sort algorithm; I've often said point blank, "this is not a test of your programming ability.  This is a test of whether you understand how to get things done while meeting business requirements."

If I'm met with a blank look, I follow up with, "Here, I'm looking for you to tell me how you'd get this done, without writing code.  For example, I just hinted that you could do this with "make".  How many other ways could you solve this without having to write code?"  In the rare cases where a solid candidate was uncertain what was expected, they usually say at this point, "Oh, I was wondering why you didn't just use "make".  Okay, I get it."  And then they proceed to talk about where they'd look for libraries, ask for more requirements, etc.

The other 4 out of 5 continue to stare blankly.  (Sigh.)

Frankly, "Smart and Gets Things Done" is the *toughest* requirement to meet in hiring and will eliminate 90-95% of my candidates for a senior engineering position.  If I find somebody who's really "S&GTD", I usually don't care very much about their specific technical knowledge.

Phillip J. Eby
Tuesday, April 1, 2003

Guy, What a late reply, but What Joel has asked is straight forward, This is an issue about very basic thing that can cause a big time trouble in run time environment. And i defenately don't want lousie chap working on my team that writes code that may break in production. environment

same as joel here
Monday, April 5, 2004

*  Recent Topics

*  Fog Creek Home