I have a dilemma. I have a candidate for a senior software developer position.

The guy seems competent on a first talk with him and he answered the questions asked precisely and gave me proofs of his work. Moreover he has been highly recommended by some trusted colleagues.

In this case I am tempted to skip the technical test HR requires as I need to fill the vacancy asap. Please share your experience.


Against a better judgement I have given the test. Top scores on almost all questions, even on subject that he did not boasted upon. But I had so support some irony from him when he saw the questions of the test - which were clearly not for a senior.

So we made an offer.

Thanks all for the insights.

  • 22
    recommended by trusted colleagues should be good enough. Most would not do that as its their reputation on the line.
    – Aditya P
    Commented May 16, 2011 at 17:38
  • 28
    If you don't have enough time to test him now, how the heck will you have enough time to fire him, search for a new candidate, and then test that guy? Do it right the first time. Commented May 16, 2011 at 17:52
  • 1
    @Alex: It is not a question of not doing the process right. I want to hire fast because I have a deadline to keep. I can test him as much I want, I have even made him design solutions on the talk - no code though as I really was not interested in the language syntax but in the solution proposed and suitable technologies. Commented May 16, 2011 at 18:12
  • Could you not contract during this pressing time?
    – Kevin Peno
    Commented May 16, 2011 at 20:33
  • 1
    @Aaron, would HR really be that worried about a contract position? Especially if the contract was setup short term to prevent long term hardship for the company.
    – Kevin Peno
    Commented May 16, 2011 at 21:00

15 Answers 15


As usual...

It Depends

I have never seen a technical test that proved competence. I have seen a lot of technical tests that demonstrated ignorance - both on the parts of the test-maker and the test-taker.

How much confidence do you have in the technical test? Have you taken it? Do you think it's fair?

Confidentially, I took an online technical test as a favor for a client a while back (they wanted my scores as a 'baseline' for new hires) and failed it - mostly because the test questions consisted solely of syntax and function names for a specific version of a specific language. I use the language all the time, and have for years, but not those specific features. These were all things that I could look up when/if needed - and as such were utterly irrelevant to skill/competence.

So it really depends on the test. If you think your technical test is significant then by all means administer it. If you don't then get rid of it. Your impression based on a personal interview plus recommendations from trusted colleagues are far more valuable than any test.

  • :) I am really not interested in the syntax or code formatting. I just want an experienced guy that can handle uncertainty and knows his stuff well. Moreover he is a SCJP - id verified at Oracle. Does it worth asking him questions on C# just for the sake of HR process? Commented May 16, 2011 at 18:25
  • 3
    +1 "Both on the parts of the test-maker and test-taker"...indeed. Wish I could +10 that Commented May 16, 2011 at 19:20
  • 1
    @Daniel: I don't think so - but I have an extremely low opinion of HR processes and formalities. I think much of it exists merely to justify the existence of the department, rather than add value to the company. But that's just my opinion. Commented May 16, 2011 at 19:50
  • If it is an online test, then you can look up the answers just as you would normally, no?
    – Zan Lynx
    Commented May 16, 2011 at 20:17
  • 3
    lol at your story about failing a test for a technology the client already knows you are an expert at. I've taken those sorts of tests before and they really made me doubt my own abilities (I was too early in my career to realize how useless the test was.) This is exactly the reason most technical certifications are at best buzzwords to put on your resume for HR screeners.
    – jhocking
    Commented May 17, 2011 at 14:27

Will the results of the technical test make a difference in your hiring decision? Is the strength of your talk with him and the recommendations of highly trusted colleagues strong enough to make any results of the technical test irrelevant?

If the test won't make a difference then skip it.

  • 2
    If the test won't make a difference then skip it. - I thought the same. However, there is one more variable - HR, if it strongly requires that test and it doesn't take much time, then I'd recommend to do it for not being blamed by HR in weak testing or not supporting company rules/policy.
    – alexb
    Commented May 16, 2011 at 19:57
  • 1
    @alexb If HR truly requires the test the the question itself is moot and the test must be administered. The fact that the question is asked we have to assume then that the possibility of not taking the test exists.
    – Gratzy
    Commented May 16, 2011 at 20:01
  • 1
    @Gratzy Certainly agreed. By "HR strongly requires" I meant, that HR requires test but it still could be skipped(if HR could be flexible), but it could be risky for manager in case of hiring engineer with lack of some needed skill, because manager in such case could be blamed for not taking test. It's just I wanted to tell.
    – alexb
    Commented May 16, 2011 at 20:33
  • What I could additionally tell is: if test doesn't take much time, I'd recommend just to take it, that should impede + some useful info could be retrieved.
    – alexb
    Commented May 16, 2011 at 20:35
  • 1
    @alexb I don't disagree with you. More information is better than less, eliminating risk is better then having risk, however the poster clearly has a short time frame and wants to make a decision based upon the limited information he has, therefore if taking the test isn't going to add much then it is not very useful here. If we had unlimited information then decisions would be easy. Being able to make good decisions on limited information is valuable.
    – Gratzy
    Commented May 16, 2011 at 20:43

I don't see a strong argument to skip the test. Therefore you should keep it.

If you believe that the candidate will balk at having to take a test, that is telling in and of itself.

If the test takes so long to administer and check that it means the hiring decision is delayed, then you likely need to review the test itself.

Conversely, if you are planning to hire the person no matter the outcome, then go ahead without it, but then you should likely revisit the testing policy again and make it explicitly optional.

  • Good point about the test (not the result) being an issue. Definitely make sure that the test is appropriate.
    – ChrisF
    Commented May 16, 2011 at 22:22

Is the technical test generally useful or BS? Do you want to skip it because you want him hired faster, because you're afraid of getting a roadblock to the hire you want, or because you are afraid it might offend him?

As a general rule of thumb I like making rules rules. Because if you start making exceptions for one person, then you should start making exceptions more and more until you get burned and learn why the rule exists. And trust me, a bad hire is a really painful mistake to make. But that is only true if the rule is useful. Whether this rule is useful, depends on the technical test.

Secondly, no matter how much pressure you feel under to hire, don't let that push you into making a rush decision. Haste pushes us to say yes when we shouldn't, ignore warning signs, etc. In fact the more pressure you are under, the more you need to push back on that pressure to be sure you make the right decision.

Thirdly if you have a nagging voice saying, "I'm afraid that, everything else notwithstanding, he might not pass the test" then listen to that voice - don't skip the test. This might not be the right hire.

And lastly, if the candidate is good not only will the candidate not be offended by having to take a technical test, the candidate will likely see it as a good sign about your organization. It is item 11 in the widely quoted Joel test. After all they've had the displeasure of working with developers who wouldn't have passed a technical test, and probably don't want to repeat that experience.

For all of those reasons you should give the test if (and this is an important if) the test is not an obvious piece of BS that should be replaced with a useful technical test.

  • Mostly BS, with mostly no relevance for the job. The HR asks C# questions but we are mostly a Java/Unix house (don't laugh - they bought the tests from an hiring consultant). As I have commented above - it was not "real code" asked during the interview but pseudo-code and some UML scketches. Commented May 16, 2011 at 18:16
  • 1
    @Daniel Voina - Will this person be in a coding job, or an architecture job? If a coding job you need to have the person write code in the interview. Seriously. If the candidate balks at that, you need to know this before you hire.
    – btilly
    Commented May 16, 2011 at 19:36
  • Both. I expect him to develop. I expect him to come with solutions either at design/architecture level as well as code them. I think that the 2nd is naturally implied by the SCJP + previous experience + reccomendations Commented May 16, 2011 at 19:44
  • @Daniel Voina - Then you definitely need to test it. Some very experienced, otherwise very good, candidates develop an attitude that coding is somehow beneath them. They can be great in a pure architecture role if a pure architecture role makes sense for you. But if you hire one and then ask them to code, you'll get no end of resentment and problems. You therefore need to look for this in the interview process.
    – btilly
    Commented May 16, 2011 at 20:50

We were recently in the same situation. We skipped the deep technical because in the initial he seemed to have read all the right books and worked on all the right types of projects. He seemed really good.

Then after a couple of weeks it became apparent he wasn't able to actually code at the level his interview said he should. And his personality didn't fit with the team. It was a mess to get rid of him and clean up what he had done.

Do the technical before hiring anyone.


Keep the test for the sake of fairness. If other new-hires later learn that they had to write a test but this guy didn't, it could cause feelings of resentment.

The test should be applied to everyone or to no-one. If you want to apply it selectively, make sure there is a clear and written policy explaining when it can be waived.


The values of technical tests are varied and is largely dependent on how well the tests are matched to the role the senior developer is being hired for. I mean, would you give a list of questions about embedded system engineering to a Oracle developer (this is a bad example to prove a point).

Even if the senior developer scores poorly in the technical test, would it be an obstacle for you to hire the candidate?

As you mentioned that you are pressed for time, don't rush the decision because of it. It will be worse if the senior developer turns out to be someone that is below par in his area of responsibilities and ends up putting the project behind schedule.


Turn it around.

If it's a permanent senior hire who comes highly recommended by people you trust, he/she may well end up on future interview teams. Ask this potential senior developer for their favorite technical interview test questions, and how they might rate the strengths and weaknesses of various answers. Maybe make up some new bad answers to test them. You might even learn a lot from this use of your time (or possibly find something that's a red flag).

Then checkmark some of the answers to their own questions as "technical test done".


Think of it this way - what's the difference between hiring someone excellent a bit later than you'd like, or hiring someone potentially awful right now?

Also, how capable would you say you are of doing the job this test was designed to evaluate for?

I work for a company that requires about 99% of candidates to pass a programming test. The 1% who aren't required to pass fall into two categories. The first category are "rockstar" types that we've actively recruited from the get-go. The second, and probably more relevant, category are people for whom the process has been waived by senior personnel who have a very strong track record hiring and who are capable of performing the job they're hiring for.

Personally, I think this is a good policy, and I'd recommend it for your situation.


I would give the test anyway. He might be recommended for any number of reasons (some which might not be all that beneficial for you...). One benefit of the technical interview is to begin the bonding process with the other team members. Don't underestimate the need of the team to get bought into the hiring process.


Given HR's restrictions, I think I would download a copy of cyber-dojo, install it on a local server, sit your candidate in front of a web browser which can only access that server and ask them to complete several kata's (of your chosing) in a language of their choosing (ideally a different language per kata).

Then look at the sequence of traffic lights. If they are a good TDD developer, you should get a nice repeated red/green progression.

If you want to have a play with cyber-dojo, the author has a nice online version here.

  • hmmm... nice tool. I was considering Codility codility.com but this one is free. Thanks! Commented May 17, 2011 at 20:11

Another question - how much confidence do you have in your HR department.

I may be drinking too much psychedelic KoolAid over here, but I've often been pleasantly surprised to find out that my HR department had a good plan in mind when implementing a given protection measure for hiring. For example, it sounds like it's true that your senior guy is going to be needed for Oracle, and not for C#, so a C# test seems irrelevant. But if your HR department is very sensitive to how difficult it can be to fire someone when they can't hit the mark across several different projects, then your short term need for someone may be trumped by the long term need to make sure that every developer could meet some minimum competency in a widely used programming language.

It all has to do with your current hiring methodology, the laws governing your company, and the needs for technical skills across the board. In some companies the setup of things like a probation period make it easy to go for a trial run with someone and then let them go if it doesn't work out in the first 3 months. In other companies, the minute someone walks in the door as a permanent employee, they are subject to massive fair treatment protections that means that you have to retain and retrain them for a long time before you can get rid of someone who doesn't measure up.

I'd check around your company and see if there's a reason to do some level of diligence even though this guy doesn't need to demonstrate these skills in the short term. The long term ramifications - especially at the salary rate of a senior engineer - can be huge.

  • Frankly? Not much. Thet seem decoupled from technology and are, maybe unintentionally, not following the local IT market trends. Commented May 16, 2011 at 19:48
  • @Daniel Voina - Have you tried firing someone before? Commented May 17, 2011 at 13:52
  • I even succeded. Commented May 17, 2011 at 14:02
  • @Daniel Voina - great... but I've seen situations where it's taken 6 months to 1.5 years to fire someone. Given the pain and suffering involved not just for the person and the people directly managing them, but on the entire team, I'd say there's a valid point to making the person jump through some seemingly unnecessary hoops, especially if it's part of a CYA mechanism. Commented May 17, 2011 at 14:09

You have repeated multiple times that deadlines are looming - I am assuming you know about Brook's law.

Having said that, here you should see what kind of delay the actual interviewing process might cause. If he is a very competent candidate that you think can jump in and fix your deadline issues on the run, then he should have no issues in spending a couple of hours interviewing/pair programming. Another factor to consider would be your current peers. You don't want to give a feeling to your larger team that people enter/leave according to your whims - because it usually reflects bad if the guy conks out. This is one main reason why HR insists on multiple interviews so that one person doesn't hold sway on suc.

Good luck with the hiring and the project!

  • Deadlines are coming in about 5 months. I do not expect super powers from him, just be able to handle new features, understand the present codebase, be familiar with some of the technologies and be able to correct bugs if necessary. Deadlines are my problem and I want to hire in order to keep them as much as possible without consuming the team too much. The guys from my team know him better then I do - they worked together at another company. Commented May 17, 2011 at 7:01
  • Then that means you are assuming he will be able to hit the ground running. Why don't you do a 1hr pair programming session and make a decision? Commented May 17, 2011 at 8:56
  • I had in mind to give him a problem and get a solution in a couple of days (solution = code + tests). Pair programming would also be excelent. The problem is if I do not hire I might loose the window of opportunity - the guy is headhunted y others as well. What bothers me is that I cannot keep him in town (he currently lives elsewhere) longer, until HR decides that the hiring test is ok. I think I'll follow my guts after all. Commented May 17, 2011 at 9:52
  • Unless you are trying to hire Richard stallman level person, I am sure there are other equivalent programmers:). But again, we have to follow our gut once in a while - So, as I said before, Good luck:). Do update this post on how it turned out later! Commented May 17, 2011 at 13:49

Usually as part of the contract you have six months as a trial period at the start of employment. If the candidate is completely incompetent then this will be quite obvious during these first few months and you at least have the option to terminate after their trial period. I would also make a point that no one can know everything and people often need time to grow into the role and indeed may be stepping up the career ladder so a little bit of time to settle in before making any judgement is always wise (from both parties!)


To be honest (and repeat my answer for another question), I myself would be wary of getting hired by a shop which didn't give me a technical interview. I'd doubt their commitment to technical excellence and would not like that fact that I wouldn't get the opportunity to "talk shop" with the team before making my decision.

Make the technical interview also an opportunity for the team members to get to know the guy, and for him to get to know them. Since the guy is senior, it is very important that you can communicate with him clearly on technical matters. How are you going to test it without an in-depth technical interview?

In short: if he's important enough to waive the standard technical interview for him, he's important enough to carry out a special technical interview with him.

Not the answer you're looking for? Browse other questions tagged or ask your own question.