Hacker News new | comments | ask | show | jobs | submit login
Hiring Developers: You're Doing It Wrong (pen.io)
399 points by Udo on Mar 30, 2011 | hide | past | web | favorite | 218 comments



I worked for a German startup too and our main problem was not vetting interviewees but finding people who want to interview at all. In the five year history of the company I think only one single person was hired who was not already friends with someone at the company.

Other people just never applied. I remember manning the booth at one of those college campus events and it was very lonely. I probably talked to three students that day. Nobody followed up with us. I even had the distinct feeling that students avoided eye-contact with us and made beelines for the booths of the big established companies.

In the end, our hiring interview process for interns was 'do you want to work for us? yes? you're in' and for full-time applicants it was simply non-existent. I think in the last three years we did not interview a single person.

I often wondered why that is but I have never found a good answer. In the end it worked out for us. The company was acquired by Google.

Still, I would have liked to have some applicants and interviews once in a while because I keep reading so much about them and I wanted to practice being an interviewer to avoid pitfalls as described in the article.


Was your company offering "business solutions" by any chance? I remember once walking across an IT fair in Munich and being floored at the extreme boringness of all the company banners. They all seemed to provide "solutions" - whatever, no details about what they were doing (solutions for what?), nothing special going on. My brain was completely drained after the walk.

Just saying, maybe a better presentation could help. Also working in a software company is a kind of dreadful outlook, even today (neon lights, specs filled with hundreds of pages, dreary meetings...).


Business solutions is indeed just a fancy word for trying to make overcomplicated products with too many features and overcharging unknowing businesses. Business solutions is much shorter. Looking for a job soon, but job fairs seem very counter-productive to me: websites give a much better impression and idea of possibilities and lead to faster filtering of options.


Maybe it varies between regions. We were based near Mannheim, and it was hard to find interesting software startups. Our town even has a technical university which meant that graduates were always looking for jobs in a market that didn't have that much to offer. In the web world, developers mainly had the choice between working for an advertising agency or work at a very small shop with less than 5 people. Non-web devs would have to choose either IBM in Mainz or SAP in Walldorf as a matter of course. At least that's what it looked like from my perspective, I could be wrong. So yeah, we got a lot of CVs for any job postings and people were also sending them in when we had no openings. I guess the region was just starved.


I have heard this anecdote from many of my friends as well. So my advice would be : any devs frustrated with jobs in their country head over to Germany ! It's a beautiful place with a comfortable work culture ...


I'm a student and I'm thinking about taking a year off from college (a CS degree) and explore the world of startups.

US is out of option leaving with some European country. I've heard Germany has a very vibrant software industry.

Can you please give a little more information about heading over to Germany?


Think about Slovenia too... very vibrant start-up community here, English is a standard too.


Getting to Germany is the easiest when you are a student here.

Do you want to think of getting a Master's here ? This i) helps you get here ii) gives you more access to startups who would be hesitant to take the burden of visa processing


I am planning on moving to Germany in the next year. Any resources for finding a job in Berlin?


It depends. What are you looking for?

Get yourself a xing.de profile. Headhunters find me there all the time.

If you are looking for an iOS or Android job: Apply at Neofonie Mobile, we're hiring :-)

From my experience (Lot's of Java backend stuff). A lot of companies in Berlin are looking exactly for Java backend developers. Some are looking for Grails, Rails or Python developers.

On the other hand: There are many Hackerspaces and meet ups in Berlin to find like minded people:

http://www.c-base.org/ (Android Round Table, Lisp, Wifi-Hacking)

https://berlin.ccc.de/ (CCC-Stuff :-))

http://berlinwebweek.de/ (various stuff, some about business, some about hacking)


I'm actually still new here, but one suggestion I've heard is to directly apply to companies you are interested in.

But be prepared to deal with a borderline byzantine visa system, though ... about the only thing I can complain about.


When we advertised our job posts through different media nobody reacted. Headhunters would send us candidates which were too expensive for what they were worth.

So I ended up hiring ex-colleagues and friends who I convinced to start working for us. In the mean time we took 2 interns a year offering a job to the suitable candidate(s). This we we were able to hire staff.

The slow hiring process meant I needed to outsource some projects abroad to off shore development companies.


I'm curious, where in Germany was that college campus event?


Whaddaya Mean, You Can't Find Programmers?

It is a give and take. If developers are in high demand, it is the companies turn to show their value to the employee in advance.


out of interest, what did your company do?


Ah Germany - where I just gave up applying for jobs.

"Oh, yeah, I see - you've got 10 years of experience. But what's that? You don't have a diploma? Nor a 'Ausbildung'? Sorry, in this case I just won't look at your prior work - no matter how cool it might be. Have a gut day, sir! No job for you."


Wow here in Australia we get HUNDREDS of people lining up to interview for every job we advertise.


This is the same thing I've found, in Brisbane.

People apply for jobs without skills, without hobbies involving development, without experience and without even looking at the website.

I simply don't understand it... Are they hoping to get employed to twiddle their thumbs? Do they think they can pick it up on the fly?


When advertising on seek.com.au we've resorted to adding additional filters, otherwise we get so many resumes that we just can't read them all. And yes, most of them are clearly from 'spray and pray' applicants with no relevant skills.


Why not add a code puzzle that has to be solved before accepting a submission? Then you'd weed out some of the spray.


Which company would that be, if you don't mind me asking? :)


We're just a random B2B company you've never heard of (Sydney)


Really? Well, I guess you're not based in Echuca then....


The only hiring process I have found to work for developers is to sit down and work on real code together.

This gets to the heart of the matter, and you very quickly feel out someone's knowledge, ability, and most importantly, how well they collaborate on a problem. Because in a startup you will need collaboration, and likely under the highest stress moments you've seen in your life.

I also feel like this gives applicants a much better opportunity to learn about their possible future company and coworkers, and whether they themselves would like the fit. If you have not done this sort of interview, even if you have never pair programmed, try it out. It's very effective.

What I'm still trying to learn, is what screening process to use ahead of this. Sadly, you can't invite everyone for an on site day long interview. The best I've come to is to look at what applicants have made on their own time or alternately how they talk over the phone about topics and problems they're excited about. Resumes are nearly useless.


"The only hiring process I have found to work for developers is to sit down and work on real code together."

Yes. My favorite is to ask the candidate to go on a webpage he has been working on, show me the source, and we start discussing it together. I can ask him to explain some markup, or simple javascripts. Then the key point is when I go and criticize a part of his work. Two bad reaction: immediate yes ("sure boss! you are right boss") and immediate no ("who are you to criticize my work?"). I take the guy who really starts to think, check if I could be right, and accept to discuss the technical point of view.

Other point: I need to shake his hand, it tells me a lot!


The handshake thing worries me a bit... that seems more in the category of things that many people rely on, but actually tell you very little about the person.

Someone with a good handshake either:

* just naturally learned to shake hands in the way you like

* found out that handshakes are important to first impressions and spent time perfecting theirs (including maybe a handwarmer in the pocket...).

Does either of those things reveal any important traits?

People naturally have different levels of perspiration & circulation in their hands, particularly when nervous. Anyone going for a job interview they care about should be at least moderately nervous.

So someone might have a cold clammy handshake purely through genetics. How many strikes against them should that be? Firmness and eye contact are based on habits, generally -- again, the developer who's thinking ahead to the "important" parts of the interview will just give you the handshake they learned as a child. How many points against them should it be if it's very soft (because they were raised by an arthritic grandmother)?

Too much rambling for a small point, but I just want to say you should try to reserve judgment on exactly this kind of thing until they've had a chance to relax a bit, get talking, etc..

Personally, my handshake is probably pretty good, but I'm not going to be really at ease talking with you until we've been interacting for at least a few months. I've learned to fake it over the years (and keep calm enough in the face of strangers that I can think straight, for the most part...), but the hiring process is definitely harder on introverts.

I went through an phone interview a few months ago that included some quizzes, talking through solutions to invented problems, etc., and was glad she agreed I could hang up the phone while I thought (and took notes)... this resulted in a much better answer than I would have given if forced to think through it while on the phone with a stranger.


I wonder if you could give them access to a custom subdomain of a test site and tell them to build a web app, anything they want, and upload it. Give a suitable time limit, a day to a week, depending on how much you want to see and whether they already are a full-time employee or student. Then screen based on what people came up with.

That's a bit more involved than the lighter-weight solution in the same vein - remote coding tests facilitated by a collaborative website. But it's something I haven't heard of yet.


Right, that's because no sane prospect (or rather, a prospect you'd want to hire) would go along with it. A reasonably competent developer has several options to choose from - it's just not rational to spend 10+ hours on each job opening; you wouldn't be able to coordinate and assess 5 or so offers in a reasonable time (when looking for a new job, people will apply at various places, compare the offers and take the best one).

Most competent people would scoff at a suggestion like this, and I suspect that competent employers know it.


As a SCREENING mechanism 10 hours might be too much for the candidate to spend. But once past the initial screening, if there is serious consideration of an actual job offer, it is quite reasonable. The company will spend a good deal more than that on every candidate brought in for interviews (if you add up the time of everyone at the company). If the applicant is considering tens of different offers then they're Doing It Wrong(TM) -- they should pick the 4 best and choose amongst those. If they're considering 4 offers and can't spend 10 hrs on each, then why on earth not?


Asking someone to spend 10 unpaid hours on a test is a great filter - for developers to see that a company doesn't value their time.


Because it's 40 hours wasted. 40 hours = one full working week = for (I think) the type of professional we're talking about $2000.

I guess we can differ in opinion on what is 'reasonable' but I say that requiring what you're proposing is too much for me personally to take any such employer serious.

(on the part of the 'past initial screening', the employee can't know or verify this. If there are 50 applicants, and there are 15 selected in the 'initial screening', is it reasonable to ask for 150 hours of unpaid labor from these people? I posit it's not.)


$2k to find a good hire is nothing. Signing bonuses, referral bonuses, and interview related expenses (air travel, taxis, hotels) are often on that scale or larger. Also, your numbers are way off the mark, you're not going to bring in 15 people for such an interview, you'd be extraordinarily lucky if you even managed to have 15 people that looked good enough to go that far, but even if you did you'd screen it down to a lower number to make it more feasible.


Uh, what? I was talking about a $2000 cost to the job seeker. It may not be that much for professional, but it's nothing to sneeze at either (I've seen people making a multiple of 120k fret over much less than 2k).

The GP was talking about doing the 'screening test' for everybody who passed a first qualification stage. I don't know where you work, but having 15 'might qualified from a cursory glance at CV' applicants is very normal. Basically it's everybody who can use a computer and format a CV without using Comic Sans, and is smart enough to phrase his work experience or degree so that it sounds like it might have something to do with the advertised job offer.


Agree with roel_v. There is no way I'm going to spend a week working on a screening project unless I'm extremely confident in my chances. And usually when you're really confident you already have a friend in the company. If the company paid for the effort that would be a different story, but advertising that could cost them quite a lot.


What about candidates who are currently working (for a competitor)? Taking a day off to interview is bad enough.


> 10 hours ... is quite reasonable.

How many good candidates have been willing to do it?

That's the fact that matters, not an argument about what people "should" do.

> If they're considering 4 offers and can't spend 10 hrs on each, then why on earth not?

Suppose that I'm considering two offers. One wants 10 hours and the other doesn't. Are you seriously suggesting that I shouldn't take that into account?

The answer to "why not" is "because even if getting a job is my only priority, paying extra for a chance at given job isn't".


We did this for our most recent front-end hire, actually.

We gave him a two-day project to complete for us, and compensated him with what we thought to be a fair stipend for his time. He completed the project, we hired him, he cleaned up the project, and we actually put it into production a week after his hiring date.

Everything worked out fine, and the developer in question is quite competent, sane, and rational.


It makes sense if you basically call it a freelancing job with an option to hire. If it's an unpaid interview, though, it just seems unfair and likely to turn away some of the best candidates.


Yeah but you paid him for it, that's a different situation.


I agree, there is no substitute for working on a real problem together outside of the pressures of an interview room. This'll really give you an insight as to how a candidate is likely to perform within your team.

I'd have to disagree that all resumes are nearly useless though. We need some way of screening people and I think we just need to improve the resume format. Perhaps by making a tech resume more structured and uniform across candidates things could be improved. I built MightyCV with the aim of doing this - it's a resume platform with hackers in mind. I'd like to see MightyCV become a service that shepherds candidates towards producing a resume that is actually useful to tech recruiters. A MightyCV allows you to hook into the API's for HN, Github and Stackoverflow. When integration is activated this means recruiters get a useful at-a-glance overview of what people have actually been up to in the community. I'm toying with the idea of using an aggregation of these metrics to produce an overall MightyCV score. I'd then like to create a MightyCV map that resume owners could choose to place themselves on. Candidates electing to be included on the map would only appear if they had attained a certain score. It'd be a little like how down-vote privileges work here on HN, i.e. you have to earn your way on to the MightyCV map. I guess if I set the score threshold high enough then this map could become a good source of resumes within our sector that weren't entirely useless.

Also I liked the OP's suggested list of questions too:

- What's the last project you worked on at your former employer? - Tell me about some of your favorite projects. - What projects are you working on in your spare time? - What online hacker communities do you participate in? - Tell me about some (programming/technical) issues that you feel passionately about.

I'm going to give some thought to how I could incorporate these questions into MightyCV. I might even consider making them compulsory for all MightyCV owners. What do people think? Is forcing people to include something in their resume a bad idea?

Anyway, if you've read this far you might be interested in seeing what a MightyCV looks like. Here's mine: http://robeastham.mightycv.com (For those paying attention I don't think my theoretical MightyCV score would be high enough to get me on the MightyCV map at the moment. Answering SO questions is on my list of things to do in April).

If you like the look of it and want your own MightyCV then sign up for the private beta. There is a beta code and link in the first entry for experience within my resume. There are a couple of bugs I'm ironing out at the moment, mainly associated with the LinkedIn profile importer, but otherwise it's fairly robust. If you try it, I really hope you like it.


The spare time issue is an interesting one. One one side we have companies saying that they look for programmers who are working on projects after they get off work and on weekends. On the other side we have companies having employees sign a contract claiming that everything they do 24/7 belongs to the company. Often both sides are the same company.

It's not an issue for me only because I work for my own firm, something I had to do to get out of such bizarre situations. But it's an issue for many programmers who are told that working on their own projects is stealing time and mental energy from the company. I can certainly sympathize with the talented developer who, told that the company owns all his private projects done in his own time on his own equipment, simply chooses to leave at 5 and spend time with his family rather than have passionate private work seized and shelved by a firm who had nothing to do with its creation. It's really the rational choice if you think about it and something very valuable in a developer is rational thinking.


To be honest everywhere that I have applied as a programmer has either had the 24/7 rule or a contract so unspecific that it leads me to think that they will try to take ownership of something I write if it does indeed lead to a valuable product. As such I am usually working on projects in my free time but I rarely want to tell them about a real project for fear of them trying to take it. It creates a difficult situation in an interview, when I have projects but I dont want to discuss them.


Have you tried asking for a written addition to the contract saying work you do on your own time, unrelated in subject to what you do for the company, belongs to you? Contracts aren't always necessarily one-size-fits-all, and if that's the only thing keeping you from a good job it might be an option worth exploring.


Since this is a story from a German company... such a 24/7 clause can't be enforced in .de, it's void.

The company can claim inventions you made during work hours, and can forbid you to compete with them directly in your free time. That's it.


And in some states (like washington), by law, work done on your own time with your own equipment that does not directly compete is yours too. (And the law even says you have to put it in the contract!)


My previous employer (http://thefrontiergroup.com.au) had a process where candidates would come and spend a day onsite. You'd be paid for the day.

The process was to work together with a senior coder on problems of escalating difficulty. Starting with

    1.upto 10 do |i| { print i }
"What does this do?"

And ending with "Here's a legacy application we maintain. Add a new widget to the dashboard. Think aloud."

During the day you had lunch with the team.

Even so, that process didn't work perfectly for them. They hired me and about 6 months later they decided to fire me.

Subsequently they've focused on hiring people they already knew. For example, they've hired Darcy Laycock (http://sutto.net/), who they've known through the Rails community for years.

... and in all fairness I'd sack about 5 of me to get a Darcy on board.


> 1.upto 10 do |i| { print i }

My answer would be "bombs with syntax error," assuming this isn't something that just looks like Ruby.


Well now we know why I was sacked!


Erm... why did they fire you?


I've wondered about that myself. I wanted to stay, I liked it there. But it's like many relationships in life, if both parties don't want it, it won't pan out.

Edit: I also had to take time off for studies and I suspect they really wanted all-hands-on-deck.


If a person is fired from a company, and that person doesn't really know why, it is not a plaudit for that company or the managers involved.


In their defence, they were new to having to manage people they didn't already know -- which is probably why they went back to hiring people they already knew.


A tribunal would find out soon enough. Ker-ching!


Darcy also goes to school although: "By day I attend the University of Western Australia"


They had about half as many people when I worked there and it was fairly full-on.


In my previous "day" job, I probably interviewed more than 100 candidates and hired about 15-20. Here's what worked for me:

1. Phone screen (~45-60 mins). I'd spent ~15 mins going over what the company does, what the work environment is like, the team structure, the personalities, the technologies, etc... I'd try to "sell" our opportunity to jazz up the candidate and get them at least curious and hopefully very interested. I'd weave in a little of why-are-you-changing-job, what-was-your-experience-like, or what-would-you-prefer, and then ultimately we spent the majority of time on a recent project that he/she can talk about in depth. I pushed on a few related technical aspects to those projects to see if the candidate could clearly explain himself/herself technically.

2. First round (1.5-2 hrs). If I liked the candidate's potential after the phone screen, I'd invite him/her to our office to meet me and another engineer. We'd go into more depth about their recent project(s), and then go through a design/code exercise for a web application (the company builds web apps). The exercise was very open-ended (there's really no one correct way to do it). The design/coding choice depended on many factors, and we helped steer the conversations so the candidate could talk about those factors and what he/she would do to handle each of them (including when not to handle certain situations).

Along the way, we also probed into how he/she would work with other team members, how/whether to "challenge" another colleague, what/if any development process he/she would follow.

There was no trickery, no reversing a string, no linked lists. But I might ask how one would deal with concurrency conditions (two users trying to claim a single resource), how to scale with traffic, etc...

The candidate was encouraged to ask questions throughout the interview. It was a two-way street after all.

3. Second round (another 1.5-2 hrs). If first round went well, I'd invite the candidate back to meet a few other employees (e.g., another engineer, a Product Manager, a designer for example). I asked these other employees to ask anything they'd like, but at the end be able to tell me if this candidate would a) be smart, b) get things done, and c) have right cultural fit. If anyone had strong objection from this round, it almost always resulted in no-hire.

Equally important to hiring well is to let employees go quickly if they don't fit. That's a separate subject worth its own post.


Seems to me you just shouldn't ask typical "CS problems". The problem with those is that a positive result doesn't necessarily mean that the candidate knows anything. It could be that they've just interviewed so many times that they know a few common answers to memorize.

I still think asking coding questions is extremely important. Programming is one job where you can actually test skill in the interview (unlike management for example, where you mostly have to rely on personality, work history, and references). I don't know why you woulnd't take advantage of that opportunity.

As for culture fit, obviously you need to do that too, but that's somewhat orthogonal to what else you ask about in the interview.


I agree that these types of questions can lead to false positives, but what about the negatives? Don't these have some value as filters? After all, if I can't answer a simple question like string reversal, it suggests that I can't code AND I'm not enterprising enough to do some rudimentary Googling to practice technical interview questions.


If you assume the goal of an interview is to hire "good" people then you're right. If you assume the goal of an interview is to not hire "bad" people, then I think you're wrong.

I think in practice it's almost impossible to determine if someone is a "good" hire based solely on an interview (regardless of technique). It is possible to determine is someone is a "bad" hire based on an interview however.


Despite having written tens of thousands of lines of open source code, I have yet to have an interviewer who has looked at that code and asked me about it.


Really? That's the most surprising thing I've read today.

As an interviewer, Open Source contribution is one of the first thing I look for about a candidate.


I think most people look for it, but that the poster is talking about due diligence. It is easy to read that someone contributed to open source and give them brownie points. It takes a bit of effort to find the work they did, figure out what its doing, and determine whether they actually did a good job. People try to conserve their mental resources, so they don't always put in that effort.


That speaks volumes about the interviewer(s) and their company. Did no one look at your resume before speaking with you?? If not, that's inexcusably inefficient.


Do you mention it in your resume or cover letter? We try to look up information about people (blogs, open source contributions, etc.) before or between interview rounds, but it depends on how much the candidate pushes it and how much time the interviewer has to look into it.

Just having committed to an open source project would put you way ahead of most of the people we interview.


Whenever I see a resume with open source code, I always visit and try to read some of their code. I rarely ask them about it (there's little time), but it does inform which questions I want to ask in the interview and my overall impression of their skills.


> my overall impression of their skills

If you do this, please take into account the time they wrote the code too - they might have improved their skills significantly since then.


Even bad code would make for an interesting discussion topic during the interview. The code may turn out not to be as stupid as the interviewer thinks after all. Or maybe it is, in which case it's great to talk about lessons learned. I think every developer has some bad code floating around out there, including the person conduction the job interview. They'll understand. And if they don't, that's a great litmus test for the type of company you are applying to as well.


My last interview at the company I'm at now went somewhat like this: "Your CV looks fine, we wouldn't care if you're an axe murderer, now what would you like to do/tackle?". Should have been a warning sign: interesting company to be at.


What do you mean by interesting? Do they have a lot of axe murderers there?


Everything practical-wise is done my the boss, who is painfully slow at anything practical (salaries, supplies, workstations, etc etc). My project is a sideproject, others have projects with constantly changing features, deadlines and requirements.


Doesn't every company have a Murder Division?


Interesting has it's ups and downs.


Speaking from personal experience, a bad job can leave your "passion" somewhat lacking. I think if you asked anyone I work with today, they would definitely describe me as passionate. There are indicators that I am doing well there. I can't agree more with this article. I absolutely hate doing tech interviews. I can not code under pressure. Even in the most high pressure situations with an outage or huge customer issue, I always take a step back, think, and try to see what else might be affected before doing anything.

I hate tech interviews so much, that I never do them. I mostly do unconsciously what this article lays out. I would say personally I've experienced better than average hires if I happen to be positive on the person, doing what this article suggests in an interview. I have missed good people (was overridden) and have failed tons of tech interviews where I thought I would be an excellent fit on the other qualifications.

You'll have to ask my co-workers if I'm good, but they tell me I am.


While at my last job I was tasked with being apart of the interview process. My favorite question was "how do you keep up with web technology and trends? (web development)" and I was surprised at how many people had no answer for that simple question.

My response to my manager was "this dude wont work"


I've experienced the same thing while conducting interviews. The flip side is that some people have great answers and they often open up and show their passion for programming when they get to talk about the things that interest them and aren't as focused on how nervous they are trying to answer your question correctly.

I've also has people tell me that they read the study guides for the Microsoft certification exams. I'm not trying to start an argument about the value of certifications. I think it is questionable though when asked how someone keeps up with the latest technology, they reply that they read books with content of questionable real world application, from a single company, that are updated every three or four years.


My answer to that one would be "I've found it's more efficient to not keep up with the latest fads."


That's understandable, if a little antagonistic. I'd probably probe further just to make sure your definition of "fad" is not "anything newer than Blub."


I would consider that a bad response if you kept it after probing simply because the sales dept likes to sell clients on the lates/greatest tech. And if you were a serious web dev, you'd have to keep up with it in some way.

Assuming you are a web dev, Im sure you know which browsers support which html5 features, which ones play which video types natively, and the newest css3 tricks that everyone except probably IE supports.

There is changing course with every shift in the wind and there is understanding which way the wind is blowing and charting your course based on the fuller picture. (and of course there is "the wind is blowing?")


I don't know, I feel like I might be reticent about admitting exactly how much time I've wasted on HN and /r/programming.


Here's my 2c's on this as a 12 yrs Software Eng and a startup founder:

1) Software development is a TEAM work, so asking one questions like "how did you design this or that" is just pointless. We did design that on that specific period of time...Our motivation was ... 2) Good Developers Copy, Great Developers Steal (altered from P.Picasso), so we all use Google, HN, GitHub, wikipedia and alike to innovate our solution, so if you ask me B-Tree algos, I'm sorry, but I've to look at wikipedia... 3) Hiring process is just a scumbag for both parties, you impose big, the other party imposes big. So what? You're not Google, and he's not Kevin Mitnick... 4) I think, companies should try to get the personality, not the KLOCs of applicants. If you gonna ask programming puzzles, please be authentic and ask something related to you. Not just copy a Googlr interview question because you liked it.


My current system is:

1) Simple programming challenge (< 30 minutes) by email. To see if they can actually write good code. Resume/age/experience/location mostly disregarded.

2) Casual discussion-style interview to get to know how they think and behave.

3) Short term contract with a predefined project (< 3 months) to see how they work over time.

4) Full time hire with salary + equity.


If (3) is working for you, great; however, bear in mind that it's a seller's market for talent right now. I'd neg an offer contingent on doing a 3 month contract first, and I'd advise my friends to do the same; why should I shoulder that risk, if there are 2-3 other good positions open that will take it on for me by offering FT right away?


I think the problem between tptacek and me and the others arguing is that many of us are not from the USA... The USA being an At-Will employment system, there is not as much downside with hiring someone full time and the health care issue is specific to the US...


Conversely, (3) might attract some programmers who want to work at a place that is very careful about who they bring on FT.

There are three risks compared to a FT offer - (1) the business goes south and they can't afford to bring you on FT (in which case you might be screwed even if you had gotten a FT offer), (2) you're not a cultural fit (in which case, it's the better outcome for everybody) and (3) you don't meet their standards.


No, you've missed a key risk: (4) that the prospective employer continues to get resumes from people even after "filling" the position and decides on T+89 that you're great, but they can do even better.

During the 90 day contract, both you and the employer must technically still be "looking" (the company still has an FT headcount to fill, and the dev still doesn't have a job). But the company is inherently better positioned to deal with the uncertainty: companies hire many people simultaneously, and keeping a req open costs them nothing. Individuals, on the other hand, have a very hard time conducting a serious job search and doing their 100% on a full-time job simultaneously.

That is not actually a risk in the FT dev model, where the incentives are structured differently; it is instead very much more like the "up or out!" model of the Big 4 accounting firms or investment banks: you got the shot at the gig, now work your ass off to make sure you can keep it!

If you are a friend of mine and you are staring down the barrel of one of these "contract-to-hire" offers, take my advice: turn it down. We've been hiring nonstop for the past couple years, including for dev, and it is ludicrously, insanely good to hire good people. You hold all the cards, except (tragically) the one labeled "knowing what you're worth".


I agree with you, and want to add some more about this. Usually the 90 day things are from companies that also want you to sell your house and relocate to where they are. Often you do a fantastic job and are let go at the end of the 90 days because 90% of the time this scheme is how disreputable companies hire contractors for 90 day stints while paying low rates with no benefits.

Now sure, this guy is the rare 10% that is completely honest and pure, I will assume that and he has no ill motive at all. But the other 90% that he has no control over is the real issue with this. Most people with talent that have been around the block a couple times have gotten burned by this scam and avoid these scenarios like the plague. If you are a reputed expert the way you handle this is either handle it as a straight consulting job at your standard rate (which should be something like $180-$250/hr if you are any good at what you do or $120 if you are a newbie) for the 90 days, or you put a big fat penalty in the contract that if they say no at the end they have to pay severance to cover the full cost of both of your relocations, the one out there, and the one back, including losses from the required hasty real estate transactions. Will they agree to these? Usually not, and that's the point. You really only want to do business with people who are fair dealing, not people looking to cheat contractors through false promises.

Another scam is the two day long interview where you work on some serious problem the company is having and it happens that you are known as an expert in that field, your name coming up on some searches. For me it was Windows graphics drivers. Back in the 1990s I would get tons of job interview requests and then would be treated to two days of intense querying to "prove" that I knew how to solve their problems in detail during which they either took a lot of notes or recorded the interview. Lots of other people get this one too.

Another related scam is the programming problem you are supposed to solve which should take 30 minutes, but as an expert it takes a full week. Instead of being a puzzle it is something obviously related to their business.

Just say no to all these! I know the bright eyed and bushy tailed kids won't listen, but this old geezer has to warn them nonetheless.


Don't throw the baby out with the bathwater - plenty of scams out there, but the lesson is to look out for those that you mentioned, not to use the contractor stint as some sort of litmus test.


(4) isn't really a risk if the employer is following a consistent hiring procedure, since they will not have had the time necessary to evaluate your potential replacement. What sane employer is going to willingly pass up someone who's been vetted over 3 months (and determined to meet the standards) for an unknown?


Hey, if you say so. If this is working out for you, that's great. I wouldn't do it. I'd tell friends not to go along with it. In Q1'2011, I wouldn't have wanted to do anything that made it even epsilon harder to recruit and retain the best people. But I'm (a) in a talent-intensive business with fierce competition for people, and (b) a consultant who knows a bit about how contracts are actually valued and who thus thinks anyone getting less than $XXX/hr for 1099 dev work might be getting jacked.


To each their own - if your only goal is to minimize missing qualified people, then I would agree that you should offer FT offers to everyone. If you have a stronger goal of minimizing the number of unqualified people you hire, then that's a different issue.

Personally, I'd rather work at a company that falls into the latter category.


Yup. "No false positives" is my goal. I've experienced what happens when a company gets bloated and teams get diluted with bozos. Even one person can poison a team. Firing people is bad for a team too. I'm determined to avoid that to a great extent. I know of no other way than actually working with a person to determine whether I want to keep working with them.

I don't think most people even question how ridiculous it is that companies interview a person for a couple hours and then agree to work with them for many months or years before they will even consider firing them (usually only after additional months of trying to "work it out").

In my opinion the best recruitment tool is having a team that a potential candidate would be really happy (and lucky) to work with. You can only do that if you keep standards up and hire slowly and methodically. A bit of a pain in the beginning, but worth it for everyone involved in the end.


Does not giving someone a full-time offer after the short-term contract hurt the team like firing someone? I could imagine it going either way. Perhaps it's better because those not in their contract period don't start thinking "it could happen to me at any time."


As a candidate, I would like this approach a lot because it would give me a better opportunity to evaluate the organization to find out whether it'd be the kind of place I'd like to work. A short contract is an excellent way for both sides to evaluate one another and make sure that the fit is mutual; I've worked both in places where I loved the technology but disliked the culture and vice versa and neither one is great for long-term full time employment.

Of course, that is provided that the company would be paying my standard consulting rate for the relevant 3-month period.


If the 3 month contract is paid the normal wage then I'd rather go to a company that does this because it means that there's an higher probability of having competent coworkers there. That's the reason why I do the same in my own company now.

This is of course because he said he didn't care about location, so there's no moving costs and so on...


Why would the competent developers migrate to the company that is more hostile, in a purely objective sense, than the alternatives?


It's like they're almost trying to winnow the pool down to developers whose programming ability outperforms their career experience and business sense. They certainly exist: I had the business sense of wet paint as recently as two years ago (which might explain why I willingly worked as a salaryman despite having perfect knowledge of the hours and salary).


Or winnowing it to people who have experienced the results of conventional hiring practices and want a place that is more rigorous about it.

I spent many years hiring and working for companies that did it the way most people do it. The results speak for themselves: most companies suck to work for and most of them suck because of a few (or not so few) bozos and the environment they create.


That's kind of like asking why students choose to go to harder/more hostile universities.


You go to a challenging university because you want to take advantage of their knowledge, to the extent that you're willing to pay them for it. An employer wants to take advantage of your knowledge, to the extent that they're willing to pay you for it. The situations aren't comparable.

I agree that three month contracts should be compensated at contractor wages rather than employee wages, unless the company is also paying for health benefits, some sort of portable retirement plan, etc. Otherwise you're giving up those items in return for zero commitment from the company. Not a good deal.


I would say it's comparable, at least in the way I treat a job.

If you work at an excellent company, you can learn much, much more than you do at an average job, and you'll likely make connections with better people. Working with excellent people at a job has many of the same benefits as studying with many excellent people at a university. It's one of the biggest reasons to go to an elite school, and one of the biggest reasons to work at a very selective job.

If it's a great company, I think it's worth giving up some of those things for the chance to work there. If you can show them that you're much better than average, they'd be stupid not to bring you on full time. It's mainly risky if you don't think you can demonstrate that.


I don't know if it's the same everywhere, but a 90-day "probationary" period is absolutely commonplace in the USA. Not sure I see much difference.


Virtually all employment in the US is at will, meaning you are continually on "probation". The difference between a contractor and an FT is that the contractor is 1099'd, pays both halves of FICA taxes, and isn't provided health insurance; more importantly, when the employer is as overt about the issue as "not hiring you full time", there's no implied social contract or norm ensuring you'll even end up getting the job.

Contractors make significantly more money than full time devs partly for this reason. They're compensated for shouldering the risk of keeping a full book of work. Getting a good developer to work as a contractor for what will eventually be their FT wage is almost kind of a scam.

This is a simple, practical issue. You're Sam, a developer with 5 years experience. You have a choice between two roughly equal jobs. One prospective employer offers you a full time job tomorrow; the other offers you a 3 month auditioning contract. Which offer do you pick?


Agreed, but most states as well as federal laws also prohibit discrimination, and companies of any size/sophistication have HR policies to be sure they avoid being vulnerable to discrimination lawsuits in todays litigious climate. Probably fairly safe to fire a 20 - 30 year old white male for "any reason" but firing a minority or female or older person has to be done more carefully, following all established policy. With an explicit 90 probationary period there is more freedom in that initial window of time.

Also if you work 40 hours a week at the employer's place of business, are provided with all the tools you need to work, are paid directly by the employer, and are told what hours to work and how to do the task, the IRS will consider you an employee. Maybe if its only for 90 days you can get away with calling the person a contractor, but I think you're walking a fine line.


That doesn't contradict what tptacek said, though. You may be an employee, though probationary, for 90 days, but the company should still compensate you at a higher rate for those 90 days to reflect the risk you're taking.


Try looking at it a different way - assume, you will have a full time job at either of these prospective employers. Do you want the one that makes FT offers immediately, or the one that makes them only after testing new people out for 3 months?


I want the one that makes FT offers, because I don't believe that the best programmers, who can write their own ticket in this business climate, would put up with this contracting bullshit. This approach to hiring is a cop-out. It says, "we don't know how to hire properly, so we're going to push the risk onto the candidates".


I've seen the contracts with my own eyes. But I guess I can't prove that the developers in question were good without divulging names.

Anyways, I don't see why this is a cop-out any more than any other hiring procedure. No company has anywhere near a 100% success rate - this procedure acknowledges the shortcomings of a traditional interview process (namely that succeeding on an interview and succeeding as a developer are two very different animals) and tries to address them.


> Anyways, I don't see why this is a cop-out any more than any other hiring procedure. No company has anywhere near a 100% success rate - this procedure acknowledges the shortcomings of a traditional interview process (namely that succeeding on an interview and succeeding as a developer are two very different animals) and tries to address them.

Agreed. But tptacek's point seem to be that this new process addresses the perceived weaknesses of traditional processes by moving all the downsides/risks to the potential employee. I think the hiring firm can signal their honorable intentions more clearly if they would pay a significantly higher salary during "probation" - something that compensates for lost benefits etc.

Edit: staunch mentions elsewhere on this thread that he is offering higher rates during probation.


I'd take the one that makes full-time offers immediately in a heartbeat, because I wouldn't trust the company that does the 3-month, no-benefits contracting "test".

Going to work for a company with employees of varying skill is no big deal; every company above a certain size has people who probably shouldn't have been hired. Going to work for a company with shady management, however, is a deal-breaker.


Exactly. I don't get what the big deal is about working with lower skilled programmers. At my job there are some fairly "bad" programmers, but even they are a pleasure to work with. The trick is simply to make sure you hire nice people. I've spent plenty of time getting them up to speed with various languages and techniques, and they're all very receptive. The trick is, you yourself have to leave ego at the door. I think this is the hard part for a lot of people.


My first programming job started with a two week contract which then ultimately became a FT position.

So I accepted a position like that and it worked out fine, but honestly, I will never do it again. I only accepted it in the first place because I was a desperate, inexperienced hire without any alternatives. Now I'm more skilled and have experience that demonstrates at least some ability. Accordingly, I don't need to take those kinds of risks.

Just because I'm good, maybe the boss's wife decides she doesn't like me or I lose some political blame-the-new-guy game, or they decide on entirely different qualities in a hire, or whatever. In this climate that sort of risk is their problem. I also won't do 10 hour programming 'tests' and I'm pretty reluctant to do several full-day programming interview marathon sessions. It sucks, I don't want to take the time off for that crap, and most importantly...

I don't have to.

This means there are places I can't work at, but there are plenty that would be glad to have me, and that suits me fine.


Contractors make significantly more money than full time devs partly for this reason

I've always heard that, yet when I look for contract work, it's always at equivalent or less than my hourly equivalent as a full-time dev. Full time was $100k - $115k/yr, contract was $40 - $50/hr, in the SF Bay Area.


Every contractor I know in the Bay charges more than this - more like 80-120 and up.


What technologies?


Rails and iOS provide most of my datapoints.


Thank you.


Then you're looking for contracts from the wrong kinds of companies; standard rates for most folks with a decent amount of experience start around $100/hr, more for short contracts, maybe a little less for longer ones or preferred repeat clients.


Again, I wonder what technology areas. Having looked, off and on, for C++ contract positions, I never see anything that high, in the SF area or elsewhere. Of course, my typical search involves Dice and Craigslist. Perhaps there's a better method of finding lucrative contracts.


As someone who has done this for 5+ years now (before that 10 years at various large / medium corps. and startups), I'd advise you that you won't find good opportunities via Dice and Craigslist. Nearly all of my contracts have come from references / networking (i.e. people I worked with once who hire me back as a consultant to build something / solve a problem). You're just looking in the wrong place.


So, general statements about how contractors should make approximately double their per-hour salaried rate only apply to people with a sufficiently established network of paying clients.

I don't know, I don't really consider it "normal" or "market rate" if there isn't an open market for it.

I appreciate your wisdom, though, don't get me wrong. It just makes me question the typical advice espoused by people.


Out here in SV it is almost unheard of; if someone is not working out after 90 or 180 or 365 days you drop them and move on. It is definitely a sellers market for talent here and anyone who is worthwhile enough to make an offer to is not going to put with an explicit probationary period (since everyone is a at-will employee and general non-competes are worthless the concept is pretty much a moot point anyway...)


The advantage of the contract with a specific project is two fold:

1) It makes it very easy for either party to end the relationship in a natural and simple way. Minimal hurt feelings/embarrassment/harm to morale, etc.

2) The project is at least semi-isolated so it's very clear how skilled the person is. They don't get lost in some "training" mode as a new hire spending 6 months "ramping up" on the primary codebase. They (hopefully) get an early win and earn respect and confidence from the beginning.


The obvious disadvantage is that if you do hire a really good developer for a short project, they will have to start looking for their next contract almost straight away, and so you are likely to miss out on converting them to full time. By the time you've figured out they're good at what they do, they have another offer (at contracting rates).


I've never seen that in the US. I should add that to our hiring agreements!

But I do agree with the other poster. Most high quality devs I know, worth their weight, won't sign on for that. Their view is that its a slap in the face from day one, and disrespect like that from management never gets better over time.


Talk to your lawyer. It may not necessarily be a win to add that clause. You have the ambient right to fire someone (in almost every locale in the US) with no reason whatsoever. Why qualify it?


Actually I was joking about adding. I have no plans to add such a thing. Our interview process has fortunately been solid enough that no one we've hired has been less than solid. And I think such a clause would backfire, since many of our best devs wouldn't have accepted on such conditions.


I've just started a new job, and I am on a 6 months probationary period, which apparently is standard for this company. It doesn't really phase me, I would be surprised if I was let go.

I haven't worked anywhere that didn't at least have a 3 month probation period.


Wow, you actually encounter people willing to take you up on #3 these days? They're either in love with your company or desperate for work.


Someone who opts-in to #3 is not necessarily desperate. In fact, to the contrary, they likely also want an opportunity to feel the company out and be more confident in their choice to stay/leave at the end of 3mo.


There's nothing preventing them from quitting after 3 months with a normal offer.


Depends on the contract. Over here (Finland) it's very common to have a three months "trial period", during which both the employer and employee are free to terminate the contract at (practically) any point and for any reason. However, after that three months, you need to give a one month advance notice to quit and firing someone becomes more complicated too.


Same here in Australia; I'm about to start a trial period of a few months with a single week's notice for termination from either side.

(Every job I've held has had this in some form or other. I'd wager it's common in countries with termination rules that aren't quite so, uh, "at will" as the US'.)


That "opportunity" is not worth having no company-provided health insurance, nor is it worth paying both halves of the FICA tax, except for the desperate.


Because it's impossible to pay someone at a higher hourly rate than they would be paid as a full-time employee?


It's not the easiest thing in the world to explain, no, which is why I bet most people who do the temp-to-perm thing don't bother, and just pay the contractor according to their yearly salary. After all, if they don't know enough not to take the term-to-perm offer, why complicate things? ;)


That may be. I have no interest in what other companies do, really.

I'm happy to pay higher hourly during the contract to compensate for the lack of benefits.

I'm happy to pay a (naive) employee more than they asked for because I know what the position is worth and have no interest in tricking them.

This isn't generosity, it's just good long-term business IMHO.


How about a W-2 contractor with benefits?


Agreed. It's an excellent way to make sure the only people you hire are desperate for any work.


Just filter out the latter and you're golden ;)


I once learned a shocking lesson about the influence of my preconceptions when I accidentally took a developer through three rounds of interviews because he previously worked for Pivotal Labs and had a German (aka technical) accent.

It wasn't until the third interview that I asked him to write an algorithm to sort an array and when he couldn't I suggested instead writing an algorithm to see whether the array was already sorted. When he couldn't do that either he told me I was asking the wrong questions and not letting him show off the code he was good at.

To this day I have wondered and never discovered what type of code doesn't involve arrays, loops and comparisons however I do now ask candidates to write code right at the start of the interview loop. I simply never anticipated how many non-programmers would apply for programming positions.


I haven't written code to sort an array in nearly two decades of professional experience:) I've been lucky enough to work on some pretty non-trivial problems as well. If you asked me to do it, I could probably crank out some sort of bubble-sort (maybe).

It's not to say I haven't sorted arrays, I certainly have, but whatever standard library I'm using almost always does it for me... and pretty damn well at the same time.


While it is largely based on the context of the job, I'd think some demonstration of fundamentals, like sorting (even if it's just bubble sort :-)), is important. It's another way to see which mental tools the candidate can use when debugging problems and they're forced to drill down through the layers of abstraction provided.


It seems fairly obvious that a pure tech interview doesn't screen for cultural fit, and that you need to have some form of behavioral/cultural assessment as part of the interview process.

Depending on how much time you have to interview (and I suggest you take the time if you're going to hire someone!) the "standard" dev interview can do pretty well at weeding out candidates who clearly lack basic skills. Joel Spolsky is a proponent of this and I agree.

I've found that passion is a great indicator of future success, and you can usually get a good quick read on whether they are serious about software development by asking people about their favorite projects, what they spend their time working on, and what interesting things they see happening in the field.


I once decided to skip the standard programming problem during the interview process, and I ended up regretting it extremely. The person we hired was nice, and a good "culture" fit, but couldn't code for beans. We had to let them go and I felt pretty bad about it.

Programming questions certainly aren't the be all and end all, but as a filter they are useful.


Programming questions seem also useful for companies trying to make a good impression on the candidates. I find that companies with really interesting technical questions are more likely to spark my interest than companies whose hardest question is "How would you reverse a string in Java?"


I never really understood why companies don't just take a non-trivial real problem that they have run into during development. Just ask the candidate to talk it out, see if they are able to at least get on their feet toward a solution or an idea of possible solutions.

I've never hired anyone, but I can tell you that I could write a linked list in a handful of languages. I can also tell you that it doesn't say much about what I know (or perhaps more importantly, don't). Problem solving is what is important, more important than ability to write code on a whiteboard.


Definitely agree with this post. I've been interviewing for the last couple months and one of the better/more fair interviews I've had involved a nice back and forth (mostly the types of questions posed in the article, including a lot of stuff about my outside projects).

Then they brought me in for a tech interview where they plunked me down in front of a computer to architect a small application for a type of problem I might encounter on the job. I thought it was fair and it probably gave them reasonable insight into how I code/think/present my solutions.

I've had a lot of "write a linked list" style and they're draining. The quality of the applicant being pulled in to do CS trivia is going to be all over the place since that type of an interview can be gamed fairly easy if someone has a desire to do so.


I was very impressed when an employer used an open notes, take home exam in the second interview. Initially, they had tried a written, proctored exam during the first interview.

Although I was the only candidate among many who did not claim any experience in the actual technologies listed in the position, I was also the only candidate who turned in the take home exam. I also completed my working code in 8 hrs rather than the week time limit. The others all quit the exam at various stages because they did not possess the tenacity to hunt down technical knowledge online required to implement the proof of concept software. At the third interview, they asked me how I came to my solution and why I chose certain methods in order to validate that I completed the work myself.

This seemed like an great alternative to other exam experiences I'd had. At another interview, a non-technical company officer asked me a technical question and then couldn't explain it. The question was so opaque that it took thirty minutes of probing and badgering him to even understand the question. By this point, I was ready to write them off and leave. They lost their largest customer the next week and I would've been laid off if I'd joined them.


Writing code is just another type of conversation. Sure, you're going to ask many questions. Having a candidate code a bit in front of you, going back and forth, provides a lot of info.

As far as "CS puzzles" - binary search, trees, linked lists, hashtables, etc: None of those should be puzzles. If you're giving interviews that people can "memorize" an answer to, then the problem is how you're doing the interview. A proper conversation, including code, will quickly sort out if the person just memorized a one-line Haskell quicksort, or actually knows what they're talking about.


Do you actually find people that expect candidates to implement quicksort?

I've certainly implemented it, but there's no way I have it memorized, it's not an obvious algorithm at all. I'd be flabbergasted to be asked to implement it from memory with no warning. It seems clear to me that one would be testing for if the person happened to have looked at the algorithm recently, not if they were competent.


It's not such an arcane algorithm. Choose a pivot element, (say) p. Rearrange the array into left_sub_array + [p] + right_sub_array such that all elements of left_sub_array are no greater than p, and all elements of right_sub_array are greater than p. Then recursively sort the left and right sub-arrays.

If you don't remember this, it's OK. If I was the interviewer I'd still give you the description above and see if you could implement it. Most candidates cannot.


In college ("computer science part A",using Haskell) we played out the various sorting algorithms we learned in class, with students holding up a number (to determine sorting order). Neat to actually experiencing the slowness of bubblesort vs. mergesort/quicksort ;) We repeated the performance in front of a local mall - I can't recommend trying something like that in a crowded place from that experience.

I think expecting recent CS graduates to implement a basic sorting algorithm or binary search, etc. (say, in a garbage collected language they know well) is reasonable, for people with actual work experience I think it makes less sense and the focus should be on more recent experience if relevant to the job.


Yeah doing a binary search in an array is pretty standard. What I was asking though is quicksort since that was mentioned. It's not obvious by any means how it works and I recall that early reference implementations had bugs that were unknown for years even though widely used. It really sounds to me like asking someone to implement the FFT in an interview. What are you really testing for when you do that?


As long as you don't want to do it in-place, it's actually very easy to code.


I used quicksort as an example of something that one could conceivably memorize in Haskell (only 80 chars) with no clue to the functionality.

I was referring to any sort of "memorization" - just talking and watching someone code should make it clear if they just recently read an article about an algorithm, or if they actually understand it.


Bit offtopic but that CSS made reading the article a complete pleasure. With the mixture of nice readability and interesting content this post turns out as a really good essay.


I have to disagree about the uselessness of a technical interview. I'm 100% with RethinkDB that any competent programmer should be able to figure out how to reverse a singly-linked list in some reasonable time. (http://www.rethinkdb.com/blog/2010/06/will-the-real-programm...).

" Some were shooting their pre-canned answers at me with unreasonable speed."

This should not be possible for all questions in a technical interview. Especially if you are a startup, you can use your own original problems, especially ones you've actually had to solve. Aim for actual coding questions though rather than too puzzling ones that are often just memorized (implement quicksort, detect cycle in linked list in O(1) space, the random puzzles companies love to ask).

Of the people I've worked with, there is a high correlation to job performance to performance in a tech interview. (which for new grads is strongly correlated to their college CS grades).

Of course, passion is also a decent indicator, but it is highly correlated with raw competance. That said, I wouldn't hire anyone lacking either.

Disclaimer: I'm coming from the background of a systems company. For those making CRUD apps, tough coding questions might be less relevant.


Usaar333 - Here’s some food for thought:

There is a difference between -capable- and -willing-. Years ago I hired a brilliant developer that didn’t do anything because the work was below him.

A good interview should determine culture, willingness, and competence. If your dev-group works with b-trees daily, then include it in the test. For me, hiring someone who knows the answer is less important than hiring someone who can find the answer. In a dynamic - always changing environment - I would rather hire the latter.


> I have to disagree about the uselessness of a technical interview. I'm 100% with RethinkDB that any competent programmer should be able to figure out how to reverse a singly-linked list in some reasonable time. (http://www.rethinkdb.com/blog/2010/06/will-the-real-programm...).

I had the initial phone interview with RethinkDB and they were asking me questions about what is a B tree and how to use them to implement a filesystem/database, what is the pros and cons of structure A vs. structure B, etc.

I understand wanting the best of the best, people who have implemented filesystems before, etc., but I think it's pretty unrealistic to expect someone three years out of college who has not been working in the same area of specialization to just know this stuff off the top of his head.

Wouldn't it be much more realistic to basically give someone the Wikipedia entry for various data structures, tell them something about the data and workflows, and then ask which structure(s) they would use and why?

After that interview, I was sure I wasn't getting the job, but I wasn't very upset. They seemed to have unreasonably high expectations, and that's not exactly the most healthy work environment.


Why not just pair with the interviewee for half a day or a day? You will learn how they think and work and if you like them. It's a riddle to me. I've never heard from anyone actually trying it and not being happy with the insight won.


I'm a lot more interested in how someone breaks down an architectural problem than I am in how well they can implement heap sort on a whiteboard. The closer the interview is to real coding the more you learn.

Of course, github is the real resume now.


Why not pair on whatever you would be working on anyway. I usually have to solve many architectural problems every day but honestly never had to implement a heap sort all my life. So there should be ample opportunity for an interviewee to show his architecture-fu


I think it's got to be more than just github for the resume. There are tons of other open sources of data. Personal blogs, twitter feeds, even things like delicious links can be indicative of what a potential candidate is thinking.

My new startup is focusing on doing exactly this --- bringing together as many sources about engineers together as possible, and putting them all in one place. It's still very early, but I'd love HN's feedback. http://proovn.com


Because with a large codebase, you're not going to be particularly productive on the first day? I mean, it's better for web projects with a framework and set of conventions, but for, say, sizeable C++ applications it can be a serious hurdle.


I get a really good insight in the candidate's programming skills by pair-programming a simple problem with them. For TDD, I write a test and ask him / her to write the code to make it pass (then repeat, refactor). That way, I can see how fluent they are in the programming language, at the same time evaluate their problem solving skills and see how they work in a team.


I have had that happen to me a few times.

They used vim and textmate. As an emacsian that didn't have any firm understanding of those editors, it was .. frustrating. Lots of times with 'oops, what did I do now?'.


It seems that one simple thing you could ask is for usernames or profiles on sites like StackOverflow or other programming related websites to see what kinds of contributions or questions they've been asking.


I think websites like Stack Overflow, GitHub and HackerNews attract a certain type of programmer, which might not always be the sort of person a business is looking for. Or, at least, it will exclude a lot of people who aren't interested in being involved with online development communities. That is, they are too hardcore.


Yes, but there are tons of other data sources out there, right? For example, how many developers are members of mailing lists for a given API, service, language, tool, etc.? How many contribute? Plus, that doesn't even include the world of personal blogs, twitter accounts, etc.

I think we're entering an age for software engineers where expressing yourself externally is going to be even more important than your resume. For example, a really intelligent, well-thought-out post like the one linked above can really move you forward in your career.

I'm focusing on making a startup that captures all this stuff and uses it for both display and matching candidates. I'm still in the very early stages and would love some feedback! http://proovn.com


When I hire a developer, I ask him about the scene in 'The Social Network' with the Winklevoss twins, and ask if he knew Armie Hammer's face was CG'ed to another actors body.

Depending on his answer, I know right there whether to end the phone interview, or fly him to the Valley so I can see him write code on a whiteboard.


I guarantee with that hiring process, that you will not want to work with me. Given your interview process, the feeling is likely to be mutual.

(I don't watch TV or most movies, haven't seen The Social Network, and have no interest in doing so. If that is what you value, then I'm going to be a poor fit from both sides.)


I think he was making a joke about a submission here a day or two ago...


WTF has a CG'd face got to do with anything? Seriously, I'd like to know (I've never seen that film either).


I'm pretty sure he's making a joke about this other article that got submitted: http://news.ycombinator.com/item?id=2384499

in which someone mentions that they use people's opinions about whether or not they side with the Winklevoss twins in the movie as to whether or not they would be a good co-founder.

I actually thought this comment was pretty funny, but if you didn't read the earlier article, it probably doesn't make any sense.


You got it, dude.


Fwiw, my current screening is: first resume screening, then I send candidates a simple programming exercise that sort of is in our domain. I can assess the delivered work in around five to ten minutes, so it scales well. Then a further skills/team fit check through interviews, and for those who survive that, the expensive bit: pairing with developers on actual production code.

Especially the exercise works as a good screen. We get quite a number of "deafening silence" responses, which says something about the candidate's motivation. We also get responses where people try to show off alternative language skills but deliver something totally non-idiomatic. And we get good submissions, showing some patterns knowledge, unit testing, at cetera. These typically end up being hired.


Knowing all about data structures and other computer science implementation-related stuff means exactly nothing if a person can't think creatively enough about how to approach a real-world problem to begin with. Those data structure CS questions are down in the weeds and you haven't even figured out if the person can get down to the weeds if you're asking those sort of questions in a first-round interview.

I mean think about it: do you approach programming tasks top-down or bottom-up, usually?

Critical thinking is the most important skill IMO, and it can only be tested by giving someone open-ended questions on how they would approach real-world assignments, preferably in a low-pressure take-home test kind of thing - again IMO...


Totally agreed. As a team lead I've hired my best talent with interviews like this.


I couldn't agree more with the sentiments of this post. Apart from anything else 'software developers' vary massively in their core strengths and job positions require different strengths in the candidates. Skill in developing algorithms and solving puzzles on the fly is just one of those strengths. There are so many more in terms of software engineering practices, knowledge of programming patterns, awareness of different programming paradigms, ability to solve higher level problems / combine technologies effectively to solve a business problem rather than a low level programming problem etc.


My last interview process was intense:

1. A write-a-document test. I was given a fairly simple (contrived) scenario over the phone and was asked to write specs and a deployment plan with a deadline of an hour.

2. A programming test. Again, a description given over the phone and someone available to answer questions if I had them. After delivery, there was a followup programming task to extend it from a client app to a web app. It took about 8 hours in total.

Provided you're willing to put in the time (and I was), it seemed to be an excellent way of judging whether I could really do the work they needed me to.


I hope they made sure to get you to sign a copyright transfer for the work.


Hi there! Good article, I've seen similar situation in several companies too.

Few words about one startup-like company(based in Kiev, Ukraine) I have been working for 1 year as developer. It was focusing on .NET Enterprise apps. Their interview approach: - 1st day: tech-interview via phone(0.5-1hr); - 2nd day: (companies office) simple technical tests(choose-right-answer on paper), short technical interview(technology basics, fizz-buzz tasks, sql-tasks, usually join/group-by, having-based), coding-task on laptop(the most significant and essential(for evaluating developer) part of whole interviewing process write application for calculating bowling scores, Console app or GUI application - no matter, for candidates choice, time-bounds - for candidates choice; rules were provided and explained to each candidate + full access to internet resources + possibility to ask interviewer == real working environment); - 3rd day: final technical interview(patterns, OOP, code-design, etc.), general interview with CEO;

When I came to it, there were 3 devs(including me). The next(after me) developer were hired after ~60 interviewed fellows. Yeah, the total interview time is tend to be long and hard, as for candidate such as for company, BUT in such way were established the best TEAM I had honor to work in.

Thanks for attention:) Cheers Aleksey


"we ended up hiring the candidate with the smoothest answers"

I mentioned this in another thread, but the point of coding questions is to see how they think about code, whether they understand how to walk through it (have a machine model), if they can pick out and evaluate edge cases, and how they can work with hints from you on how to improve their answer. Hiring based on ability to answer a particular problem is probably only a slightly better indicator of ultimate job success than height.


Having only recently read Peopleware 2nd Ed., I've been mulling over the audition concept in the "Hiring A Juggler" chapter - effectively having a developer present on a project they worked on, what they contributed and learned and so forth.

It seems like it would have value - allow the candidate to prepare and present on a topic they're strong on, and in-depth enough to allow cross-examination.

Has anyone any experience of this from either side?


Great article! For 15 years I have conducted interviews and been the victim of the interview process. Your article sounds familiar; I have been telling my wife the same thing (out of frustration) for years. On several occasions I have made it through 3 or 4 levels of the interview process and then blocked in the final interview-step by an insecure or egotistical technical person.

I would add the following (problem) points as well.

* Some technical people like to hire clones of themselves, creating conflict and diversity issues.

* Some technical people, conducting the interview, use the interview process to posture and show how smart they (the interviewer) are.

* According to the BLS, the demand for programmers is decreasing while demand for analysts is increasing. Programming has changed a lot with tools like intellisense and included libraries.

* If you can’t answer the question, "why did you ask that question?", you should not ask the question. Each interview question should have a specific targeted purpose.

I hope my additions help. http://www.linkedin.com/pub/michael-pritchard/3/93b/4ba


Also:

* Realize that answers to questions like "what is abstraction" might vary from one text book to the next.

* Establish context for your interview questions. I was once asked "What is Application?" (too vague). In response I said, "In what context?" The interviewer smugly said, "What comes to mind?" . . . He did not like my answer. Hum?


As a former head of HR for three successful start-ups and now as the founder of my own, I (in the words of our former president) feel your pain. I've reviewed 10's of thousands of resumes and interviewed over 1,000 candidates so I know what you're going through.

Your points are well taken and insightful - and while they're especially true of technical hiring, they are also applicable for all start-up hiring. A smart person can learn the tech skills you need but it is impossible to impart passion and an intuitive understanding of culture where it isn't already present.

I eventually honed my interviews down to one question: "Please describe your most significant team accomplishment, where you were a key member of the team."

Then I'd follow that with numerous follow up questions until I really understood the person's role. This will uncover the candidate's passions, communications skills, leadership abilities, and their technical prowess. Then I'd ask the same question about another accomplishment.

Good luck. I'll write you a note on the side with my contact info. I'd be happy to talk over any "people stuff" if you'd like.


Couldn't agree more.

The focus that the short sighted interviewers and companies have on how fast your can solve some pointless algorithm that a CS has figured out 30 years ago, vs how you get on with the team I find mind boggling.

http://www.jeremyhutchings.com/2010/11/interviewing-dating-f...


The problem with "tell me about your projects" is that it doesn't distinguish good programmers from bad. It isn't even gaming. A programmer who makes a negative net contribution to a large project may sincerely feel he is responsible for its success. All you can pick up on is their perception.

At least when you ask them to write code, you can tell if they got it right or wrong.


You can actually learn a lot from a candidate's past projects if you know how to follow up with the right questions. Someone who had a negative net contribution on a project will not have anything interesting to say about the data structures or algorithms they used. They won't have interesting war stories to share either (e.g. nasty bug fix, conflict with management or team and how they overcame it, etc.).


In the last year I've been on interviews like this, where I've been presented with sorting problems or quirky pointer arithmetic conundrums. However, these bear no relation at all to the kinds of practical software problems which I've had to tackle in business or industrial contexts in the previous decade or more.


That might be a good thing. It shows how you think in new situations, how you can problem solve, and how you deal with complexity. I used to give "reverse a linked list," and it's essentially a book keeping problem: you're changing links around the time you're trying to read them, so you need to keep all that straight. If there's a bug in their code, you can see the thought process they go through to find and fix it.

Unless the job they're interviewing for is almost exactly the same as their current job, it's important to understand how they think through new situations.


A very candid self-analysis. Thank you.


>But how did the candidates we selected measure up? The truth is, we got very mixed results. Many of them were average, very few were excellent, and some were absolutely awful fits for their positions. So at best, the interview had no actual effect on the quality of people we were selecting, and I'm afraid that at worst, we may have skewed the scale in favor of the bad ones.

This doesn't follow at all! Consider, as is surely the case, that only a small fraction of the applicants would have turned out to be average to excellent. The interview process can filter out the vast majority of the sub-average applicants and still leave you with a significant fraction of sub-average employees.


I just had a thought: How about having a phone round first, and ask all applicants to provide a sample of their coding skills, like suggested in the article. Then, in the second round you leave each applicant for a couple of minutes to analyze the code from someone else and find out what it does and what's so special about it.

That way your work of looking into the code samples will be minimized. Even better, you'll get an idea of how well a coworker with a similar skillset can cope with that code. You can also judge how well people are at dealing with code from their coworkers and don't have to come up with examples yourself.

It does sound pretty good, no?


I think interviewing altogether is an ineffective way of evaluating people. And the whole process of interviewing and hiring staff members is an outdated, slow bureaucratic way of doing things.

Instead why not work with several people on small projects, ask 5 people to do 2-4 weeks of paid contract work for you and then select the person who was the best fit for longer term work. This tests the real world skills of a person much more effectively than an interview.


s/'Me and my cofounder'/'My cofounder and I'

But it was a really good article besides that! Sorry for being a grammar german.


Their smart quotes are ”wrong“.


❜❜Nice, but that doesn't work for large, successful companies. Your idea doesn't scale.❛❛


This is a great read. Exactly how I have approached hiring developers.


What does 'I only went "full Trump" once on an employee.' mean?


I'm assuming it means outright firing someone.


Yes, it does. Sorry, it's a bad allusion to an even worse reality TV show.

What it means is that letting people go happens. Usually, when people were underperforming or showing other signs of problems, I just talked with them to clear up what the matter was. Sometimes, they had personal problems, or other temporary and resolvable issues. Sometimes, they were unhappy and needed to be somewhere else.

I remember one guy, an intern with horrible attitude, who said to me in confidence: "I regret this so much. I always wanted to become a baker, but my parents wanted me to have a real job." I kid you not!

The point is, it has been my experience that even layoffs can be borderline mutual. But this once, the latest screw-up in a long line of screw-ups... it was so monumental and malicious even. Worst of all was I felt kind of powerless, having this adversarial force on my team. Like a Trojan horse that wasn't even making an effort to disguise itself. I fired the guy on the spot. Of course, you can't do that in Germany, so eventually I paid through the nose for it following the lawsuit. But in that split second it was worth it just to have this guy off the floor immediately.


Thank you for posting this! This really resonated with me.


Very lucid and reasoned argument that you make. I intend to blog about it, and my forthcoming experience of using it on my blog at: carphill.blogspot.com


Not sure I agree with the alternative, but besides that, I think the nail was hit directly on the head.


Hello Mr. Schroeter,

I have enjoyed your post on DZone (http://www.dzone.com/links/r/hiring_developers_youre_doing_i...) and have decided to let you know about it. This topic of 'interviewing the right candidate' has always intrigued me. I have always wondered if the superstars amongst the technology-driven companies have devised a surefire method to pick the right candidate from thousands! In my experience, the decision to go for a candidate or not, is very subjective as you have mentioned. At a certain point in time during the interview, one listens to a inner voice and decides between 'Yeah!' or 'Nah!' and not always that decision is based on pure facts: precise answers to precise questions. But, to know the personality of a programmer - through some questions and possible answers in an hour's conversation - is a difficult task. You have not mentioned if you had cracked it finally in your star-up or your later efforts/engagements. I will be keen to know.

I am based in India currently. Here, because of the business success of the IT Service companies, most of the companies try to follow their business model. However, about 95% of the work that these companies take up are low-tech, mostly repetitive and disincentivize breakthrough technical work. Their need for good programmers is not much; they are content to see that the client is that much happy to keep the projects continuing: that is the main objective. Moreover, you seem to say that 'scaling' is not an insurmountable problem. It probably is, if you see that the Indian IT service companies cite hiring figures in tens of thousands in an year. So, the interview process that these companies stick to, aims to find out how much is the probability that the candidate is going to prove himself a misfit. Subjective, as usual; for a good measure, the companies take in people in huge numbers simply hoping that the probability of a 'good fit' increases. For a bit more experienced people, it is almost always aimed to find out if the candidate can 'manage' a team, and certainly not whether the candidate understands the world of programming at all.

I work as a freelancer and in India, that doesn't help me. I claim to know and understand what it takes to 'design' and 'develop' a good piece of software. More than that, I carry a certain amount of intensity about the whole act of programming and usefulness of well-written programs, even at this advanced age. However, that doesn't interest most of the potential employers because a good programmer - who knows some but is eager to work in a team where people know more than he does - is not valued as much. Importantly, it requires a keen pair of eyes to spot these qualities and that is largely missing.

Recently, situation here has made me so despondent that I have begun to look for opportunities outside India, Europe in particular (I have stayed and worked there before, hence the bias). I am hoping that there will be some people out there who will take some interest in not only what I know and have done, but how fast I can know more and can do if I join them. I am looking for those keen pair of eyes. Agreed that there are those issues of geographical distance and visa papers etc., but if someone finds me suitable, s/he may want to go that extra mile.

If you have read till this point, thanks for your patience. I read your post at a moment when I was in despair and wanted to demonstrate that your post chimed with me.

Warm regards

-- Nirmalya (sengupta.nirmalya@gmail.com)

-- Software Technologist http://www.linkedin.com/in/nirmalyasengupta


Well stated and pretty much spot on, with one exception...

The notion about "Programmers who are good program all the time, even in their spare time."

It has been my personal observation that this period of "Programming is the only thing worth doing with your life" (And yes, I know I am paraphrasing this in an unkind interpretation of what you said, I'm not doing it to be mean though, I'm doing it to illustrate a point) is true, for the first 5 to 7 or 8 years of a programmer's career. The reason seems to be that the deep fascination with what makes programming interesting as a career, continues to hold them even in the evening hours when they are at home. When not actually programming, they talk about programming, or programming problems or some aspect of computers and computing technology, when they can find friends to talk about it with, that is.

However, the basic drive behind this seems to be finding out as much as you can possibly find out about your chosen field or niche within the field. After that time period, though, something interesting happens. The MYSTERY of it all, starts to fade. You begin to see patterns in how things work, and similarities in how things are done, or are implemented, or can be implemented. Other interests start to take hold and after a while, family life starts to become important as well. At least, for a well balanced human, it does.

And that, I think, becomes my major point. The kinds of programmers who live eat breathe and drink programming, non stop, past this time period, are RARE, and usually are not well socially adjusted.

This is something that I think is not accounted for when interviewing more experienced software engineers. When looking at the scads of job openings for folks with 3 to 5 years of experience, your methodology and assumptions should work well, however, when you are looking for that really senior guy or gal who has been doing this for over 20 years, then the methodology, in my opinion, will not yield to you the best results. ie. teasing out the best candidate from the stack.

As an aside, I once told this to a young friend of mine who I met in college. I had already been programming for nearly ten years when I returned to school to get my bachelors in CompSci. I was always fascinated with just HOW MUCH he would go on and gush about computers, tech, sun workstations, sgi's, their hardware, their software, how to program them, linux and unix tricks etc etc.. One day I smiled and said to him. "I'll give you 5 to 7 years, and this utter all consuming fascination with computers will tone down to seeing them as nothing more than tools." He denied it, vehemently, he would NEVER have computers be something so mundane! It was, about 7 years later that I got an email from him where he told me "You were right." He's a googler now, and was one of the lucky ones who was in early, pre ipo and can now retire if he wants to. I myself tried getting into google, but made some mistakes in the interview process, trying to be 'clever'. It backfired, but that's okay. And not once did they ever ask me anything about what it is I do, or what I do best, or what I was interviewing for, board bring up, device drivers and kernel porting. Things which I'm very good at and have done for over 25 years.

Anyways, just my .02, your mileage may vary!

Sincerely, Richard Dorfner


I always find the emphasis put on algorithms 99.9% of developers will probably never have to implement after the interview totally astonishing.


Too bad this site's domain name wasn't issued by the Iceland TLD registry.


What's your point? You realize it's an anonymous publishing service that, although being awesome, has nothing to do with the article at hand?


No humor on HN allowed!


I am getting down votes for this?! WTF? Look at the domain name and understand the original post, before downvoting! Think and then act!


I haven't downvoted you, and usually don't reply to posts like this, but I think that making posts to complain about getting downvoted is just encouraging it.


Yeah, keep downvoting me and don't even have the curtesy to write a comment as to why!


You're being downvoted because you broke two explicit guidelines (the last two here: http://ycombinator.com/newsguidelines.html - you should probably read these as a linked list, not an array) as well as an informal one, that this community frowns on superficial one-liners. It's not that people here hate humour, it's that they're sensitive to how other online communities deteriorated once such comments became the norm. They are like weeds that spread rapidly and choke out the flowers and vegetables. A few weeds are ok, amusing even, but they don't make for a satisfying crop.

The weeds are one problem (users here do a pretty good job of rooting them out); a harder one is the crops themselves getting more mediocre.


Disclaimer: I'm not downvoting you but I believe you are being downvoted because people thought the original joke was offtopic and not all that funny. I mean, are you seriously defending the honor of a penis joke here? Don't take it personally. I know it's hard sometimes... (almost no pun intended)


[dead]


  Domain Name: monster-beatss.com

   Registrant Contact:
   wong
   wong wong 114174559@qq.com
   +86.01083839489  fax: +86.01083839848
   Beijing
   Beijing Beijing 101100
   CN

   Administrative Contact:
   wong
   wong wong 114174559@qq.com
   +86.01083839489  fax: +86.01083839848
   Beijing
   Beijing Beijing 101100
   CN

   Technical Contact:
   wong
   wong wong 114174559@qq.com
   +86.01083839489  fax: +86.01083839848
   Beijing
   Beijing Beijing 101100
   CN

   Billing Contact:
   wong
   wong wong 114174559@qq.com
   +86.01083839489  fax: +86.01083839848
   Beijing
   Beijing Beijing 101100
   CN

Domain Name: ghd-midnight-uk.com

   Registrant Contact:
   Tony Wong
   Tony Wong 506169530@qq.com
   +86.01038098999  fax: +86.01038098888
   Beijing
   Beijin Beijing 101100
   CN

   Administrative Contact:
   Tony Wong
   Tony Wong 506169530@qq.com
   +86.01038098999  fax: +86.01038098888
   Beijing
   Beijin Beijing 101100
   CN

   Technical Contact:
   Tony Wong
   Tony Wong 506169530@qq.com
   +86.01038098999  fax: +86.01038098888
   Beijing
   Beijin Beijing 101100
   CN

   Billing Contact:
   Tony Wong
   Tony Wong 506169530@qq.com
   +86.01038098999  fax: +86.01038098888
   Beijing
   Beijin Beijing 101100
   CN




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: