How To Hire Me (or any other programmer)

http://www.youell.com/matt/writing/?p=898

by softbuilder • 13 years ago

346 250 13 years ago

ttrreeww• 13 years ago

Cash, lots of cash!

mooreds2• 13 years ago

Wow, full of great advice. The biggest one for me is: acknowledge applicants. I've hired and know what a hassle it can be, but use a system, and respond to everyone. Set deadlines, and if you miss them, acknowledge that. Look, this is a possible team member--why would they believe you'll treat them with respect when they are employees if you don't treat them with respect when they aren't?

Basically, it's the golden rule. It's not hard!

illektr1k• 13 years ago

If you give me a few seconds of your time to say thanks, I probably won't mind spending a few minutes staying late to get a task completed.

mooreds2• 13 years ago

Or thinking of a friend who might be a better fit for a position, or trying your product/service, or recommending your product/service, etc. The dividends of being kind and humane are pretty amazing.

RandallBrown• 13 years ago

I can't even begin to describe how worthless I think most coding interviews are.

Here's a contrived problem, that will never come up in our work. Now solve it by writing your code by hand without a compiler or any other tools that you would use in real life.

I understand that these questions are often about seeing how you think and how you solve problems. Throwing annoyances like writing code on a whiteboard into a high pressure situation doesn't help that at all.

niggler8• 13 years ago

Writing code by hand reveals far more than you give it credit for. Someone omits a semicolon? Bam, conversation about semicolons or ASI.

It's not about the fanciest solution. And anyone who does it that way is foolish. It's the purest test of Language facility, and a really good springboard for all kinds of questions.

Downvoters: have you actually tried to hire someone?

gambler2• 13 years ago

I didn't downvote, but I disagree and I did try to hire someone. Whiteboard questions are next to useless because they are, essentially, a guessing game. The candidates need to guess what behavior the interviewer wants them to exert. Some interviewers simply use it as an idiot filter, while others want the person to explain their reasoning, wile yet another group is stupid enough to think it's representative of real coding habits of the candidate. If the candidates guess incorrectly, they will fail the question, regardless of who they are or how good they know their trade.

In short, interpretation of whiteboard questions is too damn subjective.

xyzzyz• 13 years ago

Conversation about semicolons? During a job interview? I'm sorry, but this is a waste of time. Why don't you talk about, you know, algorithms? Concurrency? Databases? Testing? Or anything that is more than remotely relevant to the job?

mgkimsal4• 13 years ago

I'll go one further.

I had an interview several years ago. Talking with the owners, small shop (6 people? 8?). We get to a "let's code something on the white board" segment. Fair enough. "Write me some code that does XYZ" (I honestly don't remember what it was - something basic but not trivial).

I took the marker, went to the board, put the marker to the board, then turned around and asked a couple questions. They answered, I sketched out a few lines of code, and that was that.

I sat down and one of them said that I was the first person ever to ask a question before writing. Everyone else had started writing, got part way through, then asked for clarification on the ambiguous parts (or worse yet, never realized part of it was up for interpretation).

Everyone handles whiteboard tests differently, but it was interesting to me to get that perspective shared with me about asking questions before writing on the board.

run4yourlives2• 13 years ago

The problem is that at least 60% of people that call themselves programmers, and seemingly have no issue getting by HR, can't code fizzbuzz, let alone whatever it is you're working on.

Issue one for me as an interviewer, whenever I've needed to be in such a position, was just to figure out whether or not I was talking with a programmer.

After that though I tend to agree with you. Beyond demonstrating basic competence - which I think in the future I will look to put into some for of pre-interview screening - code writing tests don't do much.

Personally, I've found bringing my current work in with me and talking about different ways of solving the issue seems to work pretty well.

Falling36• 13 years ago

I've heard various numbers like this thrown around, but I'm having a hard time seeing how it could possibly be that high. Is that figure coming from personal experience?

I also struggle with that idea since I'm very capable of programming fizzbuzz and a lot more, but am still having a problem finding a new position.

Falling36• 13 years ago

Not too mention that many of those contrived problems are recycled, so a little studying goes a long way. What exactly does that prove?

lessnonymous8• 13 years ago

It's not a test of your ability to recollect something. It's a conversation. If you're just regurgitating the greatest code solution ever but can't explain why it's so damned good then you're not very impressive.

There ARE contrived problems that you can just regurgitate an answer for. (Why are manholes covers round? Because manholes are round duh!) And if anyone asks you one from the lists that are on the interwebs, they're probably just asking because that's What Google Does

kailuowang• 13 years ago

As a coder, I couldn't agree more with the last paragraph (Let Me Code). Other than paring interview, I also like code submission. The company gives you a problem and couple of days and you write the code like you would in a real project. IMO, nothing reveals a developer's coding capability more than that.

brian_wendt• 13 years ago

Wow, can't tell you how much I have seen and experienced the BS that you mentioned. The company I'm with right now may be hiring soon, fwd this article to my boss. Thanks

Mc_Big_G• 13 years ago

Want to get my attention? Tell me you don't use email as a project management tool. Tell me you won't send me 5 emails a day. Tell me you don't want two status updates/meetings per day. Tell me you understand that the shotgun approach to adding features is stupid. Tell me that you don't randomly change features without any kind of data to back up the reason for making that change. Tell me you follow through on promises. Convince me you're not a fucking liar. Tell me you're offering benefits packages commensurate with your senior engineer position. After that, in addition to what OP said, I'll consider responding.

zem• 13 years ago

honestly, if i got a recruiting mail that emphasised a strong commitment to tool-based programming best-practices (dvcs, review, continuous integration) it would raise my interest in the company significantly.

Glyptodon3• 13 years ago

I find sarcastic naming conventions can help the pain just a little. But yeah, otherwise completely agree.

ryderm• 13 years ago

> If you don’t have genuine passion for where you work and you do the hiring, you’re committing some kind of moral fraud. You might want to see to that.

Never really thought about this before, but I totally agree.

pekk5• 13 years ago

Almost everybody is playing some minor role in making someone else a lot of money. That also includes people doing hiring.

All this kind of statement will do is make companies extract faked workgasms from their employees every day.

cliftonmckinney• 13 years ago

We've been working to solve this problem for a long time at https://workforpie.com/.

I completely agree with everything OP says, but I'll tell you what the real problem is: time. This is especially true in early stage startups and consultancies, where oftentimes the founders are still building stuff 95% of the time.

Recruiters are easy (as are, by the way, the new wave of non-recruiting recruiters like Developer Auction). Pay the man his money, and get a candidate in return. The founder doesn't have to spend time communicating with candidates or really doing any of the stuff OP mentions. That's why a lot of companies still hire recruiters. (Some of the companies) don't care what happens before the viable candidate walks thru the door, they just care that he/she does. It's like buying an iPad. Most of us don't think about, and don't care to think about what it took for that iPad to make it to us. We just care that it did and that it works as advertised.

Recruiting: the most important thing most companies don't have time for...

There's absolutely a better way, and in the end it's less time-consuming than what most companies do now. But the up front work is harder and more time-consuming. Convincing someone who's time is worth more than his money to adopt the better way is a hard thing to do.

Glyptodon3• 13 years ago

I wonder if it's possible to move from employer to employer getting paid more and more by spending all your time answering questions on Stack Overflow instead of working...

gambler2• 13 years ago

Thank you for putting this into words. I wanted to write something similar for a long time, but didn't get around to it.

Not only these things are frustrating for us as developers, they also decimate IT recruiting for companies. I've seen it from the other side too (while conducting some interviews). It's quite incredible, really. It's like a game. Both sides go through all the usual motions, but gain next to no useful information about each other. In the end it all boils down to unsubstantiated personal impressions, coated with some generic BS that makes it sound "objective".

(Before you ask, it's very hard to change interviewing process when you're a part of an established process with a lot of people involved.)

Glyptodon3• 13 years ago

I've got to agree with you. I recently started getting serious about changing positions and I've become completely convinced that much of the so-called 'talent shortage' is caused by the job search process, from job listings through to interviews. Every step is unintentionally outrageous in a new way.

The first step, finding open positions that are appropriate to your skills and abilities, is overwhelming and impossible. The only way you have any hope of short circuiting it is to have connections with the right people who can open the maze from the inside. Or to become famous in a community.

Otherwise, it's a slog of browsing through hundreds of job listings, finding the one in 20 that isn't for .NET or MS-SQL or C# or Oracle, and the 1 in 50 that's not from a recruiter who's listed the same job 5 times, realizing that you aren't qualified because you haven't used the all 4 languages they care about, or maybe because you've only dabbled with some key piece of tech they're convinced you need 3 years experience with, or they won't look at candidates who need to relocate, or you absolutely need to know Red Hat when you've pretty much used Ubuntu derivatives or Arch or whatever. Then you waste time adjusting your resume, and never hear back.

Those you do hear back from will often mis-represent themselves and their businesses in an attempt to get hires. In fact, I was a victim of this at my current job.

Oh well. All I need to do is start spending all my evenings and weekends on side projects while building an impressive blog to talk about coding and technology. Once it's popular with the Hacker New digerati all I'll need to do is wait... After all, we all know 'talent' is code for 'marketing.'

resu_nimda• 13 years ago

If my recent experiences are any indication, the secret is to go to hackathons and developer meetups. In the past I've gone through that whole painful and impersonal process you've described.

It has actually shocked me how effective this approach has been, and I wasn't even trying (I was just there to hack and learn). You get to have real conversations with people who understand you, and you can easily walk away a couple of those inside connections.

Also, the companies that send people to those events (more accurately, those that hire people who will attend of their own volition), seem to be more likely to have sane hiring processes. The two that I have been in talks with have actually made me feel "recruited," and follow most of the points in the article, which is a nice change (and I certainly don't have rockstar status or really any public image).

pyre• 13 years ago

I've gone to meetups, gotten business cards, but my emails just ended up going into a black hole.

michaelochurch2• 13 years ago

I recently started getting serious about changing positions and I've become completely convinced that much of the so-called 'talent shortage' is caused by the job search process, from job listings through to interviews. Every step is unintentionally outrageous in a new way.

Yep. Bilateral mismatch. Here's the dirty truth: people don't actually care about talent or even how good you are at your job. They just want to get a mission fulfilled. That'd be fine, with competent execution-- hire the right kind of person, get it done and done well, make your money and move on to something better. The problem is that it seems that 90 percent of them have no clue what they want or how to evaluate the relevant talents, and there's a hardcore Design Paradox effect going on as well.

By the way, I'm pretty well-known at this point. I'm probably in the 96-97th percentile for programming skill and 99th for loudness. It makes job searching easier to be "a quantity" and I'm finally getting to a point where it opens up some great options... but I've still dealt with a lot of frustration. It's nothing to be ashamed of.

Those you do hear back from will often mis-represent themselves and their businesses in an attempt to get hires. In fact, I was a victim of this at my current job.

This is a problem in stodgy bureaucracies and VC-istan. In the former, it's because in Douchebagland, one's value is based on how many reports he has-- not what those reports actually do-- so bringing in marginal people through dishonest means improves the boss's resume. In the latter, it has more to do with the way companies are valued by investors and acquirers-- some $X million per employee.

potatolicious4• 13 years ago

> "The first step, finding open positions that are appropriate to your skills and abilities, is overwhelming and impossible. The only way you have any hope of short circuiting it is to have connections with the right people who can open the maze from the inside. Or to become famous in a community."

You don't need to be famous, not even close. You did get it right though - you do have to know people.

Finding your next job is something you should be doing before you're actually thinking about leaving your current one. Go to meetups, look up interesting companies in your area and make yourself known to them - you'd be surprised how many people are willing to chat even with the knowledge that there's a 0% chance of you jumping ship in the foreseeable future.

It's not only a great way to get your name out there and make a few contacts, but it's also a great way to find out what's happening in your local tech community.

It is also necessary. In my experience the best employers and the best positions fulfill primarily via word of mouth. By the time a job hits a major job site it means the employer has already failed their first-choice option (i.e., a known referral by a trusted entity).

meerita• 13 years ago

I did an interview 2 week ago. I'm not a programmer, yet, they gladly asked if I code wich I answered yes. What made me go nuts after show them all my work is, fill a questionary? one question was: "Tell us what you understand by "pixel perfect"

CurtMonash• 13 years ago

I love that he just assumes people know the Heinlein quote. ("Specialization is for insects.")

ibudiallo• 13 years ago

I did not know what it was, and i am glad you brought it up :)

listaware• 13 years ago

The problem is that recruiters carpet email (bomb) programmers, for many of them it's a numbers game. They aren't interested in taking the time to get to know you and frankly I don't expect that they do.

The best way, in my opinion, to get a new job is to be proactive and search for it yourself. Contact companies directly, use your network and see how you get on.

Recruiters sadly aren't interested making friends.

eksith• 13 years ago

Thank you! That no recruiting recruiter email is such a buzzkill.

Even if the company itself looks interesting, just the fact that they sent some brocruiter to flood prospects with emails just makes me question the wisdom of the folks behind the company. I can appreciate a lax attitude at work up to a point, but beyond that, there's no real productivity. It's like the days before the dot com bubble when VCs were dumping cash on a potential product sold on hype.

Even if I were to get hired, what's the point if the company folds in a year?

edw5192• 13 years ago

How to hire me:

   1. Tell me about the 3 biggest things you must accomplish.
   2. Tell me why you must accomplish them.
   3. Tell me when you must accomplish them by.
   4. Tell me how you intend to accomplish them.
   5. Tell me what you're already doing to accomplish them.
   6. Tell me the role you envision me playing in accomplishing them.
   7. Tell me what you expect from me.
   8. Put me with some of the key people already working on them.
   9. Tell me what you'll do when things change or go wrong.
  10. Take me to a Chinese buffet.

padolsey• 13 years ago

Hmm, 6 & 7 are the same. And I think you meant Thai, not Chinese.

mgkimsal4• 13 years ago

They're almost the same, and it probably wasn't intentional, but they're worded differently enough that you might get some surprising answers from someone if you ask them a few questions apart.

pasbesoin• 13 years ago

A good Chinese buffet. If you can't tell, or don't want to pay for, the difference, well...

P.S. (The secret is that good and cost are not in direct correspondence across the population of Chinese buffets.)

davidroberts• 13 years ago

Sometimes you don't find out it's not good until several hours later when you are having a close encounter with a plumbing fixture.

Mahn2• 13 years ago

> 10. Take me to a Chinese buffet.

No need for the rest, this will do.

Actually, in all seriousness there is at least one start up here in Germany which hiring process consist in going for a beer with the founders and members of the team you'll work with, and only follow up if you liked each other. It's probably not very scalable for the founders as the company grows, but still an interesting approach.

BHSPitMonkey2• 13 years ago

I wonder if being the fourth interviewee in a given day would help or harm your chances of a follow-up? :)

lessnonymous8• 13 years ago

(The following is made up and CERTAINLY isn't for the job I currently have open for a senior PHP dev in Melbourne.AU)

Here's why you don't see question one answered honestly:

A. Our sales guys sold our product based on feature "Foo" a year ago. We haven't started coding but they need a demo next week. You have to grok our codebase and write it on your first day.

B. The 'Bar' feature was written by a guy who should have failed finger painting, but we don't have time to rewrite it. You have to fix the many patches and modifications it's had since.

C. The 'Zap' feature was written by our cowboy programmer. You have to do all his bug fixes and modifications because he thinks he's too important for anything but new code.

hack_edu• 13 years ago

Tip:

When hiring engineers (or speaking to any anyone ever again) NEVER use the word 'grok.'

irahul• 13 years ago

Your 'Zap' is bothering me. What happened to Baz?

niggler8• 13 years ago

" 10. Take me to a Chinese buffet."

I've had so many bad experiences with Chinese buffets that I steer clear of any place that would suggest that.

seanmcdirmid• 13 years ago

I absolutely hate Chinese buffets, they all feel like feeding troughs to me.

Of course, we take all our candidates out for Chinese food these days, but its kind of expected since we are in Beijing. Sometimes its difficult dealing with some foreigner's dietary restrictions (orthodox, vegetarian are hard; halal is quite easy).

philsnow2• 13 years ago

I mentally substituted "dim sum" for "a chinese buffet" because the latter just doesn't make any damn sense to me.

mindcrime3• 13 years ago

That's some good stuff, but I'd add a couple:

1a. Show me the office I'll be working in. Any "open plan" or "2+ people per office" setup decreases your odds of hiring me by about 93%. Not to say I'll never take a job like that, but it really, really hurts your odds.

1b. Show me the rest of the building... are there common areas where people can hang out and collaborate away from their offices, preferably with natural sunlight to the area? Are there plenty of conference rooms, team rooms, or other areas for small group meetings? Do people have to fight to get a room for a meeting? Are rooms commonly "double booked" in whatever system tracks that? IS there a system for tracking room reservations? Is it Lotus Notes? If "yes" to the last question, I walk.

2. Show me the tools I'll have available to work with: Hardware, software, etc. If you're handing out ancient laptops with 1GB of RAM while expecting developers to use Springsource Tools Suite, I'm probably walking out on the spot. If you're using CVS for version control, I'm probably walking out. If you don't have a continuous integration server, I'm probably walking out.

3. Tell me about the training budget, if any. If there is no training budget, your odds just went way down.

4. Tell me about your software process. Here's where I am going to interview you. If you say "we are an Agile shop" you better be able to explain exactly what that means. Which Agile methodology do you use? Scrum? XP? Crystal? RUP? Your own made up psuedo-Agile process? Do you just use the "words" from Agile or Scrum without actually understanding them? If you use the terms "sprint" or "iteration", and "epic" and "story points" but clearly don't understand what they mean and how they should be used, I'm gone. Also, I'll want to know if the business side of the company understands and is onboard with the iterative approach with empirical feedback loops. Do execs prioritize stories for the backlog and then leave it be? Or are they randomly coming in, mid-iteration, and changing things around willy-nilly?

5. I'll want to know how many people I "report" to. If I have a "manager" telling me what to do, AND a "project manager" giving me conflicting instructions, AND random execs with an unclear relationship to the project coming along and tell me stuff, we aren't going to be together long, sorry.

6. Tell me more about the culture of the company... are people expected to be on-time for meetings? Do meetings always have agendas, and time limits? Does the company favor promoting from within? Do the execs have an "open door" policy? Are their performance reviews? How are they done? Do you make employees take any bogus "psychological profile tests"? Drug tests? Do managers go out to lunch with the "rank and file" and share a beer or two, or do managers go out in groups and pointedly avoid the riff-raff, and you'll get yelled at for having one drink with your lunch? Does the CEO interact with the "rank and file"? How? In short, convince me that this is a well run company, who respect their employees, value engagement and actually empower their people.

7. Is there any attempt to implement Kaizen or become a learning organization? Are there post-mortems for negative incidents? Do they use "Five Whys"? Are employees fired for one f%!# up, or is it more of a "support, coach and encourage" environment?

8. Are there bonuses? Profit sharing? Employee Stock Purchase programs? Stock options? What exists to align the goals of the employees with the goals of the firm as a whole, other than "I want to stay employed"?

9. Take me to eat Thai. A quality serving of Num Tok and a nice Mussuman Curry improve your odds considerably.

edw5192• 13 years ago

I purposely didn't include any of yours. Why?

1. Mine are issues and yours are details. If my 10 are satisfactory, I can live with your 9, even though some may not be satisfactory. But if you 9 are good and my 10 aren't, I'd last about a year before moving on because of lack of meaning.

2. Mine are about them, yours are about you.

3. Mine show interest in the big picture; yours could easily paint you as a demanding nit-picker (whether you are or not).

Yours are important and a good list. I just don't think I ever would (or ever have) discussed them with a prospective employer.

And thanks for the tip on the Thai. I'm googling "Midtown Miami" and "Mussuman Curry" as soon as I finish typing this.

AaronM• 13 years ago

Tell me where a place like this exists. I think you may be my doppleganger, especially in regards to #4, #7

cookiecaper• 13 years ago

aka "I will only work at venture-backed startups that will die in two years or Google".

steven777400• 13 years ago

1a. No offices, only cubes. 1b. Limited conference rooms, people ignore the reservation just enough to make it irritating. 2. No continuous integration. No Git. 3. We say there is, but there isn't. 4. As one of our supervisors said recently, "If I'm not telling you what to do, or changing your workload on a daily basis, then I feel like I'm not doing anything." 5. All of the above! 6. Most people show up for work, most of the time. Performance reviews are irrelevant. You may be evaluated on things like "dresses appropriately" when there is no dress code. 7. No, no, no. Employees are not fired. I'll let you think about where that eventually leads. 8. No. No. No. No. None. 9. Not in the budget, sorry.

That's where I work. And I wouldn't give it up for these fast paced do-or-die startups. :)

avenger123• 13 years ago

I love this list!

I just don't think a company is going to answer many of these questions. They might think you are a spy for the competition :).

inovator2• 13 years ago

1a. Just out of curiosity, what's wrong with "open plan"?

IheartApplesDix• 13 years ago

These are basically all the things they need to keep secret to keep leverage over you.

dmiladinov• 13 years ago

Sometimes I think it might be even more benign than this. Some hiring managers are already so ingrained into their work culture that it's already become transparent to them.

"Don't ask the fish about the water," and all that.

alok-g• 13 years ago

Much of this sounds like a joke [1] to me really as the most of the companies I have interviewed with won't tell all this even after signing an NDA. Even asking such questions elicits a strange look (don't you know we cannot disclose what we are working on).

A second question then is why did they ask for an NDA then, and the answer is "company policy". I have refused to sign such NDAs, and they have refused to interview me then.

Interestingly here is something that has worked: I have signed such NDAs with my annotation saying something like "It is mutually understood that this NDA is null and meaningless" right above my signatures, and they do not have any issue with that. Well, as far as I "signed" the NDA per the company policy!

This has been the case with several big name companies I have interviewed with.

[1] Not making fun of you here, rather of the companies and bureaucracy.

FourthProtocol2• 13 years ago

Useful and insightful list. I'd add "what's the impact to [your org] if you do not fill this role (whether with me or someone else)?"

fduran• 13 years ago

To companies hiring: explain who you are and what you do, what you are looking for and what the hiring process is, extra points for a FAQ. Here's an excellent example: http://www.matasano.com/careers/

csmatt2• 13 years ago

Excellent! Very well written and expressed.

There was an interviewee here today and I heard my boss tell someone to quiz him on big-o notation. I rolled my eyes.

Yesterday I had an interview that started off with "Tell me a bit about yourself." No direction as to what the interviewer wanted and, the worst part, as soon as I said I was done, he went right into asking me what the difference between "overloading" and "overriding" is.

How many years of experience do I need to have for them to stop asking me things like this? Most of my work lately is in JavaScript and Python. I had trouble answering "What's the difference between an abstract class and an interface?" That doesn't necessarily come up in those languages in a distinct way, so I'm out of practice in my vocabulary.

I have neat personal projects with source code on github. Do you really need to screen me with a phone interview?

mgkimsal4• 13 years ago

"How many years of experience do I need to have for them to stop asking me things like this?"

It will never stop.

"Do you really need to screen me with a phone interview?"

Meh... I'm kinda split on that part of the process. I understand the frustration, and too often it's wasted time that doesn't gain anything you couldn't get from the CV itself. If done right, it can tell you if the other party is good at verbal communication, which is an important skill in its own right.

chollida12• 13 years ago

> Yesterday I had an interview that started off with "Tell me a bit about yourself."

To be fair, alot of well meaning interviewers start off that way. It's supposed to be a chance for you to mention all the good things that we may not ask about.

In fact that question is so common its a good weeder question; if a person can't blow your socks off with 5 minutes then you can probably predict how the rest of the interview will go.

I mean the interviewer basically says to you a golden opportunity to say why they should hire you. If you don't know what to say that pretty much says it all:)

pekk5• 13 years ago

Except this kind of demand for a prepared 5-minute self-pitch really tests how much you are confident and good at bullshitting, and not really anything about your skill with anything.

A person is not worthless and incapable just because they aren't huge salesmen.

No wonder women have trouble getting into this industry and getting ahead, with this kind of macho superior attitude from interviewers

rhizome7• 13 years ago

if a person can't blow your socks off with 5 minutes then you can probably predict how the rest of the interview will go.

Is this really true? I think if you turn it around you wouldn't agree with it so readily: if a person can blow your socks off in 5min, then you can predict how the rest of the interview will go." Well then why have the rest of the interview, or if the rest of the interview is still necessary, why go through the 5min pitch rigamarole? Why not just shave those 5min off the whole interview? Why not send the candidate on their way after they don't do their pitch-intro well? These are all rhetorical questions, but you see how I'm following the logic in your statement. I'm not judging either way, but hey, could it work any worse than the processes elsewhere described?

Heck, I wonder how a company would do if they gave the candidate 5min for whatever with the significant coworkers of the position, then take a vote from the interviewers and just hire based on the victors. Interviewers can do culture or technical interactions, doesn't matter, if they feel good about the person then they vote to hire. I guess it's like Speed Dating this way, but still.

bcoates• 13 years ago

What am I supposed to do instead of the cookie-cutter technical interview? Right now I do "Ask any question that starts with the phrase “tell me about a time when”." for most of the interview.

I'm trying to give them an opportunity to describe technical things they've done so I can drill into details and suss out if they're exaggerating their skill-set and/or incapable of communication.

For perspective, I'm a schlub at my company they grab out of the hallway to give technical interviews, not the founder or a full-time HR guy.

csmatt2• 13 years ago

Just came up with this, but you could ask the interviewee to teach you something programming related that he/she learned recently. That should tell you how well they communicate, can deeply show you their level of experience (and interest), and it doesn't require that they recently revisited their notes from academia.

Another option would be to keep notes on programming challenges you hit (and the attempted and final solutions) while doing the job this person is interviewing for and ask the interviewee to walk you through how he/she would go about solving the problem.

rhizome7• 13 years ago

The first one might be funner for people-persons, but I'd say the second approach would give you a much higher degree of confidence in the candidate's skills.

larsberg• 13 years ago

Completely agree with you - I frequently used to ask experienced candidates questions of the form, "tell me about one very difficult bug or performance issue encountered during your two years working on X."

Unfortunately, the number of flat-out liars on resumes is extremely large. Heck, I've even seen resumes from people I worked alongside at Microsoft who now claim to have done things that I did while there. <shrug>

Sussing that out is part of the interviewer's job, at least if you care about 1) whether you're hiring a liar 2) the skills that should have been gained if they actually spent two years working on X.

logn• 13 years ago

How about: hi, candidate, here's my laptop. I've created a guest account for you and installed an IDE with X programming language. Take some time to implement this original program I want done that can't be copied from google. I'll be back in 45 minutes and we can discuss your solution until our hour is up. Nice to meet you.

stonemetal• 13 years ago

I think my ideal way to land a job would be

1) contribute to some open source project.

2) get a beer with the company's dev team at a hackathon.

3) job offer.

supervillain• 13 years ago

Number 1 rule for hiring geeks.

- Do not ask for a .doc Microsoft Word document resume

Because we might be scrambling and downloading LibreOffice and converting our .latex resume to .doc, if you want to get our attention, ask for TXT, PDF or LaTeX format.

ghjm2• 13 years ago

Unless you're trying to hire geeks who can fit in to a standard office environment without weird platform demands. In which case, insist on .docx.

disgruntledphd2• 13 years ago

Well, yes and no. I write everything either in LaTeX or markdown these days, but its ridiculously simple to output either of these formats to docx, so normally that's what I do. I'll always send them the PDF version of my resume first though, as good typography can make you look better.

If a job requires me to write in Word throughout the day, that's a job I don't want (in fact, writing grant proposals in Word was one of the most frustrating things about working in adeademia).

bluedino• 13 years ago

To be fair, a lot of recruiting companies or hiring companies only do that because their HR system will only import a .DOC file.

The absolute worst place I ever applied to required to you upload a version of your resume in Word format. After you hit submit, the next page wanted a plain text copy. Then, I bullshit you not, the next page was a web form in which they requested you fill out educational background, work history, references. Something you just uploaded twice!

up_and_up• 13 years ago

“Node.js V8 Korean-language backend optimization engineer”

Thats hilarious. I recently was job hunting and I ignored prob 20% of position due to that fact alone.

segmondy2• 13 years ago

He who is getting hired is at the mercy of the person doing the hiring. That's just how it plays out. If I'm getting hired, I have no say on how a company should conduct their interview process. Their interview process is a window into how they operate, and if it's terrible, I won't want to work for them. i would hate to have a great interview process only to find out that the company is terrible. There is a need for terrible interview processes, so long as it matches the company. The last time I had a bunch of interviews, there was a company I interviewed at, they were so terrible I knew I didn't want to work for them. At the new company, I ran into people who interviewed at same company and refused to work for them, and into two more who use to work for that company and were glad to leave.

With that said, the biggest motivation for me is compensation. I don't care what problems they are trying to solve, I don't have to love it. Want me to write in COBOL? Fine, I'll learn it. Want me to work 10hrs a day? Fine, compensate me accordingly. Everything has a price.

pekk5• 13 years ago

I find that people don't respond well to this 'mercenary' attitude. They usually want you to act like you love it, even if it's stupid. They want you to commit long-term, even if you are a temporary contractor. Etc.

Every company is like an oversensitive lover who has to be the best ever.

segmondy2• 13 years ago

Of course. I'll feign the love for it.

signed03• 13 years ago

Can someone explain what a "resume wall" is.

lessnonymous8• 13 years ago

A job board has a 'resume wall'. It's like there's a very narrow slot in it you shove your resume through. Then you just hope. And hope. And hope. And then give up because that wall ain't talking.

Anyone ever applying to me that sends me a legitimate application WILL get a response. And if you made it to a phone interview you WILL get a phone response even if we're not continuing.

It's all about respect. (Plus, I might want to hire you next year for a different role. I'd like it if you thought highly of me. And it's not difficult to be polite)

(If you or someone you know is looking for a Senior PHP role in Melbourne.AU, hit me up and I'll point you at the ad on Seek's resume wall :-P)

signed03• 13 years ago

So it's like a firewall but for resumes?

softbuilder2• 13 years ago

Sorry I left you wondering! A resume wall is a third-party service that sits between applicants and an employer. In order to apply for a job with some companies you have to submit your resume through their service. http://www.jobscore.com/ is an example.

signed03• 13 years ago

Ah, I was imagining a huge page filled with resumes in the same vein as a wall of text.

VikingCoder15• 13 years ago

When I'm involved in interviewing someone, one of the interviews will be cookie-cutter. I've seen with my own eyes applicants who had stellar resumes, had great conversations with everyone they talked to... and could not pass a Cookie-Cutter Technical Interview.

You may think that it's insulting to have to pass a Cookie-Cutter Technical Interview, but we are not (generally) a Professional group - we don't have a Bar that you have to pass to be considered a professional programmer.

When I give something that looked like a Cookie-Cutter Technical Interview, what I'm really assessing is, "How much of my time will I have to spend explaining to this person how to solve programming challenges they'll actually see in the code they'll be working on, and how hard will it be to have that conversation with them."

The absolute best candidates were the ones who understood why I gave them the Cookie-Cutter Technical Interview, and related to me their own frustrations with similar oddities in programming... I concluded that they knew how to dig in to programming problems, and solve them on their own.

The next best candidates, who I loved to recommend to hire, were the ones who didn't know the answer to my questions (which were purposefully challenging), but who had a great dialog with me. I would encourage them to ask questions, to think out loud, etc. I know this is very, very hard to do in an interview, and I tried as hard as I could to be encouraging, and patient, and give hints when they were needed. And if they responded by asking good questions, stating their assumptions, verbalizing what it was that was difficult for them... I concluded that they would be good at identifying when they were over their head, which I hoped meant they would know when to ask for help, and I could also assess whether they'd be able to explain their problem succinctly.

Let me circle back with an anecdote: we had a candidate who looked great on paper, spoke well in all of his other interviews, had lead impressive teams at competitors, and who couldn't solve FizzBuzz. Hiring someone like this is incredibly expensive. Spending one hour of time with a candidate to make sure they can... program... is well worth the time.

And I'm sorry, but it's a Buyer's Market. People trying to Sell themselves as good candidates are going to have to put up with one hour of demeaning technical questions. Hopefully they'll turn that hour into a fun discussion about how programming is challenging, and relating their own stories of the oddities of the languages and libraries they use, and why they have certain preferences, etc. - a whole meta level above why ++i is different from i++, and how it's burned them in the past when someone didn't know the difference, etc.

You say "Let Me Code, Dammit," but most of your job will be READING code that other people write. I know what the code looks like here, and you don't. If I show you the warts, I can tell how you'll react to them. Do you call ugly code "ugly"?

http://www.osnews.com/story/19266/WTFs_m

Do you know why this line of C++ code compiles with Visual Studio 6, but produces the wrong result?

Do you cringe when you see a %s with an int in the param list? Do you tell me that printf functions are inherently unsafe? How do you recommend making them safer?

If you code C++, do you know Boost?

Can you spot a new without a delete? Will you tell me to use shared_ptr or auto-ptr, or just use the stack?

Typing code is generally having good habits, using safe but powerful libraries and language constructs the right way. But maintaining code is a bit of an art. If you don't agree about what's "ugly" and why, you're probably going to push the body of code in a direction that I call unmaintainable.

And there are different strategies in how to make code more maintainable over time, but within one company, we should probably all be pushing roughly in the same direction.

"Let Me Code, Damnit" doesn't help me assess that as well as something that looks - at first blush - like a Cooke-Cutter Technical Interview does.

pekk5• 13 years ago

You're right, it's a buyer's market. And this kind of thing shows it. But for some reason we keep hearing that there is a massive talent shortage. Hmm...

VikingCoder15• 13 years ago

Both things can be true at the same time.

Someone fresh out of school should expect to jump through hoops.

A company that's looking for senior developers who've Been There, Done That, should expect to have to empower, reward, and listen to them.

But senior developers really need to understand that there are Chameleons among them, who have floated from job to job, look like they have all the right skills, but can't perform.

Companies need to be able to distinguish those Chameleons from the real deal, and I have found that Cookie-Cutter Technical Interviews are a necessary step. I think I've kept out more Chameleons than I've lost good candidates. Or rather, I've determined that it's worth administering the Cookie-Cutter Technical Interview, because I've concluded that the cost of hiring a Chameleon is higher than the cost of making one of the many honestly good candidates walk away in distaste.

I also have to emphasize how empowered, rewarded, and listened-to the candidate will be, and that they'll be surrounded by other senior programmers with great skills that they'll have fun interacting with...

SomeCallMeTim3• 13 years ago

Ahhh....I think the two concepts (buyers market vs. talent shortage) are related.

It's a "Buyer's Market" right now for average talent. And honestly, most start-ups only need average (competent) talent.

But if you need above-average talent, there's a perpetual shortage. Speaking from experience (and I'm NOT a name you've likely heard of -- I'm just a generalist who is good at low-level through high-level code and API design and have a resume that reflects that), once I get through a technical interview with a company they usually are inclined to make a position for me, whether or not they previously had one available.

And by "usually" I mean that I've gotten a job offer from more than half the companies I've ever interviewed with. Feels like a Seller's Market to me, and has for 20 years (with the exception of the 6 months following 9/11 when most of the US was in shock).

onemorepassword3• 13 years ago

> but it's a Buyer's Market

On what planet?

VikingCoder15• 13 years ago

You think it's hard to find programmers, at any given level of skill?

Maybe I've been fortunate enough to work for companies that had enough gravitational pull that we attract good candidates without trying very hard.

vinceguidry8• 13 years ago

> You think it's hard to find programmers, at any given level of skill?

If it were easy to find programmers, you wouldn't have all these shops using spam-tactic recruiters to drive volume. They wouldn't need to.

It's most definitely a seller's market, if programmers can take their pick of corporate gig | freelancing | startup. My last job hunt took one hour. Their search went on for two months. If they fired me I could line up a dozen interviews next week, they'd still have to wade through a sea of unqualified/foreign/unmotivated alternatives.

It's not that I'm that good, I'm an entry-level Ruby guy working in a .NET shop. I interview well, but they interviewed a dozen guys before me. My job offer came the same day as the interview, after a token 4 hour wait. It's not that they were being overly selective, the pool they were fishing in was just that bad.

I don't know where you're getting the idea that it's a buyer's market for programming talent.

DavidWoof2• 13 years ago

> Do you know why this line of C++ code compiles with Visual Studio 6, but produces the wrong result?

Are you actually serious? You ask about a quirk in a 15-year-old single-platform compiler?

I always wonder what some interviewers think they're gaining from questions about minute historical trivia like this. It doesn't provide any real insight into ability at all.

Contero• 13 years ago

I thought that was meant to be a joke. At least I hope it was. It would get a good laugh from me in an interview.

VikingCoder15• 13 years ago

At the time I was working with code that had been written with Visual Studio 6. The code snippet was written at that time, and I thought it was interesting because of how it behaved, and it let me delve into how the person reasoned about the language, the compiler, and the runtime.

I repeat my earlier declaration that I loved candidates who didn't know the answer, but could have a good conversation about the question.

notaddicted• 13 years ago

The question equates to "spot the undefined behaviour in this statement" which I think is a legitimate question for assessing knowledge of a language like C++, and to use as a starting point to find out if they understand the difference between programming to the language spec. versus programming to the compiler.

dinkumthinkum6• 13 years ago

I think it could be an OK question. I'd have to see it; if it is something sort of well known or a fairly arcane thing. It being 15 years old is not really that problematic to me. Python is much older than that. :)

softbuilder2• 13 years ago

I think "cookie-cutter technical interview" has been misunderstood. My fault, I didn't spend much time on it in the post.

A cookie-cutter interview will ask things that I've been asked by every other shop in town. For instance, I literally recite Fibonacci now. It's a completely useless test because it's over-used. This sort of thing makes a company look cold and - far worse - unimaginative. It's not insulting, it's just a red flag.

The other part of this is having people stand at a whiteboard or work on paper instead of sitting down with them at a computer. Every single thing you listed can be determined by sitting with the candidate at a computer, working with actual code.

None of this bars you from asking about historical quirks of compilers or anything else. If anything, it offers you the chance to have a more relaxed conversation about these things so you can get past the bullshit and see the person that you'll actually be working with.

VikingCoder15• 13 years ago

Thanks for the response.

I actually printed out about 20 sample bits of code, and discussed that. I worked with people on the Image Processing / Computational Geometry side who would set up a programming challenge with a compiler, and I respect that, too.

UncleOxidant3• 13 years ago

> If you code C++, do you know Boost?

Do I know it exists? Sure, of course. Have I used all of the 50+ libraries in Boost? nope. Maybe about 10% of them. What exactly do you mean by "know Boost"?

> "Let Me Code, Damnit" doesn't help me assess that as well as something that looks - at first blush - like a Cooke-Cutter Technical Interview does.

You can also have a look at my GitHub where you can read actual code I have written and see how I've handled pull requests, bug reports, etc.

VikingCoder15• 13 years ago

> Sure, of course.

I get applicants who claim they're C++ experts, and they've never cracked Boost open to look for anything good, and they've never heard of TR1 or anything that followed. I'd like to have that discussion with a candidate. That's all I meant by "know Boost."

> You can also have a look at my GitHub

When I can do that, it's awesome.

Many candidates have been work-for-hire their entire careers, in states with Non-Competes that are either enforceable or people are afraid their previous / current employer might try to enforce it. I don't hold a lack of a GitHub account against someone.

sopooneo3• 13 years ago

Though I have only been on the applicant side of the interview table, everything you say rings true to me. I understand completely why employers need to do low level competence tests.

However, I am curious what you mean when you say that it is a buyers market. From everything I've read, there is a shortage of development talent, so those "selling" their service as programmers have the edge. Doesn't that make it a seller's market?

dinkumthinkum6• 13 years ago

> And I'm sorry, but it's a Buyer's Market.

In what universe is this true. I don't want to imply anything but I feel like maybe you're not sure what "buyer's market" means. That would imply that employer's have large pool to pick from an those looking for a job are essentially lucky to find one. I don't think you meant that ... I'd hope if you are really in charge of hiring people you wouldn't think that because, I feel perhaps you wouldn't be the right person to be in charge of hiring due to not recognizing what is happening in the world at this moment (3/23/2013). :(

On a side note, I hear the thing about FizzBuzz a lot. I find it, personally, hard to believe that it is common for someone to pass an interview that probed to any depth, pass with flying colors, and not be able to code FizzBuzz. I would think the person directing the conversation was not doing a good job.

And the ++i vs i++ .. that's pretty basic stuff, I get that that's potentially part of your point, but that is just silly stuff.

VikingCoder15• 13 years ago

The employers I've worked at, since about 2002, have had a large pool to pick from, and those looking for a job have gotten less and less of a cut of profits and their benefits have been cut back, fairly consistently (relative to inflation, etc.)

People are still afraid of losing their job. Some people have been under-employed for a long time, now, and are settling for jobs they previously left in distaste. A lot of people feel stuck.

Let me try to rephrase it - there are entrepreneurs, there are people who will accept a lot of risk... and then there are people who feel they cannot move, have a low tolerance for the imagined future pain of being unemployed, worry about the housing market, worry about losing insurance... and when they are unemployed, they stand in line to try to distinguish themselves to the large companies that are nearby, so they can get a stable job.

Heck, I know people with advanced degrees in their fields who have accepted Internships just to have a paycheck.

There's no lack of smart people who will work hard at a stable job, and consider themselves lucky to get an offer for the positions at the companies I've worked at.

If you accept candidates who are not citizens (H-1B), I find it hard to believe that ANY of you have a hard time finding candidates. If you're open to telecommuting, especially.

FourthProtocol2• 13 years ago

I never bother with cookie-cutter interviews. With the exception of the first, every time I've had one I ended up being made an offer, and turning the job down. First, I found obscure technical questions from interviewers a bit sadistic. Almost as though the interviewer is trying to tell you how good she is. When I accepted an offer after such an interview I only lasted three months, because the interviewer felt threatened by me.

If, conversely, a candidate asked me the questions edw519 listed above, you'd pretty much be guaranteed a job. I don't care how well or badly you program. I don't care whether you know Boost or not. I want to know whether you'll fit in here. Ever read Peopleware [1]? There's a great example in there on why you should value the programmer that seems to deliver nothing of value, and yet makes the team gel.

If you don't know why this line of C++ code compiles with Visual Studio 6, but produces the wrong result, hey, that's ok. Are you giving me the impression that you like programming? That you will try and find an answer yourself before coming to ask for my help? If I ask you a question that you can't answer, do you bullshit, or do you say "Hey, I don't know, but I'll find out and email you the answer tomorrow."

The character is far more important to me than your ability as a programmer. The former is a fit, or it isn't. The latter I can work with. Because it's a long game.

[1] http://www.amazon.co.uk/dp/0321934113

BHSPitMonkey2• 13 years ago

"If, conversely, a candidate asked me the questions edw519 listed above, you'd pretty much be guaranteed a job."

I'm confused. Is it normal for an interviewee to ask the interviewer a tricky technical question at some point of a job interview now? Am I reading this correctly?

NateDad• 13 years ago

Man I hate getting recruiter emails... I get this vague description of the job for a "hot startup" or "well funded startup" or "established startup"... and I have no idea what they actually make, what the company is about, etc.

   STARTUPS: STOP USING RECRUITERS!

in fact... everyone stop using recruiters. Look on monster.com and dice.com and stack overflow careers and whatever else. I guarantee you, recruiters aren't going to magically find people that don't have their resumes listed there. Anyone who wants a job has their resume listed up there. Find some people that look good, and email them. It's not a full time job, and the quality of candidates you get will more than make up for the lost time in actually reading through resumes.

I pay 100x the attention to an email from a real person at a real company who can actually talk about what they do, how they do it, and what I would be expected to do, than I do an email from a recruiter who just wants to place me at whatever company they can get me into. Recruiters don't care about you and they don't care about me. They want a quickie - wham bam, thank you ma'am.

Maybe it's just Boston, I don't know, but you look on all the big sites, and it's 95% recruiters.

Do you think job applicants are dumb? That they won't do some basic searches to find the job your HR guy posted on dice.com?

Which of these do you think I'm more likely to click on?

  Job #213 from TechRecruiterz.com
  Full stack engineer for SomeAwesomeStartup.com

One is a position at an actual company, one is an advertisement for a Recruiter who doesn't give any identifying information about the job, and doesn't actually care if I'm a match for a job so long as I take A job... any job, so he can get paid.

nollidge5• 13 years ago

Also stop with: interviewing based on rote memorization.

Yesterday I had a really crappy (third-party!) phone screen assessing my ASP.NET and some general web dev knowledge. Questions included asking me what the stages are in the ASP.NET page life cycle, how to create Web Control in ASP.NET, what elements are new in HTML5, and how to pop up a new window in Javascript.

None of which I know off the top of my head (except I know <canvas> is new), each of which I can learn in about 100 milliseconds, and none of which assess skill and intellect.

Did you want a skilled programmer, or someone who memorized their Foobar Enterprise Framework cheat sheet? Because you're only interviewing for one of those.

taytus• 13 years ago

I think that's the problem, they don't know what they want.

rhizome7• 13 years ago

I recently got the question, "explains what happens when you type a URL into a browser."

nollidge5• 13 years ago

Ugh. See, and if my mom asked that, I know she's looking for a barebones high-level explanation that she can grok, so I can be a bit fuzzy. But when an interviewer asks me that? I can't tell if they're just screening out the dummies, or if they actually want me to talk about packets and handshakes and DNS protocol.

willismichael• 13 years ago

Typing it in isn't really that interesting... but when you submit, now that's when the magic happens.

Falling36• 13 years ago

I also got that last week. It was during an interview for a position that ostensibly didn't require any sort of in-depth knowledge of that process.

dj_axl• 13 years ago

> Did you want a skilled programmer, or someone who memorized their Foobar Enterprise Framework cheat sheet? Because you're only interviewing for one of those.

People who ask common/simple insert language/framework here interview questions are sometimes looking to see if you at least minimum care enough to memorize the answers. Alternatively a sideways answer might work, like "I find that's no longer necessary since..." or "I'll be attending a 3-day dev conference that includes that topic..."

That said, it makes it look like they don't care enough about interviewees, when they put so little effort into the questions asked. To hire a skilled programmer, you need to present yourself as a skilled interviewer.

michaelochurch2• 13 years ago

This is a great post.

One issue here is that a (possibly deeply-layered) "neural network" model applies to many industrial processes, which means that there are a lot of interacting components, but in many of those the input/output relationship is almost binary-- a logistic curve close to a step function. Most companies have absolutely no need for exceptional people. They're looking for a process that can hire good-enough people at controllable volume. They have a mission to be fulfilled and want it done well enough. There's nothing wrong with that; it's just that most of them have no idea how to execute. They might over-hire and reject mediocre-but-good-enough people. They might come up with insane purple squirrel queries or HR-ish hiring policies ("we only hire NoSQL developers; it says here that you use Scala"). They might hire mediocrities (when they actually need strong people) and compensate by hiring a lot of them, which we know doesn't work.

There's also a deep, bilateral trust sparsity in the economy. Most employers aren't doing interesting work and have shit cultures. Most programmers haven't been well-trained or motivated to grow and are incompetent. It goes both ways. I'm just as elitist and network-driven in terms of the companies I'm willing to consider credibile as they are in their willingness to fairly evaluate candidates.

I can't come up with a good way to overcome this in the general case, but the OP gives a strong guide for recruiters to overcome trust sparsity and show capable developers (who can be selective) that they're not actually clueless.

rhizome7• 13 years ago

"Be Interesting"

As a corollary to this, I would advise companies to be OK with not being interesting. Not every business is exotic and innovative. If you aren't actually interesting, don't try to portray the company so.

"Rockstars, etc...."

This has been hashed over so many times, especially here on HN, but I do want to point out that there is a YC company (that has been trying to hire for A LONG TIME, here and on SF Craigslist) who uses this kind of lingo. In fact, they were the YC company that implied to me that the YC partners don't actually try to control their companies too much. This company will be allowed to create their own business (or not) via their own philosophy, which is a point in YC's favor.

stanleydrew• 13 years ago

So just be yourself as a company then right? Of course put your best face forward, but don't lie.

If you're 5'4" and balding it's going to be apparent to anybody you meet, so there's no point in lying on your dating profile. The same should apply to recruiting. Both are a "dating game."

greenyoda2• 13 years ago

Very good article. I have just one thing to add: If you don't tell me a salary range up front, I have absolutely no incentive to even talk to you. I have no desire to go through an entire interview process just so I can find out that you'll be offering me a salary that's $100,000 less than what I'm currently making. It would be a huge waste of both your time and mine.

renegadedev• 13 years ago

I just got an email from a recruiter who's looking for a SQL DBA. The applicant must know (note the lack of mention of DBA skills): Java Script, jQuery, CHTML, CSS

I also frequently get asked by recruiters "how much do you make?". How is my current salary any of their business?

blackdogie• 13 years ago

Personally I don't think that recruiters are worth paying any attention to. At least not in the cookie cutter version. If they want to get in touch then that's cool, but if it's a generic email it will get labelled as SPAM.

ruswick• 13 years ago

I concur with the point about the ridiculous "rockstar" terminology. It's ambiguous and non-descriptive. However, the titles that truly irk me are "code artisans" and any variants thereof. I've seen this in use several times in the past few months, and it is the pinnacle of absurdity.

electrotype• 13 years ago

There is one main point that will help me want to work for you :

- Show me your business doesn't considere developers as resources that are easy to replace. Because this is not true. I've never seen a successful project built by thousands and thousands of inexperimented or bad developers.

anonfunction• 13 years ago

The biggest thing I took away from this is that you should treat potential employees like employees.

ghjm2• 13 years ago

Ok, so here's the problem. None of the recommendations in this are actually actionable. Consider:

- Be Interesting

Well, the company either is or it isn't. If you're an auto parts distributor who needs to convert your application from Cobol on AIX to ASP.NET on Windows, then well, you aren't really very interesting. And there's not one thing the recruiter can possibly do to change that.

* Care

Perhaps you genuinely care, but what if you don't? The recruiter is human too. Maybe they just want to do their job and go home. You can't decide to genuinely care. You either already do, or not. And we're saying they absolutely must not pretend to care. So ... the only remaining option is not caring.

* Acknowledge Applicants

I don't think Matt appreciates the sheer volume of resumés that come in for an advertised position. I know some HR departments that insist on sending an acknowledgement for every received application, and they spend a lot of man-hours on it, and are constantly having to defend this practice to executives. And honestly, why does the typical badly-formatted, ungrammatical resumé actually deserve a response, anyway? Matt may be a special unique snowflake, but trust me, all those other people aren't.

* Get to Know Programmers

You can't do this without getting to know programming. And the whole point of specialization of labor is that you shouldn't have to. You can hire a doctor, lawyer or plumber while knowing nothing about plumbing, doctoring or lawyering. Why should it be different for programmers? As a profession, why should the rest of the world bow to our desires, instead of us creating a better product for them to buy?

* Let Me Code, Dammit

This is the one piece of good advice. The best way to interview in any field is to engage the applicant in job-related task behaviors and observe the results. With programming, we're lucky that this happens to be pretty easy. But I don't understand how this squares with the earlier rejection of having the applicant code a Fibonacci function.

coditor• 13 years ago

I've said all of this many times on my blog as well. Sadly the only people who read my blog and live on this site are the hirees. The hirers never visit and remain ignorant.

tibbon• 13 years ago

Another thing that bothers me about some positions:

- 5-10 years experience with all of the following: PHP, Python, .NET, Javascript, C++, Perl, Erlang, Haskell, Ruby, IronPython, Lua, etc...

Seriously. Please god tell me you don't actually use ALL of those all of the time.

gavinflud• 13 years ago

This is an excellent post. I'm soon-to-be fresh out of university and the company I'm joining had a hiring process very similar to what you've described.

They were in constant contact throughout the process, sold themselves very well and - although they did carry out a cookie-cutter technical interview - it actually made for an interesting hour where I was able to solve their pretty simple sample problem and we ended up going off on a tangent talking about how to optimize the interview process.

What differentiated them from countless others was that personal touch. I always felt like they wanted me on board and they were able to sell themselves and their culture very well.

michaelpinto• 13 years ago

Having survived the first dot.com crash reading stuff like this always makes my "smells like a bubble" detector go off. Although to be fair I don't really sense that in NYC, so maybe this is more a reflection of silicon valley.

jwwest• 13 years ago

> Assuming I Am Only The Last Thing I Was

I can't tell you how much this annoys me. I've been programming professionally for over a decade now, and I've done a lot of things: C#, PHP, PERL, Ruby, Python, Javascript, etc, etc, etc. Taking a look at my resume, you would assume a rational and logical person would say: "oh, this guy's been in it a while, he could probably pick up anything" -- but this rarely happens.

I get it, you need deep technical expertise in X framework working with Y platform. Actually, no, I don't get it because a decent developer will pick up and run with anything you hand them, regardless of what they've worked on professionally in the past.

> Care

Passion != Success.

Look, I know you're oozing passion for building Twitter for Barnyard Animals, but don't expect me to show enthusiasm for your niche. Honestly, I've probably never heard of it before now. Maybe in time I'd come to really understand it and be interested in it, but right now I'm more interested in the scaling issues and optimizing my productivity through my tools.

freework• 13 years ago

My best interview advice is this: Don't ask questions to judge, ask to learn.

A lot of interviewers have an interview process that is mainly designed to eliminate candidates. Therefore, the process contains interviewers asking "fake questions" that are designed to trip up candidates and eliminate them. An example is a question like "How would you design a database engine". If I really had to build a database engine, the context and details of that situation would dictate how this database system should be approached.

Instead you should ask questions to learn. If you ask me what a cache is, you better be asking me because you don't know what a cache is. If thats the case, I'd love to explain it to you, because I like teaching people things. Its very awkward to explain something to somebody that obviously knows that concept very well.

When you ask questions like that, you end up subconsciously comparing candidates by their explanation of cache matching up with how you would describe cache. In other words, this process favors people who think the same. A team full of people who all think the same is a company that has many weaknesses. A strong company has people who approach problems differently. You need people who approach life differently. Diversity is extremely important, and asking fake questions during interviews leads to less diversity.

xtreme• 13 years ago

I see three problems with this:

1. It would pretty difficult to judge whether you are correct or not 2. This approach favors candidates with a flair for speaking but may not have good programming ability 3. The interviewer would probably run out of concepts that he can reasonably expect the interviewee to explain.

corwinstephen• 13 years ago

Not that this information isn't good or anything, but how many "the hiring process is whack" posts are there going to be on Hackernews before the message resounds?

graycat3• 13 years ago

Interesting thread. The tread is interesting to me because I'm a sole founder of a Web 2.0 startup with some relatively technical internals (in the server farm only), and have done all the work from the beginning to the present. If the startup works, then I will have to hire.

But, for what is in the OP and this thread, I have a different view.

Below I discuss the differences in three parts, software development environment, teams, and qualifications and add some comments at the end.

Software Development Environment.

I've been around computing for a long time, but I skipped over the big growth in Unix/Linux and C++.

Instead my more serious software development has been on IBM mainframes and now on Windows with Visual Basic .NET, ASP.NET, ADO.NET, SQL Server, etc.

Why Visual Basic .NET? It seems like the nicest way to exploit Windows, the Microsoft Common Language Runtime (CLR), and the .NET Framework (that is, the enormous collection of classes), and work with the rest of the Microsoft software for TCP/IP, SQL Server, IIS, etc. The syntax of C# is too close to that of C/C++ and, thus, is deliberately 'idiosyncratic' and 'tricky' and, thus, an obstacle and error prone; the Visual Basic .NET syntax is much easier to take. The idea of 'immutable' strings, each with maximum length 2 GB or some such, along with the ideas in 'managed code' and memory management seem terrific for my applications level programming.

I've always typed code into just a text editor, one that permits writing good macros, the most capable I had access to, done operations with just command line scripts, never used an 'integrated development environment' (IDE), and rarely used any interactive debugging. Instead, I just put some checks into the code, have the code write a lot of tracing data, and then look at it with a text editor. Always worked so far!

For my Visual Basic .NET code for my site's Web pages, I'm just typing into ASP.NET without any explicit use of model–view–controller (MVC) or other Web site 'framework', whatever such a 'framework' is! Once I looked at MVC for a few minutes, and it seemed that some of my code is similar!

I looked at Visual Studio, didn't like the documentation or the many small 'panels' all in one window (instead of the 10-20 windows I use), never saw a description of what they meant by 'dockable', and concluded that my favorite text editor and some command line scripts were more productive.

I've been surprised and pleased by how well Visual Basic .NET works for Web page development on Microsoft's Internet Information Server (ISS) -- e.g., just have a Web browser ask for the page using the loop-back IP address, and IIS kicks off the Visual Basic compiler, apparently for anything and everything on the site that needs compiling, does any 'link editing' on the fly or some such, and at the bottom of the Web page gives, based on options in the Web page code, lots of details on the compiling. Generally, if there are no error messages, then the Web page displays. It's nice. Microsoft should explain it someplace!

So, I begin to conclude that the main things a programmer needs are good versions of a text editor, scripting language, programming language, and documentation on these and the libraries, APIs, etc.

Teams.

I've done some software development in teams and supervised some software development. In both cases, the work went well with no attention at all to formal methodology, 'team tools', 'repositories', etc. In one case, I was one of a team of three researchers in artificial intelligence at IBM's Watson lab at Yorktown Heights, and we did research, published papers, designed and developed software, and our work resulted in two, shipped, commercial IBM Program Products, IBM's highest quality software product category. For one of these two the code that was shipped was essentially just what we wrote. In the other case, we did all the work except the actual code was typed in by an outside company in Taiwan.

In addition to our three researchers, and we all wrote code, we had several programmers. Really, it was a team of seven people. For a project that small, the lack of formality worked fine.

Once I was the Chair of a computing committee for an academic institution and, thus, in part a supervisor of a computing group that served the institution. We had several programmers, former students, with no formality at all, and the work was terrific.

I've never seen any formal approach to code 'building', testing, test 'buckets', 'quality assurance', etc., yet we had no problems.

So, I begin to conclude that for groups as small as seven, with a good leader and some good people, can do well with no formality at all. None. Zip, zilch, zero.

Programmer Qualifications.

The people I've worked with have nearly always been plenty bright, knew a lot, learned quickly, worked hard, etc. And these people were selected with none of the interviewing ideas in this thread.

Mostly the people were college graduates, but not all; some of the people had technical Ph.D. degrees; some were graduate students in technical programs and part time.

It appeared that generally quite sufficient (but usually more than necessary) qualifications were a Ph.D. in pure/applied math or theoretical/experimental physics, some good computer usage experience, and some scientific/engineering programming in two or more languages would be fine. Then such a person could pick up Knuth's TACP, Ullman on database or compiling, Sedgewick on algorithms, artificial intelligence, 'machine learning', the elementary

Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein, 'Introduction to Algorithms, Second Edition', The MIT Press Cambridge.

etc. and zip through like reading a novel. Gee, Knuth's TACP has a nice list of binomial and combinatorial formulas, good coverage of heap sort and the Gleason bound, B-trees, AVL trees, and random number generation, and more that is useful ..., well, maybe if I got out my copies I could find some more! Yes, he has a very clever presentation of the fast Fourier transform, but the more specialized sources, especially for signal processing, are better even if less clever.

Gee, guys, there are more tough technical ideas in several cases of just 30 pages in W. Rudin's books than in some stacks of computer science texts. For real technical creativity, R. Bland's proof in linear programming totally blows the doors off anything I've seen in Bachelor's or Master's level computer science or suspect is there or saw in technical talks at Yorktown Heights.

Yes there are some other hiring criteria, but they are mostly by 'exception'. E.g., if a person clearly has a personality problem that keeps them from working effectively alone or with others, then can't have that person around.

I begin to conclude that software is still a relatively simple subject, and for hiring the sufficient conditions I gave are fine.

For more:

More.

If I hire someone with a lot of 'skills' in tools and procedures for team developed software and those skills seem to be worthwhile, then that person could be helpful and welcome!

Compensation.

For salary, guys, look, the first thing to check is, does the job pay well enough to let you buy a house and support a family in nice conditions?

Large Software Projects.

Next, I confess: I've never tried to debug or modify a 500 KLOC 'code base' developed over 10 years by 20 programmers none of who are still there with no documentation except some sparse comments in the code. My view is that such code is not a programming problem but a management problem: To fix the problem, need a lot of time, money, and people. Sorry 'bout that!

Training.

I've never seen anything very useful in formal training. Have to accept that major fractions of programmer time go to working through bad documentation, learning new material, migrating to newer tools, writing little tools, etc. For a 'training budget', no: Just budget the time along with everything else; for travel and fees for formal training sessions, sure, but likely mostly the training should be in-house without flying across the country, business class, limo service, fancy hotel, rental car, big per diem, big training fees, etc.

Security.

In some organizations, have to take security very seriously. Might have to hire some outside firms with tools, procedures, tests, etc. Okay, then do that.

JavaScript.

So far have yet to write a single line of JavaScript. But so far Microsoft is writing about 300 KB of it for me, and I have to suspect that I could cut that down by a lot and, thus, save on bandwidth. So, if I have to write some JavaScript, then I will. That is, get some materials and/or 'training', learn some JavaScript, and write some.

Do something really complicated with JavaScript? I want to try never to do that!

And I would generalize that approach to JavaScript to nearly everything else in computing, for me and any people I hire.

Writing.

Once someone in my company has spent a lot of time and, thus, company funds, learning or doing something that has some importance, then I will want them to document what they learned or did so that the company can have the work as a continually valuable 'asset'. So, net, one of the better abilities I want is the ability to write good technical material. Being able to give a good technical talk would also help.

Net.

Many organizations want a lot of detailed 'skills' that I get by without and, thus, won't require in people I hire. I prefer JIT skills -- learn the stuff as needed.

eppsilon• 13 years ago

I appreciate that you posted this alternative opinion, but I found myself disagreeing with much of what you wrote.

I also work with the Microsoft stack, and I was surprised that you prefer VB over C#. I've used VB (briefly), and the syntax felt quite cumbersome compared to C# (which I use daily). What do you find "idiosyncratic" or "tricky" about C#?

Before I switched to .NET and C#, I used Django and Python, so I have some experience with the more barebones development environment you seem to like. There are things about Visual Studio that bother me, but I have to say that it's really pretty good overall. I think IntelliSense and ReSharper save me far more time than macros could. Also, interactive debugging feels significantly nicer than printing values to the console or messing with lower-level debuggers like gdb/pdb. What text editor and scripts do you use that you find to be better than Visual Studio?

How do you organize your code if you don't use MVC? It's a pretty well-regarded pattern; you may want to look at ASP.NET MVC or a similar framework.

In both cases, the work went well with no attention at all to formal methodology, 'team tools', 'repositories', etc. ...I've never seen any formal approach to code 'building', testing, test 'buckets', 'quality assurance', etc., yet we had no problems.

So, I begin to conclude that for groups as small as seven, with a good leader and some good people, can do well with no formality at all. None. Zip, zilch, zero.

You don't use version control, bug tracking, feature planning, nightly builds, continuous integration...any of those? I would think a project without those essentials would be quite disorganized.

These requirements sound extremely high. Wouldn't someone with a recent B.S. in computer science or software engineering be significantly more prepared for the job (as well as less expensive to employ)?

I begin to conclude that software is still a relatively simple subject....

I don't think this is the case at all. You can assemble a team of good developers, follow industry best practices, be blessed with a good product manager...and you still have to deal with bugs, tangled code, issues with libraries, changing requirements, architectural design problems, UX design failures, and so on.

For salary, guys, look, the first thing to check is, does the job pay well enough to let you buy a house and support a family in nice conditions?

Er, that doesn't sound all that good considering the level of demand there is for software developers. You need to at least match the average salary and benefits for the region and the skill level of the position. And you'll have to pay much more if you're serious about requiring Ph.Ds.

I don't think this is what is meant by "training". Learning new tools or libraries on the job is expected of most developers. Providing training means sending developers to conferences, buying them books on topics related to their work, allowing them to work with more experienced mentors, etc. Those things are really not that expensive considering the benefit you receive in improving your developers' skills.

Do something really complicated with JavaScript? I want to try never to do that! ...And I would generalize that approach to JavaScript to nearly everything else in computing, for me and any people I hire.

This seems like a very bad approach to use if you value improving your skills, gaining domain knowledge, or keeping up with industry trends. JavaScript in particular has been an area of incredible innovation in the past decade or so. Is it really worth avoiding just because it has some quirks?

So, net, one of the better abilities I want is the ability to write good technical material.

I somewhat agree. Developers should be able to clearly document their code through a combination of good formatting, useful comments, thoughtful naming of types and variables, and blocks of technical documentation (docstrings/XML documentation) where appropriate. But they shouldn't be doing the jobs of technical writers.

Many organizations want a lot of detailed 'skills' that I get by without and, thus, won't require in people I hire. I prefer JIT skills -- learn the stuff as needed.

This sounds good in theory, but I don't think it really works in practice. For most projects you need people to have certain skills or experience before they join the team...otherwise you'll spend most of your time reinventing wheels or teaching them the basics. For your web app startup, would you really hire someone who is intelligent and has credentials but has only a vague idea of how a web app works? Can you really expect them to just pick everything up as they go and still be a major contributor to the project?

graycat3• 13 years ago

I mentioned my use of a favorite editor and command line scripts; so, I should add some detail on those two:

My favorite editor is KEdit (Mansfield Software), a PC version of the IBM VM/CMS editor XEDIT. The macro language of XEDIT is Cowlishaw's Rexx, and KEdit uses their similar Kexx. My scripting language is ObjectRexx, an extension of Cowlishaw's Rexx. Rexx is elegant.

Nearly all my typing for everything goes into KEdit -- one means of input to rule them all.

My spell checker is Aspell from some TeX distributions; it's a darned well written program, can support several languages, and lets me maintain just one addendum dictionary!

VB:

I programmed in C for a while and got used to it. If I used C# daily, then I'd likely get used to it. As I recall, K&R confessed that the C syntax is idiosyncratic, which I agree with. E.g., can write

     i = j++ + ++k

Too tricky for me. When I read Lippman on C++, it seemed trickier. What I've seen of C#, say, from reading Microsoft's Web pages at their MSDN, it looks like it's borrowed such 'sparse' syntax from C++.

So far it appears that Visual Basic .NET (VB) and C# differ essentially in the flavors of 'syntactic sugar' and could be translated one to the other, almost statement by statement. So, I prefer VB mostly due to a flavor of syntactic sugar.

What I like in the VB syntax is essentially the "cumbersome" part -- somewhat redundant, easy to read, puzzle problem free. I type the code in quickly and let the VB compiler tell me when I've omitted little things. But there's enough redundancy in the syntax so that the VB messages usually still recognize what I intended. Good -- I don't want some tiny typing errors to convert what I want into a still legal statement I don't want.

VS:

First, I don't like the one window with lots of small panes. Second, when I look at VS, I can't make any sense out of it. E.g., I have no idea what the little icons or the various panes are for. Then, I've never seen any very good documentation. I could figure it out, but my objective is my business.

The times I tried VS; it created a 'project' where Hello World started off as 50 MB of 'stuff' I didn't understand. Then I fear that if, really when, something goes wrong I will have to dig into that 50 MB, with no documentation.

For more, I don't want to type into VS if only because I don't see any hope for the kinds of functionality I get with KEdit and macros that I highly value.

Instead of VS, here's an outline of what I do:

In the morning when I start programming on my Web 2.0 project, I run some little ObjectRexx scripts that open about 25 windows, mostly KEdit and Firefox, in a particular Z-order and arrange the UL corners of the windows equally spaced on a line on my screen from LL to UR while preserving the Z-order. I close the windows I won't be using that day and end up with 10-20 windows. When the windows get to be a mess, one click on an icon drives an ObjectRexx script to arrange the windows again preserving both the Z-order and the order of the left sides. Net, I get in effect much more screen area for my work than I get from the one VS window with its small panels.

The windows are mostly for files and directories where I am working or with relevant documentation. In addition, one of the scripts starts in a console window the session state store I wrote (some TCP/IP and a collection class).

I have 4000+ Web pages of documentation and a little system for abstracting the pages and finding the pages I need. In addition, for more relevant pages, I put in my source code page titles and corresponding tree names on my computer; then one keystroke in KEdit has Firefox display the Web page from which I can continue to traverse the MSDN tree back at MSDN. That's my substitute for Intellisense.

KEdit is terrific as an easily automated chef's knife and cutting board for slicing and dicing files of text, working with collections of files, starting programs, dialing phone numbers, etc. I don't want to type into VS instead of KEdit.

For debugging, the main challenge for me is finding the cause of the software going "poof" after running for some interval. So, with interactive debugging, there is too much stopping at break points and starting again. Instead, I just have my code write values of relevant variables to a file or, for the code for a Web page, the Web site log. After "poof" I look at the output, maybe 10 MB, go the bottom where the "poof" happened, and move backwards, using the KEdit 'select' tools to show me what I want. It's always worked so far! Sure, later I could have the writing go over TCP/IP to a program that keeps, say, the 10,000 most recent lines.

> You don't use version control, bug tracking, feature planning, nightly builds, continuous integration...any of those? I would think a project without those essentials would be quite disorganized.

Sure, some of those I do now. But I just don't yet have or need formal procedures and tools. One thing I do nightly is an incremental backup!

Since I'm just one guy, some simple techniques are sufficient for being organized. And at Yorktown Heights, I found that for our team of seven, still we could use just simple techniques.

> These requirements sound extremely high. Wouldn't someone with a recent B.S. in computer science or software engineering be significantly more prepared for the job (as well as less expensive to employ)?

I just said "sufficient"; I didn't say necessary or "requirements"!

One reason for my interests in this thread is that I don't yet know just how I will hire; I don't intend to hire all Ph.D.s.

My company needs for the code to be a solid company 'asset'. So, the code has to be well written and not just some gibberish.

For what I'm doing, I believe I could teach good people quickly.

On my

"I begin to conclude that software is still a relatively simple subject"

So, have (n)log(n) in-place sorting, balanced binary trees, TCP/IP, if-then-else, do-while, call-return, etc. Simple.

We are in agreement. Most of the sauces in Escoffier are fairly simple, but running a three star Michelin restaurant is not. Having a big chunk of production software in good shape and working and moving along nicely is not so easy and takes some good people.

On salary we may not be communicating: What I hear about programmer salaries, e.g., people happy to get $100 K a year, sounds a bit short of the standard I mentioned. E.g., $100 K a year won't go very far where houses are $400 K, taxes are high, and want to support a wife and three kids.

Early in my career, in one two week period I went on seven interviews and got five offers. Then I was getting paid about six times what a new Camaro cost. Today that would work out as $240-300 K per year.

Right, houses at $400 K are too expensive for anyone to afford. Yet, people keep buying them.

We largely agree on training. Some conferences are just for entertainment, but some are important for training. And could at times use some in-house lectures or short courses, given by people from inside or outside.

> This seems like a very bad approach to use if you value improving your skills, gaining domain knowledge, or keeping up with industry trends.

I'm not interested in JavaScript because I don't have anything important in mind I need to do with it beyond the JavaScript Microsoft writes for me.

I believe that the goals of both the company and the employees are closer to the bottom line, that is, the real business needs, than what you mentioned. And I believe that there is relevant knowledge to be gained much more valuable than what you listed. To me "industry trends" are too much like a fashion show, not that I've ever been to one.

We're not communicating well on the role of good technical writing. E.g., suppose someone in my server farm looks into system management platforms from, say, CA, EMC, HP, IBM, and Microsoft, goes to some conferences, tours some sites, gets some sales pitches, talks to some consultants, etc. Then I will want them to write up a report on what they learned and give a presentation to likely the whole server farm staff, myself, and maybe others.

I could list another dozen such.

For a significant new software development project, there should be at least a first cut design document.

For technical writing, I believe that should be done by people who understand the material really well. For 'technical writers', they may help such a person with organization, grammar, punctuation, building an index, etc.

Your remarks critical of "JIT skills" have some value. But I anticipate people bright enough and growth slow enough that what I outlined should work. If they want to know how the Web works, say, from the ISP connection into the LAN switch to the servers, etc., fine: I'll outline it quickly. Then I'll have the first person write up notes available to teach others, get some books, etc.

Current computing can be super complicated, but my plans for my company are to keep nearly all the computing relatively simple. If the computing gets to be a big, complicated thing, then I've done something wrong in my business planning and server farm and software architecture.

edandersen• 13 years ago

Now this is some fine trolling.

"I've been surprised and pleased by how well Visual Basic .NET works for Web page development on Microsoft's Internet Information Server (ISS)" - Jesus Wept.

graycat3• 13 years ago

"Trolling"? I have no idea what you are talking about. What I wrote is simply, rock-solidly, literally true -- "I've been surprised and pleased ...".

Your concerns are that I'm on Windows instead of Linux, not using Visual Studio, am using Visual Basic .NET instead of C#, that I didn't just criticize Microsoft but found something in their work I like, or something else?

Me? I've never touched Linux, tried Visual Studio in total for less than an hour, have not looked seriously at C# and so far have yet to write a single line of it, and do have some objections to some of Microsoft's work. Still, as I wrote, "I've been surprised and pleased ...".

If you have some concerns, then cough them up.

scardine• 13 years ago

"Micro Positions" are a known scheme to hire foreign workers under H-1B visas. The employer must, prior to filing the H-1B petition, take good-faith steps to recruit US workers for the position for which the H-1B worker is sought. For example, if you want to hire a Brazilian, publish a position for a "Python Portuguese-language backend optimization engineer". The Portuguese-language part is just to assure no US worker is qualified.

zobzu• 13 years ago

I'm not a recruiter but like everyone i do interview people from time to time. While I agree with TFA, of course, i think a few "quiz questions" are often necessary.

While you can check if someone can code on his github/whatever page without asking any question, you don't just want to make them want to work for you. You also need to screen them enough to figure out if.. they're going to be able to work for you. They're not all well known. There's new fresh people graduating all the time, and even if there's people that aren't just well-known (the vast majority!)

So, til there's better, i always have 25% of "quiz" questions, which are all 100% technical and all require either logic, either knowledge. (then 50% of discussion of the stuff there's to do, and 25% for candidate's questions). THEN if there's interest there's real interviews as in, come to the office 'n let's chat about stuff you'd like to do. Not before.

wfunction• 13 years ago

I beg to differ on the whiteboard part. Asking someone to code on a whiteboard is a perfectly legitimate way of seeing if they can code a few lines (with minor mistakes if need be) without needing a compiler to guide them through each step.

How To Hire Me (or any other programmer)

Related Stories