More Than Coding

Because machines still need humans

5 signs that you should hire a programmer on the spot

Bringing a programmer in for an interview and a coding test can lead to some interesting experiences, both for the interviewer and the interviewee. Most end up with the hiring manager telling them that they’ll “be in touch,” but sometimes a candidate just nails it. That’s when you consider extending a job offer before they get a chance to leave the building.

At TimeTrade we run a coding test during interviews that, for the majority of programmers, should take about 2 hours in total to complete. The whole test is comprised of a number of small problems to solve, each harder than the one before. That gives us a good initial gauge of performance based purely on completion time: if everything has been solved in under an hour, we’ll be smiling. But if two hours pass and even the first problem still hasn’t been solved, the candidate will most likely just be shown the door.

Above and beyond just solving test problems quickly, here are some signs that a programmer is truly awesome and should be handed a job offer before they leave your building:

1. They present multiple solutions

I recently interviewed a programmer who solved an entire set of tests twice: once with iterative solutions, and again recursively. I quickly made him an offer. Finding multiple solutions to a problem is a skill that engineers will need to use every day.

2. They write full documentation

Last year I interviewed someone who was so diligent, so detailed and so professional about his work that he created full Javadoc and comments for his code before he considered the solution complete. He even wrote fully automated unit tests and checked their coverage percentage. When I came back into the room at the 2-hour mark and found him typing furiously I initially thought he was having trouble with the test, but he was actually in the process of adding HTML formatting to his Javadoc. Engineers who do this intuitively are the kind you’ll want on your team.

3. They improve the test

We deliberately create tests that have some minor issues lurking within them, purely to see if the candidate (a) spots them and (b) is willing to fix them. It might be an inconsistent usage of quotation marks for strings, misleading variable names or anything along those lines. Candidates that look at all of the provided code as the test — not just the pieces we’ve asked them to write — are the ones who will do the same in our real product once they join our team.

An engineer who is willing to tell a potential employer that the supplied test contains problems shows that they consider the quality of their work to be more important than just agreeing to do what they’re told. Hire them and they’ll likely work wonders for your product, going above and beyond their assigned areas to make improvements where they are needed.

4. They refactor smartly

Most candidates like to get a solution working, then sit back and breathe a sigh of relief that they finished it successfully. That’s good, but rarely good enough to justify an on-the-spot job offer. The candidates that solve the problem but then jump right back in to refactor it are in a different category entirely. Their choice of algorithm doesn’t feel right, and they can’t ignore the feeling that it could be more efficient. Their code has some duplication in it, and that burns them up inside. These are the candidates who refactor, rewrite and improve their solution until it’s been crafted.

This can be a double-edged sword, though. If the candidate just keeps rewriting because they’re not happy until they reach a mythical point of “perfection”, there’s a chance they are one of those programmers who doesn’t know when to stop (and similarly, ship). However if they watch the clock carefully and are able to both solve the problem and refactor their solution before their time runs out, that’s a really good sign that you should consider an offer.

5. All other signs point to “hire”

Sometimes there are plenty of non-technical signs that you’ve found the right candidate. Your other team members take you aside and tell you, “We have to hire this lady.” Their personality feels like a great fit for the team. They have relevant and recent experience in what they’ll need to do. You know some people who have worked with them before and they tell you they are wonderful to have on a team (and that they’d hire them again in a second). The candidate is excited about the company and the opportunity and is hungry to start contributing.

If the candidate passes technical muster and all other signs point to “hire,” why wait? If you do, you may lose the candidate to another employer who knows how to read the same signs faster than you can. Instead, be decisive and make the offer fast, thereby telling the candidate how much the company wants them on board. It will help start the whole relationship off on the right foot, for both parties.

So the next time you’ve got a wonderful candidate in your building, don’t assume someone even better will arrive the next day. Make them an offer and get yourself – and the candidate – back to work.

This blog entry has since been translated into Spanish (by Maria Ramos/Web Hosting Hub) and French (by Hinault Romaric/Developpez.com).

About these ads

127 responses to “5 signs that you should hire a programmer on the spot

  1. Joel May 1, 2012 at 12:41 pm

    What kind of coding test do you guys give? I’d like to see if I can do a quality job in 2 hours.

    • Brian May 1, 2012 at 3:15 pm

      Send us your resume and we might bring you in to do so :)

      • Joel May 1, 2012 at 7:42 pm

        Sounds tempting, but I’m in deep south Texas and Massachusetts is too far. :)
        Maybe just a hint of what the test consists of? Is the test geared towards algorithms or actual code design?

      • Chris May 1, 2012 at 8:37 pm

        I’d also love to take a peak not because I’m looking for an offer but because your test has me really curious. I’d love to see any of it you’re willing to share.

      • Yev May 1, 2012 at 9:14 pm

        Perhaps posting some question analogous to those on the “test” might be a good idea! It will attract the attention of the people you want, discourage the people you don’t, and gain you and TimeTrade some valuable mind share in the software development community.

      • Brian May 1, 2012 at 9:59 pm

        We tailor the tests to the position for which we’re hiring, because a one-size-fits-all test wouldn’t tell us much. If it’s a web developer position, it’s going to involve adding new features to an existing web app (and require knowledge of HTML5, CSS3, AJAX, jQuery, PHP, etc). If the position is focused more on server-side stuff then the problem will likely touch on multithreading, scalability, architecture, implementation patterns, etc.

        One thing I didn’t make clear in the article above is that we bring engineers in to interview only after they’ve passed a technical phone screen. That’s where we cover CS basics like algorithm complexity and data structures, and then have them code online to solve the usual quickie problems that should take 5-10 minutes each to code up. The phone screen is a pretty effective filter, and you wouldn’t believe how many people self-select out of the process once they’re asked to actually prove they can code.

        The interview itself is as close to a simulation as we can get of what the work environment would be for them, should they be hired. We’re looking to find out if they can operate effectively in our environment and within our organization’s culture. In the few hours that interviews typically provide, we’ve found it to be a pretty good mechanism for hiring the right people.

    • Jenny May 8, 2012 at 10:39 am

      I can provide you a copy of the test, I was so diligent, detailed and professional that I did everything twice.

      You can contact me at jenny_b@msn.com

  2. Per Dervall May 1, 2012 at 1:07 pm

    I’ve done a lot of these sort of code tests and while your points are good, I’d add another. Always ask the prospective new code what blogs they follow and if they start to elaborate enthusiastically it’s a really good sign that they actually care about their craft.

    I like your first point especially, though it really depends on what sort of questions you pose and how difficult they are.

    • Chris May 2, 2012 at 11:43 am

      I hate those types of questions. Do you really want some code monkey who lives to code? While those guys are usually awesome coders, coding is only part the job. The other half involves understanding and appreciating the business as well as interacting with the non-technical people who generate the revenue in most companies.

      We don’t hire code monkeys at our firm as we really need people who can work with the business. If I need a code monkey for his ninja skills, I will call in a consultant for a few weeks and then show him the door when the project is done.

      • William May 2, 2012 at 11:52 am

        I agree with your comment.

      • Joe May 2, 2012 at 12:15 pm

        Totally agree here

      • Keith May 2, 2012 at 12:31 pm

        “If I need a code monkey for his ninja skills, I will call in a consultant for a few weeks….” Teams definitely needs skills balance to be healthy, but candidly, I believe that your philosophy here means you’ll _never_ have a world-class team, or even have a realistic hope of working towards one. Superstars advance the state of everyone’s art, when their skills are leveraged appropriately.

      • Per Dervall May 2, 2012 at 3:05 pm

        Being in tune with the community is so much more than coding. If you are following blogs it usually means you also are keeping up with methodology, best practices, recruiting and requirement analysis. All of which aren’t about code but vital in understanding what actually makes both software and users tick. All blogs aren’t about ninja hardcore coding tech.

    • Keith May 2, 2012 at 12:26 pm

      “Always ask the prospective new code what blogs they follow….” I agree. I use a similar question that’s a little broader, “What do you read?” The answer says a lot about how well the candidate stays abreast of new technologies, and in what areas they’ve been working to advance the state of their skillset. It’s even more telling when they can’t answer the question right away. ;)

  3. rib May 1, 2012 at 2:09 pm

    As a potential customer, this gives me more confidence in your company — you guys have a great product and obviously a great culture of excellence

  4. Jonathan Howard May 1, 2012 at 2:23 pm

    I’m curious as to the contents of your interview questions as well. Especially since it doesn’t sound like someone’s in the room with these candidates, hearing their thought process, solving hard problems together, or traditional white-boarding techniques.

    Have you thought about this in-person factor? Did you intentionally trade that for another benefit (like ability to screen a huge number of candidates and still get work done) while developing this method?

    • Brian May 1, 2012 at 3:13 pm

      Hi Jonathan,

      Actually, someone is always in the room with them during the test. It’s a collaborative experience where the candidate gets to ask clarifying questions if they wish, because that’s they way they’d be working with the rest of the team if they were hired.

      - Brian

  5. Martin Velez May 1, 2012 at 3:11 pm

    Have you ever followed up on candidates you didn’t hire? In other words, have you evaluated your method.

    • Brian May 1, 2012 at 3:26 pm

      What kind of follow-up are you referring to, Martin? Are you asking if we contact them a month after rejecting them to find out if they’re happily employed, or something else?

      • Martin Velez May 2, 2012 at 1:21 am

        You partition the set of candidates in two; those you hire and those you don’t. You assert that your method is effective, at least in your context. You seem to conflate/correlate effectiveness of your method with the situation of your product and/or company.

        Unfortunately, you probably lack a control group, hires hired using some other method. You could evaluate your hiring method in several ways. Here is one way. A year later, arbitrary: rate your hires; compare them to each other, developers in other companies, to those you rejected. It might not be easy but attempt to survey rejects about their current job, salary, etc.

        Just a thought.

  6. toddhd May 1, 2012 at 3:33 pm

    I understand your point of view here, and can’t deny that someone that can handle those tasks in two hours under interview conditions is exceptional. However I do want to caution against using this as a sole judgement. I’ve been developing for over 12 years, and I have to tell you this process is so abused that messes with the average developers head. I recently took a coding challenge for an up and coming software company that asked me to complete a coding challenge. I did my best work. I used the latest technologies, fixed problems in their sample code, and so on, as you mentioned above. I falied the test. Why? Because they expected me to work within the parameters that I have been given. They wanted to know if I could work with poorly named variables, code from 10 years ago, provide solutions without resorting to libraries, etc.

    OK, so at another proespective company two weeks later – another code challenge. This time I took what I learned from the last test, worked within the parameters I was given, provided custom solutions within the framework I was given – but in the comments noted how I would fix it if not given those parameters. Failed the test. They were disappointed that I didn’t go outside the box, scrap what they gave me and do it “right” using new technologies and levering common libraries. UGH!

    At the end of the day, you need to give a LITTLE direction to your potential hire, and if he fails the “test”, then ask him why before showing him the door. If he just didn’t know to do something, then OK, maybe he is not the right guy. But if had a different vision or maybe does perform well in an interview climate, ask for code samples, documents, screen shots, whatever from his previous work.

    • Brian May 1, 2012 at 4:01 pm

      Good points, and I agree. A couple of things: we don’t use a binary pass/fail system with the test, and the 5 points aren’t our sole criteria for instant hiring (just a few of the ones we’ve used in the past).

      I also wouldn’t classify our tests as coding challenges, rather they’re more like simulations of what it’s like to work with the team. You collaborate with an engineer and build something together, and there’s plenty of direction and feedback throughout.

    • Aziz May 2, 2012 at 8:43 am

      Thanks, you made me laugh at 5:40 AM, before I started pounding on some code-retooling my coding, languages and skills “repertoire” :O)

    • Jasmine Adamson May 2, 2012 at 11:22 am

      Todd, this article isn’t about average developers… it’s about how to identify exceptional developers. The article is lacking, in that it only provides one possible method of doing that – but it’s a good method. I’m fond of saying I could walk into any kindergarten class in America and pick out the potential good programmers – but how do I do that? I can identify smart kids by the way they play. I could also give them a test, of course, and that would be effective, but other methods are effective as well. Average programmers may be flummoxed by the test, but exceptional programmers won’t be, and there are other methods of identifying exceptional programmers.

  7. Fell in love with programming May 1, 2012 at 6:16 pm

    I like this… I wish I got hired like this. In my current job, I had to explain my past work, tough situations and how I solved them and all. That’s normal stuff you’re always prepared for. When it came to technical specifics, they asked really simply questions like basic, foundational stuff we learn in high school and I was applying for a senior level developer position. I felt bad during the interview and they could notice the slight changes in my facial expressions due to shock and awe at the type of questions (what’s a class, abstract class, interface, sql joins etc). Then I actually jutted in and told “these are actually basic questions” and then they showed me a pile of resumes of people claiming senior level experience who couldn’t even answer these and at that point they just wanted to hire the next person who could explain their past experience and knew the basics.

    They hired me. Well, I consider myself average when I compared myself to most people at stackoverflow and I think my boss was lucky that I happened to be as good as they required someone for their position but they hired someone else using the same technique and he’s a total snob who can’t even google properly or clear his own compile errors not to mention that he can’t even refactor his own code. They’re thinking of firing him now.

    Seriously… I consider myself as average but when I see more people in the market like him, my ego gets a boost and the people that are involved with hiring me or managing me treat me more special. If that’s how they treat me then boy, have standards come down.

  8. Yev May 1, 2012 at 6:46 pm

    I don’t believe in rubrics for hiring anyone on the spot. Programming tasks during interviews allow you to observe behavior, but not its motivation. Is the candidate testing, documenting, and refactoring, because that’s how s/he usually operates, or is it because s/he is trying to pass an interview and knows that’s what some interviewers expect?

    A far greater predictor of engineering behavior is, IMHO, is the development culture in the workplace. An engineer who’s spent the last ten years refactoring, unit-testing, and documenting will either discontinue these practices or become resentful in an environment that does not value and encourage these practices. On the other hand, an engineer who has not been sufficiently exposed to these practices will be under social (and managerial) pressure to adopt them once immersed in a healthy engineering culture. If the candidate demonstrates the ability and willingness to learn from mistakes and grow beyond his or her established preferences, then that candidate may still be a fit for a culture that will challenge him or her to do better.

    So the only reason why anyone should hire an engineer “on the spot”, is because that engineer would fit into and thrive in the culture of the workplace. Tragically, there are many workplaces, where the hypothetical engineer described in this post, would be grievously out of place.

    • Brian May 1, 2012 at 10:19 pm

      Great points, Yev. On the motivation question: that’s for the interviewer to figure out. In my experience it’s pretty obvious to tell if someone is pandering to the interviewer or if they’re naturally inclined to just write things like unit tests because of their past experiences.

      Another challenge for an interviewer is the detection of raw talent, and whether a candidate exhibiting innate awesomeness (but who might not yet gravitate to things like automated tests, etc) could be allocated the time and mentoring effort while on the job to develop those skills.

      I totally agree with your last point. There’s no way I would hire someone for reasons #1-#4 if they obviously wouldn’t fit in with the team or the culture. I don’t think it’s tragic that there are many workplaces where the hypothetical engineer would be out of place, though – it would be tragic to hire them into one of those places and have them doomed to failure from their first day on the job.

      • Andrija Surac May 2, 2012 at 10:42 am

        Hi Brian
        I would be very interested to see if I could pass your test (not that I am looking for a job, but because I consider myself very good one-man-company developer – as I have several business applications that are commercially used (www.zpas.hr))
        Andrew

    • lornecjones May 2, 2012 at 12:37 pm

      This is an excellent point…I have been a Senior Engineer for years and have been through these types of test and as a previous comment stated…Failed. But companies that hired me found I picked up the culture, was a team player and once learned my place and how to best contribute became the best employee they had on staff. Tests and pre-screening apart from culture fit and personality will not gain anything but a robot coder with zero personality

  9. mossyblo May 1, 2012 at 7:53 pm

    Code tests are a complete waste of both parties time and effort as its more around a pissing contest then it is on quality of a candidate.

    Phsycologically speaking your doing more harm to unearth potential than good, as some folks may have deep insights into problem solving skills that often require more thought but in most cases code tests put an emphasis on fire drilling code checking / mathematic hurdles.

    If you have two hours to solve a customers problem and you need to grab a random developer from your resource pool – sure you can now define that list.

    Ultimately engineers need to stop finding mathematical benchmarks to rationalize a human to human metric. I’d hire a engineer who enjoys learning but failed a pop quiz vs am engineer who nailed pop quizzes but can’t interact socially or is highly introverted – worse – isn’t passionate about the role on offer

    Establishing whether a candidate is a good technical fit is why you have probationary periods, as now you have them on real problems that need real solutions.. But more importantly you have these candidates also fitting on socially and culturally within your teams..

    You can spot a fail within the first 3weeks quite easily.

    I blame Joel on software for this lunacy around “every programmer should be tested before hiring”. It’s pandering to elitism that assumes your hiring the top 5%

    News flash : top. 5% don’t sit tests and aren’t looking for jobs.

    • Brian May 1, 2012 at 10:10 pm

      If our coding tests were administered blindly (IOW, without regard for personality fit, approach, nervousness of the candidate, etc) then I would agree with you. However, that’s just not what we do.

      We make a concerted effort to simulate the candidate’s potential future work environment for the in-person interview so that both parties can figure out if it’s a good fit. It’s not an exam, nor is it a check-box of pass/fail on some super-high nerd-bar of difficulty. It’s an experiment conducted by both sides to see if the working relationship would succeed. It’s better to hire the right person who is a great fit than to let someone go after 3 weeks because you didn’t vet them correctly. Sure, that can still happen – but we prefer to drastically reduce the chance of that happening through a solid technical interview.

    • Jasmine Adamson May 2, 2012 at 12:00 pm

      I would consider myself in the top 5% and I like tests. What I can’t stand is a company who clearly doesn’t care if I have the skills I said I have and doesn’t want me to prove it. That indicates a management problem, and may indicate that I’ll be working with people whose skills aren’t up to par, on the assumption that they were hired with the same non-objective process. I agree with Joel Spolsky on this, because I don’t like working on teams with people who schmoozed the interview and were never tested on their skills, and who drag the team down with their lack of ability. I am a good developer, and I’m ready to prove it, and if you’re good enough, you should be willing to prove it too.

      People in positions they are not qualified for is a rampant problem in the software industry. Testing addresses that issue in an objective way. Of course, the test has to be good, and I think this article describes one good testing method. There are bad testing methods as well, such as the Microsoft Certifications – many of the certified folks I’ve worked with obviously passed the test, but they couldn’t do the job.

      • brad (@brad8118) May 3, 2012 at 1:02 am

        very true. Durning our interviews we have a senior and a “lower” level developer in the interview process. I’m the “lower” level dev I’m basically highering my team lead.. Most of the interviews I’ve done are with people who have 10+ years while I have 5. (Side note I haven’t been impressed with most about 90%) During the interview I tell them my experience level and I ask them questions that someone at my level should answer. Depending on the response I’ll either ask them more generic questions or lead them to something thats more complex that a “newer” developer might need an explanation and see how they respond.

        Also on a side note that I really haven’t seen too many responses indicate that is very important the the person that being interviewed is someone who you’d enjoy to work with everyday. Don’t get me wrong that a developer who aces everything is great, but if she/he can’t hold a conversation about the weather is a big flag in my book.

      • John Albietz (@inthecloud247) May 6, 2012 at 5:44 pm

        I think that an objective process is definitely key… but making a ‘good’ test is really tricky and it should be geared towards evaluating the type of skills that are the MOST important (or at least somewhat important… cmon) for the job that you are applying for. The tests should have well-defined constraints and instructions, and once the tests are complete the code should be the basis for a discussion about why certain choices were made.

        I’ve basically received the same type of coding test from 10 different companies for the Sr. DevOps roles that I’m looking at… and it’s really sad honestly to see what they’re asking me to do. It’s basically high-school CS where I’m supposed to open one file and pull out specific parts of that file and then compare it with a second file and output only certain lines from the second file based on a comparison with the lines from the first file.

        The instructions are poor, and I’m expected to clarify each time with these kinds of questions: “Ok do I need to worry about memory?” “Does this need to work for files of arbitrary sizes?” “Does this need to handle error checking?” “Is it important that the code is readable & documented?” “How long do I have to complete this test?” etc…

        But in DevOps, I am given a specific situation that I know a lot about… and based on the situation I am used to answering these questions myself. I should be given a specific and relevant situation… and then create a solution to solve it based on my experience and knowledge of what the constraints are when dealing with that kind of situation…

        If I’m given a situation that compares the /etc/passwd file with the /etc/group file, I’m not assuming that it’s reasonable/possible in even a system set up by the most bumbling sysadmin that those files would be millions of lines long each… And if they’re blank or corrupt we definitely have other issues… If this script needs to run unattended for a long period of time it should have error checking and logging. But if it’s just run once I wouldn’t need to do everything in software as long as I:
        1) make backups of the files
        2) ‘less’ into the files and take a quick look to make sure that there aren’t any surprises.
        3) Run a test on copies of the files…

        Wayyy back in CS 101 did it ever really matter if a one-time piece of code executes in 0.0000000001 seconds versus 0.000000000099999 ? If that is important to you, then please give me a real-world example that requires optimization. Or just specify that the solution needs to be as fast as possible. My recollection was that highly optimized code often needed to be rewritten when future assignments built on the code written in the earlier assignments.

        Also fyi for interviewers… if I’m using a scripting language there might be some behind the optimizations that alters the typical CS understanding of the performance characteristics of sets, hash maps/hash tables, and arrays. (See php and python for example) It seems that any question that *CAN* use a hash map probably should use one in a programming interview… Scripting languages can also handle errors in a pretty amazing way that interviewers may not be familiar with. For example, splitting a string a=”a:b:c::::::::::” in python by using b=a.split(‘:’) works just fine and results in b=['a', 'b', 'c', '', '', '', '', '', '', '', ''].

        Which brings up a final point… in the *real-world*, writing a first version of your code in a more generic and unoptimized way leads to code that you can more easily adapt in the future when you rewrite or refactor due to changing requirements. And less optimized code is generally more readable and for other coders who may actually need to read your code and make future changes it can be easier to spot problems or make changes many months or years after you finish your version. But in a coding interview, always assume that they want the most optimized version of the code… but make sure to ask anyhow just in case. Some people may actually care to see if you can code in a way that balances between speed and maintainability.

        Testing is important, but it is extremely important to design tests in a way that helps reveal the characteristics that are important to the job you are hiring for.

  10. Derrick May 2, 2012 at 1:32 am

    I would be interested to hear what points you look for to see “good potential”. There are cases where technically one doesn’t know the answer, but learning and finding a solution would then come in. In an interview that’s generally difficult.

    I understand there are most likely generic tests that any developer should know. But say for example they fresh out of collage or is that a case of “some one else can train them up”?

  11. steve May 2, 2012 at 5:11 am

    “We’re looking to find out if they can operate effectively in our environment and within our organization’s culture.”

    But there’s an extra filter you didn’t mention, i.e. what you get is people who can solve problems quick under observation, in the position of a test subject with “many eyes staring at them”. Not necessarily the best overall.

    “In the few hours that interviews typically provide, we’ve found it to be a pretty good mechanism for hiring the right people.”

    You can’t know, since you don’t know how good the people you didn’t hire because of above mentioned problem actually are.

    I’ve been given some bigger tests to do in a few days, at home, and found that to be much better.
    As for simulating the actual working environment to see whether one “fits in”, I doubt that you do this effectively – in an actual working environment you’d also ask colleagues something you don’t know/remember off the cuff, or just ask for a better idea here and there, to get forward more quickly.

    • Jasmine Adamson May 2, 2012 at 1:03 pm

      But productivity is a measure of what you got done per unit of time. So if the test isn’t limited in time, how can you measure if they will be productive? I have worked with guys who have to put in 60 hour weeks to keep up with everyone else – that is BAD for them and BAD for the company.

      • shattenyagger May 3, 2012 at 8:08 pm

        Yes, but productivity on one set of problems, especially well known [core] problems, does not automatically equate to productivity on esoteric scenarios. I know many coders that would probably ace those tests but will take 10 times longer on what I would call “simple” issues in a real and changing environment because they’ve been too busy writing HTML documentation for their code and tests…

      • James K. May 4, 2012 at 8:29 am

        That should be where previous experience, job history, and references are suppose to come in. Testing should NEVER be the only criteria on hiring.
        And just because someone has aced a test or shown any of the other exceptional abilities should not cancel or overlook their history.

        As far as the tests go, I’m okay with it… but, only believe 2 hours may be too long to begin with and would deter many applicants. Not that 2 hours of work is long; but, that 2 hours of heavy work may signify what the 8-10 hours in the office will be like in the long run.

        As far as what the test really gauge should be more up in the air than based on performance. Real problems are never simple or as easy as building a stack… if that where the case we wouldn’t have a job; because the computers already know that stuff.

        I don’t believe the person writing the blog really wanted everyone to just concentrate on the test or the few exceptional traits that everyone should be taught or learn anyway. Most schools are trying to teach a better bread of coders and commenters for the code. Comments are hard to find and often neglected … as a result, readability and changes later really suffer. I still find myself coming back to some projects after many years and saying “what was I thinking when I wrote this?” Not that it didn’t work… but, we all learn things as we develop that make us surprised when we look back at some of our earlier works.

  12. scott May 2, 2012 at 7:54 am

    I had a company (well there were other partners as well) developing both hardware and software for industrial solutions (which we eventually sold off) and at every interview I did with the software developers (primarily with an SQL background) I tended to go for those who were not afraid to have an opinion, just as the article stated, had a natural drive towards improvement, robustness, efficiency etc… now at the peak there was a large open plan office with 11 people (men and women) punching out stored procedures, queries, C and Assembler based embedded code etc … (sorry to waffle on there) but could I ever get them to agree on anything as a unity group they would argue and debate everything … hahahahahahaha so I suppose its just “be careful what you wish for”!

    Oh and one other thing we never tested the Software guys we hired we only employed through background checks … hmmmm maybe tests are a better way!

    Scott

    • pete wilkinson May 2, 2012 at 9:42 am

      Is it just me or is anyone else flashing back to a certain sadistic Monty Python job interview skit? At least it does sound like you intended to hire someone. You know, maybe if you were not such a nerd you would acutally have talked to /worked with enough colleagues that you wouldn’t have to find someone you didn’t know from Adam.

  13. lol May 2, 2012 at 8:26 am

    lol.
    1. Multiple solutions means he wastes precious time over nothing. He/she should think multiple solutions but write the best only, and btw iteration can be simulated with recursion while the solution is the same alghorithm wise bor both implementations. Not to hire!
    2. Its a plus, but not a deal maker.
    3. True
    4. If Refactoring is the new word for legible code, ok, that is a must. Actually the oposite makes more sense: code duplication = fail. Tbh, a good programer hardly writes duplicate code from the start.
    5. Agree, but only with a fortuneteller proffessional services :)))

  14. William May 2, 2012 at 8:47 am

    I am a software developer and I would be the best one you have, however I don’t care too much for your test because its missing my best strength. I am an innovator, so asking me to do a good job of changing a tire does not interest me much but if you asked me to design a new car or ask me how I would solve a problem then I will show you where I shine.

  15. yannbane May 2, 2012 at 9:02 am

    Hi. I’ve never really been to a job interview, I’m not old enough, but some people have discussed hiring me. I’m just interested in what type of problems can I expect to be given. It would be really great if you could send some examples to me. My email is: yannbane@gmail.com.

    • Jasmine Adamson May 2, 2012 at 1:12 pm

      @William – You are the kind of developer who can start things but when the boring part of finishing it comes up, you’re less motivated. In a job interview, you need to show you can get things done, and not just the cool fresh stuff, you need be able to get maintenance tasks done, even when they are boring. Your attitude is very common, and almost all good engineers share it – but that passion for new exciting creative things doesn’t get our address validation database updated every month – which I will be doing tonight, and I honestly have better things to do, like work on my new Android app – but I’m being paid to do a job, and I need to be ok with the fact that I won’t always like it and I won’t always be working on something interesting. In fact, a good 90% of the job is working on boring stuff, so if you can’t shine there, you won’t be very useful, and you will hate every minute of it.

  16. James K. May 2, 2012 at 9:25 am

    Good article. But, being on the receiving end of some recent interviews I’ve also learned to look for a few signs you should run away from the interview.

    (1) They give you a tour and show you the place (or more specifically room) they have shoved all the programmers into. There was one empty desk in the room and 8 other sardines in the can (so to speak)… sorry, I don’t do well in cans. This one was also located in a heavy industrial park with constant moving of heavy equipment, not exactly perfect.

    (2) Another, I interviewed in a business that was mainly manufacturing with only 2 programmers (or engineers)… I wasn’t told which they were or if there were any more. This company was working on a problem with a processor I could have helped with…. This one really wasn’t what I’d call a run away opportunity, but more of a cautious one. Where they hiring just for the problem, and let you go afterwards or would you end up being the only one left or only programmer in the group?

    I’m sure others may have more horrifying stories to share.

  17. josh233 May 2, 2012 at 9:58 am

    I would have been so happy if the last interview i had here in India with one of the biggest American gaming companies which has the name “Bally” on it.

    It was also a 2 hour coding test where it contained one paper in C++ and another one in MFC. I have done very well in C++. Infact that was the best coding test i have ever written, but the other paper i have not done that good because i always do not memorize the method/function names that the MFC provides because its a framework and you can get the method names from the IDE itself. But all of the questions from the MFC were about the function names!

    HR told me that i was not selected because i have not done well in the MFC part :(. It was really a very sad experience. I really do not know why we need to memorize something that is readily available.

    I thought the coding test is to test the coding skills of the programmer and not memorizing a framework?

    Can somebody correct me on this, is it necessary to memorize the methods that framework provides?

    • shigorin May 10, 2012 at 4:09 pm

      Why, disable L1/L2 cache on your CPU and compare performance. That’s what you get with your supposedly helpful IDE.

      Overall: nice article and great discussion, made me smile gleefully way more than once recalling different occasions (including getting interviewed once back then). Thank you, nice folks over there.

      I’d like to contribute a reference to the excellent Johanna Rothman’s “Manage It!” book which had very similar effects on myself while reading it.

  18. Winston May 2, 2012 at 10:14 am

    I have only gone through the whole cold interview process to get a job twice – every other job I’ve gotten by word of mouth or already knowing the potential employer. In the first case I was freshly dropped out of college. I was given a programming test, although it was based on several systems of pseudo-code. More of an aptitude test than a test of knowledge or experience on any particular language or platform. Several friends had applied for this job and said I’d probably walk out on the test. I opened up the test to the first page, flipped through it, and knew I had the job. The second time came 12 years later, and it wasn’t a programming test but a four-hour psychological profile – which I later found out to be illegal. I got both jobs. Interestingly enough another 23+ years later, I might have trouble passing the pseudo-code test just because it was a perfect fit for my youthful ability (and willingness) to learn rapidly as well as my general test-taking skills. Today I have more resistance to learning something just for its own sake. I don’t study languages and systems that aren’t needed in my work – it’s not a hobby. I believe I’m capable of learning new skills, and learning them rapidly. But odds are I wouldn’t have the immediate knowledge necessary to pass your test in the allotted time.

    As to the other aspect of fixing problems in the existing code, I’ve mellowed with age there too. Used to be my motto was, I’ll clean up the mess but you can’t pay me enough to sit in the mess. But greed has replaced pride and sometimes the mess is a cash cow. This is where it’s clear that different companies have vastly differing practices. Some would appreciate a guy like me with a passion for rewriting, cleaning up, improving (even my own code), others wouldn’t give me the time of day if I didn’t embrace the sheer genius of all that came before me.

    I want to add one more thing that I personally look for in a candidate: willing to admit they could be wrong, or that they don’t know everything. I’ve worked with some very good technical people who will refuse to do something that makes all kinds of sense for the product and end user but doesn’t fit their technical view of how it should be. This trait tends to show up in recent graduates (especially with masters) but can also appear in people who have primarily internal team experience and little or no end user contact or feedback. Most of my life I’ve had more contact with end users than any 10 programmers ever experience, and I always give them the benefit of the doubt because in many cases when it comes to software, I’m an end user myself. So it’s easy for me to take their side in any debate over UI or just why a feature might be needed.

    • Chris May 2, 2012 at 11:16 am

      Good points Winston. I have been coding on Wall St for 15 years and I have similar opinions about code tests and the latest technologies. On interviews I have been asked what I read, I answer the NY Times. What non work projects I am working on, my answer is the lawn and my kids, I don’t code for fun or adventure. Quite honestly, I have never done well on a technical interview but I have been financially successful in our craft.

      At some point I think that we all mature out of the code monkey phase and accept that our skill set is suited for the job, not a lifestyle. These kinds of interview techniques and code tests only serve to find the most suitable code monkey in the hiring managers own image.

      When interviewing programmers, my opinion is that you can teach almost any decent programmer to code the way you want them to. It is harder to teach them to understand and appreciate the business that the company is in. It’s even harder to get an introvert to interact with and understand the business users, and that is a skill set that is invaluable in our line of work.

  19. Pingback: 5 signs that you should hire a programmer on the spot « More Than Coding « SPINMAN.TV

  20. Pingback: 5 signs that you should hire a programmer on the spot « More Than Coding | SPINMAN.NET

  21. Fadi E. May 2, 2012 at 10:45 am

    I would add one to the list:

    - Create detailed estimates: Estimates are estimates – but there are many programmers out there who just give a ballpark estimate of the costs, without any justification. Detailed estimates are appreciated by the client who wants to know how his money is spent.

    Additionally detailed estimates prove that you have fully understood the requirements.

  22. Chris May 2, 2012 at 10:46 am

    If you handed me a two hour test during an interview, I would show myself the door.

    • Yev May 2, 2012 at 10:52 am

      Would you audition a violin player without making her play?

      • William May 2, 2012 at 11:23 am

        Instead, I have asked people to bring in a copy of some source code they have written. Their whole personality will be in that code, the disciplined and consistent formatting or lack of it, inefficient coding, and maturity to name some off the top of my head.

      • Yev May 2, 2012 at 11:27 am

        Working alone is not quite the same thing as working in a team, interacting with other developers, providing and accepting feedback, and, yes, dealing with some time pressure – all facts of life in real-world engineering. While the prospect of being tested on these skills, which can never be fully perfected, is legitimate grounds for anxiety, it does not make for an unfair interview practice.

      • Chris May 2, 2012 at 11:25 am

        In your opinion, musicians are analogous to programmers? I disagree with that premise entirely. Programming is not an art form; it is just a technical skill.

        You cannot detect if a person can create beautiful music by questioning their knowledge of music theory. On the other hand, you can quickly figure out if a programmer knows what they’re doing with a short conversation about problem solving with heavy use of technical jargon. You can also figure out a lot about their personality, interests and suitability for your environment at the same time.

      • Chris May 2, 2012 at 11:36 am

        No one said testing was unfair. In my opinion, anything above and beyond testing for some problem solving skills and basic technically literacy is overkill and you are risking losing quality candidates. Honestly, my initial objection to this article was that the test took two hours. That is excessive and a bad omen with regard to how the company values the time of its associates.

      • James K. May 2, 2012 at 11:48 am

        @Chris,
        You are right in the sense that a 2-hour test seems a little long. It is sorta like asking the musician to play for 8-hours straight. You want to test the applicant so you can attempt to determine their skill level; but, at the same time giving them an overly long test can be a large discouragement to the applicant and they may think twice before accepting the position.
        Weather programming is an art form or a technical skill is a topic still open for debate. I’ll say it may be a bit of both, in reality.

      • simmol May 3, 2012 at 3:39 am

        Would you audition violin player on Piece of music that she/he never played before ?
        You can get the basic. And actually the only way to know she/he is advanced in her/his craft is for the interviewer to know the subject that the performer play.

        To make it little more clear (cause my English is not so good :) ) if i should not write some code you want for limited hours to show my craft. You should look at my code to decide am i good in my craft or not. There can be assignment but the time limit is stressing.

        I have like 3-4 jobs all with some code test and none of it prove anything about the actual work. On my jobs no one ask me to code him something only for 2 hour or i fail. They are delivery crunches but if this is you code practice i better not work for you :)

    • Chris May 2, 2012 at 12:00 pm

      You are right about the art form debate James, and I fully expected to get called on that comment. And yes, coding can be an art form in the eyes of many, but after 15 years I have lost that loving feeling. What I have learned is that to most non-coders, and by that I mean the people who pay us, time is money and that they don’t care about art. I guess I have just become jaded by my reality.

      • Winston May 5, 2012 at 10:10 pm

        @simmol you ask “Would you audition violin player on Piece of music that she/he never played before ?” The answer is yes. Every music audition I ever took part in involved sight reading. It wasn’t the only part of the process, but an essential one. Whether a placement audition or a whole band competition, how you perform a piece of music you’ve never seen before is something highly valued in a musician. Many musicians make their living playing one-night jobs, traveling shows, and have very little opportunity to rehearse – they are expected to show up, blow through one dress rehearsal (or none) and go.

        IMO anyone who has both played music and programmed clearly understands how closely analogous they are. And is also well aware of the roles egos play in both crafts :-)

  23. Pingback: 5 signs that you should hire a programmer on the spot | Oh Goodbye Days…

  24. John May 2, 2012 at 11:10 am

    My pet peeve is interviewers that expect you to write a program on a white board. White board programming isn’t readable by humans or machines. All the variable names are x,y,z and i,j,k because it takes to long to write proper understandable names for function. Then play computer writing output on the board to see how it runs. Stepping up to a computer to write a program and run it can be done as simply as using an editor and browser or more elaborate with an IDE–and it shows a lot more about a programmers capabilities. Two hours is enough to develop a good piece of work.

  25. Stephen Yang May 2, 2012 at 11:10 am

    If I encountered someone like that, I would also have to evaluate their interpersonal skills too. That kind of attention to detail is almost OCD.

  26. Kevin O'Mara May 2, 2012 at 1:00 pm

    Ah, here’s a blatant mistake in your article. “Refactoring” implies a machine-based, algorithmic reimplementation of code, not human-based. There is no such term for a human-based refactoring. You should be explicit in your metaphor!

    • Brian May 2, 2012 at 2:12 pm

      So no humans engineers have ever done refactoring? Machines are sentient enough to detect code smells and commit changes to fix them? Your definition seems academic at best, and removed from reality at worst.

      • Kevin O'Mara May 2, 2012 at 2:20 pm

        Um, like I said. “You should be explicit in your metaphor”. The author should say something like “human-based refactoring” or “human-like refactoring” to be explicit and proper. Please work on your reading interpretation.

      • Kevin O'Mara May 2, 2012 at 2:24 pm

        I should have said “reading comprehension”.

        “Machines are sentient enough to detect code smells and commit changes to fix them?”

        Also, are you so far withdrawn from reality to note the existence of refactoring tools in modern IDEs? That is where the buzzword is derived from.

      • Brian May 2, 2012 at 2:31 pm

        No, of course not, I’ve used them for years. But I’m still the driving force behind the initiation of the refactoring process within my IDE. My point was that your initial comment seemed to imply that it was a 100% automated process that required no human involvement even to initiate it, and I wanted to clarify that point.

      • Yev May 2, 2012 at 3:40 pm

        Now, boys, let’s not fight. “Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.” — Martin Fowler (http://www.refactoring.com/). No mention of humans and/or machines.

      • Kevin O'Mara May 3, 2012 at 4:02 am

        Have you confirmed this with other sources? Can you tell me what Wikipedia even says? Rafactoring.com is merely “a simple portal”, and cannot be considered an authoritative source.

  27. toddhd May 2, 2012 at 1:09 pm

    One other thing I’ll add, and this may be slightly off-topic, however just as important is for the employer to know exactly what they are looking for, and tailor the interview to that position/duty.

    For example, my background is largely in “front-end” technologies, and my primary skills would involve things such as HTML, CSS, AJAX, Javascript, as well UX design and workflow, usability, etc. I simply cannot tell you how many interviews I’ve been on where the company has the technical interview conducted by a “back-end” developer, who then proceeds to ask me all about back-end technologies and methodologies. While there are certainly arguments to be made that a good front-end guy would have some knowledge of back-end, it should not be considered the sole basis of the technical interview in that case. You interview based on the core competencies of the position.

    I mention only in regards to those who expect to setup a perfect test that fits every hiring situation they have, which in my experience, is a LOT of companies. Each hire is unique. As many have said, a person who is passionate about their work and is a good fit personally and professionally may be a much better employee in the long run than a “rock star” developer who can code anything thrown at him, but expects the world to kiss his… ya know.

    • Kevin O'Mara May 2, 2012 at 1:22 pm

      That’s funny you should see that in “rock star” developers. My image of one is of the Russian twenty-something whiz kid from an Ivy League University who develops algorithms for winning at gambling… and succeeding back in the ’90s, like in one movie I saw (can’t remember the name). It is unlikely that such a developer would be working at such a level presented here.

  28. CUP May 2, 2012 at 4:25 pm

    Some coders are slower than others because they are 4 finger typists. They choose short names because they can’t type very fast It doesn’t mean they are bad programmers: just that they aren’t fast typists. They’d have difficulty finishing a 2 hour test, just because of their typing speeds. I’d watch how they coded rather than how quickly they came up with a solution: quick problem solvers aren’t necessarily good coders: especially when they cannot understand anyone else’s code other than their own.

    Presenting multiple solutions to a problem: I’ve actually been rejected for a job for doing that. They reckoned I was overqualified and they didn’t need someone who was that good. That was 15 years ago.

    Writing full documentation and creating test harnesses: I’ve actually been rejected for a job for doing just that 10 years ago. They reckoned that since I did more than was required, that I’d get bored and leave after a short while.

    Maybe I was just looking at the wrong jobs.

  29. Stella Karavas May 2, 2012 at 4:59 pm

    Excellent article – having been taken for a ride by a programmer who talk a good game and had an impeccable CV, this is putting your money where your mouth is.

  30. Dan May 2, 2012 at 5:52 pm

    A balance of good programming skills, communications, and common sense is generally the ideal candidate. Focusing too much on how quickly a person can build a working stack of functions and not focusing on the other areas can be a recipe for disaster. There’s a very good chance you’ll end up with a lot of bright people, but a very handicapped team of know-it-alls who think they should write everything from scratch (i.e. reinvent the wheel). This will typically result in very long development cycles and a code base that doesn’t take advantage of proven standards (making it difficult to maintain). I’ve been in the business for years and have seen this happen quite a bit. I’d much rather have a team of good programmers who can work together than a team of superstars who would rather work in a silo.. This causes way too much management and will eventually lead to a non-technical manager making all the decisions rather than the team moving the project forward. If that’s the kind of team being built, then you’re taking a huge risk that will mostly likely result in a failure.

  31. JeffB May 2, 2012 at 6:10 pm

    Biggest criteria from an employee is honesty. Willing to to a good days work and not steal anything (including time). Then ability to get on in a group and ability to learn. Where in your silly test are you looking for the most important attributes. Lots of people get shaken down. Remember you never get ripped off by someone you didn’t like. Laslty have you ever employed someone who did NOT pass the test to see if the test was valid?

  32. ronal May 2, 2012 at 7:27 pm

    very good ….

  33. RSY May 3, 2012 at 12:21 am

    Really nice artlcle and so true. We have been into hiring mode recently and believe me its very tough to find a candidate who is good on all these parameters. We interviewed around 40 candidates for a single position and could manage to get only 2-3 good candidates for the final round.

  34. StationStops (@stationstops) May 3, 2012 at 8:34 am

    I don’t look at developers from the code level, don’t ask them to code for a lot of reasons, and I definitely don’t judge developers on their level of insistence on refactoring ( I’d rather have them think ‘this isn’t the most elegant solution, but I know it works, is readable, and meets requirements, so I’ll move on to the next problem and see how much it annoys me later before I spend time refactoring it)

    I want to talk to them about projects, and *how* they talk about them, projects they’ve done, problems they’ve had, how it could have been avoided next time. in most cases, I expect them to not talk about code, but the process.

    when a developer keeps wanting to talk about code, it says to me he still considers that lower level to be a problem he still obsesses with. higher-level programmers don’t worry about that stuff, they know they will find a solution for any problem at the code level. they worry about the external factors of how the process is managed to insure success.

    That said, there are a breed of great developers who still love to talk about code and are great to have, but In startups especially I want developers who see more broadly and can elevate to lead others later. in other words, developers who see code as a tool and delivering software as their skill, not those that see code as their skill and projects this annoying thing that sits on top.

    • James K. May 3, 2012 at 10:48 am

      Very good points.

      Another good trait is being able to think outside the BOX.

      I mean this for all those that haven’t started as well. You have to think differently when programming a computer; realizing that they do exactly as they are told and don’t improvise (that doesn’t come until they fully perfect the super-computer). It also relies on talking to the hardware, regardless of what anyone says, you always have to touch at least one piece of hardware in most circumstances or you really aren’t having fun (so to speak).
      The trick with programming is finding the correct sequence of 1′s and 0′s that produce the desired results and doesn’t cause problems in the long run.

    • lornecjones May 3, 2012 at 12:11 pm

      @stationstops – This is exactly the best comment on the entire blog…Process, Process Process… The Process should be focused on. The “Why” not the “How”. The “How” can be Googled by any high school student but the Process is what you are being paid for. This coupled with personality is the two ingredients that should be the catalyst for hiring someone on the spot. The blog is really saying that they want walking robot encyclopedias of code. When you hire a life-less person that is exactly what you will get….No creativity, No Real Problem solving, Only Code focused, and a No Thinking out of the box mentality employee that probably has inter-personal skills issues.

  35. Robert May 3, 2012 at 10:11 am

    These interview tests reveal more important stuff about the people giving the test than the tested. Personally as a matter of principle I will refuse any offer of work from a company that employs formal tests on interviewees. This has had quite amusing results at times over my 30+years. But I _always_ stick to it.

    • Jasmine Adamson May 3, 2012 at 12:48 pm

      Why do you not want to demonstrate your skills? If you’re good, you should be able to do that, right? In my 30 years, the places with testing have ended up being good places to work. I have rejected an offer in the past based on the content of the test (I applied as a Senior developer and they tested my algebra skills, which I found insulting). However, it’s not an insult to ask a person to demonstrate their skills – they don’t know you, and a glowing past can be fabricated. If you have the chops, I don’t see any problem with proving it. So, could you please explain your position? Are you famous or something? (I would not give a coding test to Steve Wozniak, but I would give you one)

  36. lincoln300 May 3, 2012 at 10:57 am

    In today’s world, able to provide multiple solutions for a single problem is a valuable skill set.

  37. swampwiz May 3, 2012 at 9:40 pm

    It seems that the current brutish employment market allows employers to be extraordinarily picky with their hires. I guess programming jobs will be only attainable for the top 10% of coders who are so obsessed with the latest k3wl technology that they code at work, and then code at home. I’ll bet they really have a great understanding about how the world works …

  38. Mike May 6, 2012 at 7:52 pm

    In my experience, many companies are extremely proud of, and confident in, their particular interview processes despite the fact that studies of interviews have shown them to have little ability to predict performance. I have no idea whether the test process you describe is effective or not. Obviously, it’s very difficult to study the people you reject. However, it would seem that you could assess your process by looking at the relationship between your assessment of a candidate at interview time and how he or she actually performed when hired (e. g. after they leave). It might also be worth considering how different interview processes affect the acceptance rates of candidates to whom you do extend an offer. Prediction of something like job performance is extremely difficult, so I don’t put much weight on speculation about how each feature of an interview may or may not determine some specific aspect of a candidate’s ability. I’d be far more convinced by a few actual measurements.

  39. backpaqer May 7, 2012 at 7:32 pm

    While I like to use a simple logic code test in my interviews, I rely more heavily on a more open dialog with the candidates that follows a more natural path through their programming experience and history poking into those awkward moments we’ve all experienced and uncovering how they acted, felt, thought, reacted, learned etc. A lot of the examples you have shown in this blog highlight people who may suffer from “perfectionism”. Running a project loaded with perfectionists in, you’ll find that the quality of work is key and you can merely wave byebye at the deadlines as they go sailing past.

  40. Dave May 11, 2012 at 12:14 am

    Personally I appreciate it when companies show their hand early in the piece. I for one would most definitely show myself the door as well. I finished all my pressure testing at uni (High Distinctions) before anyone says cant handle the pressure. What guarentee does the employee get that your worth working for? This sounds like a shop full of geeky programmers trying to out geek the next poor interviewee by putting them under pressure with their cleverly crafted tests….in their opinion. Very biased way of doing business. IMHO. You can take a punt on me just like I have to take a punt on you. Your probably devoid of personality and criticise people at the drop of the hat while you stand around laughing at programming jokes.

  41. Freesharehere May 14, 2012 at 4:31 am

    Superb Article. I appreciate your work. I wish i got the programmer who has all the above qualities. And I also keep in mind all the points while hiring a programmer. Thanks for sharing this article.

  42. Pingback: 5大迹象显示你应该当场聘用程序员 | IT & 数码

  43. UOBabylon May 15, 2012 at 3:07 pm

    You have stated very good points , I read all the comments , martin , I think you have never been an interviewer !!

    Thanks , UOBabylon

  44. bibleshockers May 17, 2012 at 8:38 am

    The “interview as a game” approach inherently flawed: http://www.youtube.com/watch?v=cHiGVJeuPbs&feature=relmfu

  45. Steve Willis May 17, 2012 at 4:49 pm

    As a T-SQL developer I’d want to know if during the coding test I had all my normal tools available such as my personal “tool kit” of scripts, my snippet manager, my RedGate tools, rights to run scripts against the master db, rights to view execution plans and create indexes, etc.,…not to mention simple internet access to Google. Would you expect an employee to work without his tools? Why not tell a carpenter to build a house with a handsaw and toy hammer?

    Another thing coding tests won’t tell you is whether or not your new hire is willing to work until 3am on the night before that important project goes live…and then come back in at 9am the next day to make sure everything is working OK. We recently lost a good employee who worked with us only a few months because he was basically an 8-5 kind of guy and his wife wouldn’t put up with unpaid overtime (we are all on salary) and didn’t like it when he had to work from home either.

    And one more thing these tests can’t determine is a candidate’s inherent business sense. Does the super-star coder know what a bill of lading is? Or the difference between nominal interest and APR? Or even the difference between revenue and gross margin (probably the most important thing in any business)? Without knowing what to ask of clients up-front and getting the requirements of a project correct, the super-coder will just do the wrong things very fast, then do them over again very fast, and then after a few more rounds of such real-time “refactoring” watch the profits sail off when the client bails or the hours expended wind up 3 times over the original estimate.

    Efficiency and speed is great as long as it’s focused on the correct things. In my experience the consumers of my services rarely see the big picture during the planning stages and it’s my job to give them a finished product that meets their NEED–and more–even if they didn’t think of it at the start of the project.

    • shigorin May 17, 2012 at 6:00 pm

      There are different kinds of people, and I use to work fine with both 9-6 folks and overtimers like me given they know their job (still usually they know way more) — but *demanding* overtime is demanding to kill off productivity in the long run, I wouldn’t invest that in any business but my own (and overtime is one of the worst things I can do to my own one).

    • lornecjones May 17, 2012 at 6:26 pm

      My Point exactly…Excellent comment

  46. WoundedEgo May 17, 2012 at 6:42 pm

    The comments are all good. In fairness to the original post, though, the article didn’t say that “These are the only indications of a keeper” but “these are 5″… and they are. If viewed as “the acid test” then, no, they will select for certain desirable attributes. I’m reminded of the “Moneyball” effect.

    Personally, I would “fall out” on a test like that. Many people do poorly on tests. A bright young math teacher who “gets” *why* so many bright people don’t succeed in our schools has put together a great presentation on a better approach to harnessing his student’s energy, and I think the same approach will apply to the workplace:

    http://www.ted.com/talks/lang/en/dan_meyer_math_curriculum_makeover.html

    I’ve had the good fortune to put my *strengths* to work and it has made me very valuable.

  47. 7heaven11 May 18, 2012 at 2:43 pm

    Reblogged this on 7heaven11′s Blog.

  48. Pingback: 5大迹象显示你应该当场聘用程序员 | Micro Blog

  49. Pingback: 5种迹象显示你应该当场聘用程序员 | 博客水木

  50. Pingback: Blo-g » Quels sont les signes permettant d’identifier une perle rare (développeur) ?

  51. Jorge Cuevas July 9, 2012 at 5:49 pm

    hello, i have a question, i need to hire 1 developer, i do not have any skill in developing anything, still i will group 10 developers and 1 will be hired, i’m researching for programs and things they can develop and test them like that, make them work for the position, any suggestions?

    • Michael Shigorin July 10, 2012 at 2:31 am

      A word of warning: project failure chance is much higher if the group leader/manager has no on-hands experience in what a group has to do. For one, I am carefully avoiding such situations.

      If you are determined that this is the way to go, then:
      - ask those 10 (or 9, or how much?) developers what they would suggest you regarding hiring — a reasonable recommendation is a good thing;
      - be prepared to check with your customer every week or two regarding the prototype/early code being developed and what’s to be accepted as a delivered product (can’t imagine a product company where clear understanding of the result and the process are IMHO even more critical).

      A good reading for a software dev team manager: http://pragprog.com/book/jrpm/manage-it

      • WoundedEgo July 10, 2012 at 12:43 pm

        Jorge, are you wanting a test for the new hire or for the whole team?

      • Jorge Cuevas July 10, 2012 at 12:59 pm

        @Michael Shigorin… thank you for the answer and yes it is much more difficult for me since I have really really basic experience, but i’m also the customer, this project is for me to use. I will read what you send me.

        @WoundedEgo, no I’m only hiring one, my idea is to give them an assignment test and whoever does it better, gets the spot.

      • WoundedEgo July 10, 2012 at 2:02 pm

        @Jorge, I’m curious who decided you needed a 10th developer and why, since you are just assembling the team and presumably have not even started the project and you seem unclear about the job requirements. Maybe you should hold off hiring until you have a clearer picture of what you need. I heard on NPR today that decisions made prematurely are often disasters. “Ready! Fire! Aim!” kind of things!

      • jrdc74 July 10, 2012 at 2:21 pm

        @WoundedEgo, Regarding the project I really do have very clear what do I want and what do I need, i dont need a 10 people developing I need one, i’ll be interviewing 10 developers, and i will only hire one. The idea is to give them an assignment test and whoever does it better, gets the spot.

        What my real question is if there are any suggestions regarding Assignment Test.

      • lornecjones July 10, 2012 at 3:24 pm

        This clarifies the issue…have you read ALL the replies to this article? The majority of respondents have taken issue with this article. Developer assignments are NOT a proper way to asertain if you should hire or not. In fact the real test would be the verbal discussion, their team working ability, their project history types and how they handled previous issues that arose during the project. Also, and overridding most of the other items listed is the ability to work with and personality of propective employee. To test knowledge of material, a walking encyclopedia a good developer does not make, instead do solid reference checks, and give a probation period of a few weeks with part of the actual work in the environment that the employee will be working in…this will test the prospect properly!

    • jrdc74 July 10, 2012 at 12:59 pm

      @Michael Shigorin… thank you for the answer and yes it is much more difficult for me since I have really really basic experience, but i’m also the customer, this project is for me to use. I will read what you send me.

      @WoundedEgo, no I’m only hiring one, my idea is to give them an assignment test and whoever does it better, gets the spot.

      • WoundedEgo July 10, 2012 at 3:36 pm

        @Jorge – Oh, I see, I misunderstood! Then maybe:

        * relevant resume
        * references
        * rapport

  52. Michael Shigorin July 10, 2012 at 1:07 pm

    Ah, that’s a different game of course.

    Might also be worth looking at what they’ve done already and ask for recommendations regarding the projects that are more or less similar to yours. Someone’s experience in the problem domain helps a lot too.

    That book is a huge overkill for a single man project (but even then it does show the common pitfalls like leaving things going on their way for too long only to find out that they went astray — e.g. into scratching our technical itches instead of getting something actually useful done).

  53. Michael @ Headhuntable August 1, 2012 at 9:01 am

    Another good idea would be to give the test and ask them what they would improve & what language they can use to improve the test. (For example if the challenge you gave them can be done better in Ruby on Rails or Java versus PHP)

  54. WoundedEgo August 1, 2012 at 10:57 am

    I read somewhere that you need to spend at least an hour with someone (or any proposition) before making up your mind. An offer that sounds like a no-brainer at first might start looking like a problem after 45 minutes and vice versa. I’m not talking about a test, just about maybe doing a long lunch and chatting about some the things that characterize your company culture and see what comes up: http://www.youtube.com/watch?v=rMRqZV-P6Ok

  55. jwayne20 August 6, 2012 at 1:38 am

    Good points to review before hiring a developer! Actually, I’d rather do a series of interviews to decipher a person whether he’s adept at programming or not. In most cases that’s how recruiters differentiate an applicant among others when it comes to skills and attitude. When you are hiring a programmer I would prefer outsourcing it to a trusted site especially if it focuses on full time work. We could name a lot of freelance sites today but I have more trust with http://www.staff.com. They have a pool of talented programmers and it’s always easy to contact these contractors and interview them for as low as $1.

  56. Soma Sekhar August 7, 2012 at 7:33 am

    ya true and really good

  57. Jane Somerset September 6, 2012 at 2:30 am

    Very cool :) Check out http://www.jobstock.com/blog/how-to-hire-a-programmer/ for a really great perspective on the basics of hiring a programmer when you’re not a programmer. Also very handy read.

  58. Pingback: 5种迹象显示你应该当场聘用程序员 - 博客 - 伯乐在线

  59. Iain Barnett April 27, 2013 at 12:32 pm

    Nice blog post. I have one comment, point 3: “We deliberately create tests that have some minor issues lurking within them”… If I took a coding test and I saw that, I’d probably think that the team were sloppy with their work and be less likely to want to work there. I’ve worked at a couple of places where the work was, frankly, sloppy, and it doesn’t make for a happy place to work (when the server goes down 10 minutes before you were due to leave because of an easily preventable error, you start to wonder why you work where you do).

    It may be something you’d want to mention after the test to the candidate, or you might be leaving the wrong impression. Interviews aren’t really interviews, they’re business meetings, they work both ways.

  60. Martin February 11, 2014 at 10:46 pm

    Coding interviews. Program challenges. Nothing but a scam and an insult. I own a software company, and I only hire the best people. It’s very clear to me, after many years as a programmer, who is good and who is not. I don’t need any tests. That is just so insulting and unprofessional. As for interviews, all I need is to chat with someone for five minutes and I know if I want them. In general, the work they have done speaks for itself. What I really need is to find out if they are compatible with our company ethos. By the way, it never ceases to amaze me how utterly rude, arrogant, antisocial, and generally clueless most programming nerds are. I wouldn’t trust most of you to give me the time of day. There are truckloads of smart programmers, but the real challenge is finding someone who is not only very smart, but a decent person who knows how to treat other human beings. Someone who is not a primadonna and knows how to work as a team player. Something most of you lack in spades. But I’m lucky because I love computers and this allows me to put up with the few occasions when I absolutely have to have contact with computer nerds I despise. Fortunately I can work with my own people who I select, and I like them all. Have a nice day and try not to be such snot-nosed pricks, if you please. (I’m sure not of you think this applies to you, just to your manager or someone else.) The funny thing is, you all think you are so amazingly smart, just because you work with computers. Yeah, right. At university I took classes from a few Nobel Prize winners. They were pretty smart but even they admitted they were not that smart compared to the greats. Humility is part of being truly smart. By the way, the way some of you nerds like to trick people with your oh-so-clever “tests” just shows what jerks you are. You disgust me. Now back to work and make some good software, please. Go ahead and reply, have fun. I’m not even going to bookmark this site, I just was in the mood for a nice rant.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 30 other followers

%d bloggers like this: