For background, we are doing desktop engineering applications, with an AutoCAD like UI, something similar to etabs.

One thing that really bugs me is, is there any need to hire the very best developers? For starters, we are experiencing great difficulties in recruitment; most resumes we see are either doing simple CRUD apps, or SharePoint customization which I don't think really involves a lot of hardcore programming. Even those whom we call for interview, most can't do Fibonacci sequence and a simple binary search, and we are gracious enough to give out hints and spell out the problems explicitly so that the candidates don't have to lookup a dictionary to check what does "Fibonacci sequence" mean.

This got me thinking: Yes, we do need some level of programming aptitude when doing computational geometry/ linear programming stuff, and we do need some level of programming aptitude when designing the software architecture/ or deciding which software pattern to use, but beyond that, a lot of our code are just plumbing code ( I think), which can be done by someone with some familiarity with programming.

Given that we really need programming talents now, and given that hiring superstar developers are very hard, I want to lower my standard and hire only the so-so ones, in direct contradiction to what Joel preaches.

What do you think?

Edit: You don't need to rewrite the whole computational geometry/linear programming libraries; all you need to do, as far as my application is concerned, is to be able to know how to cast the problems at hand into appropriate computational geometrical/linear programming terms and know when/how to use the existing libraries. So it's not as difficult as it seems.

  • 53
    Standard answer: maybe you're offering too low salaries and better devs are not interested in working for you? Anyway, if you have problems with people unable to do binary search, than it's not a problem with the lack of superstars, an ordinary run-of-the-mill coder should be able to do it.
    – quant_dev
    Apr 29, 2011 at 8:37
  • 15
    Your title capitalization makes me read it as P A N D A :)
    – cthom06
    Apr 29, 2011 at 15:46
  • 13
    They can't write Fibonacci sequence? That is in no way difficult... these people can't actually be programmers.
    – Ben B.
    Apr 29, 2011 at 23:22
  • 6
    Graviton, it all comes down to salary. If (just for example) you offered triple market value for salary, then you'd have people willing to leave their jobs to come work for you. I'm not suggesting that you offer THAT much, but it does illustrate the point. If you want good resumes, then you need to pay for it.
    – riwalk
    May 2, 2011 at 17:21
  • 7
    @user1525 because its something trivial, developers shouldn't normally have a problem implementing it (recursion or no recursion)
    – Darknight
    May 3, 2011 at 15:59

21 Answers 21


I suggest you stop reading Joel too much. What he has written in his blog contradicts with his responses on this site so I wouldn't really take his word for much.

What makes a superstar and why it is necessary to have one opens a long and a nowhere-going discussion. It is elitism and it is not practical.

What you need is a person who:

  1. Would love to be doing what you are doing
  2. Would be a passionate enthusiastic programmer
  3. Would have the potential to learn what it takes to do your job right

The rest is of no importance.

You wouldn't believe how many young graduates are out there who want nothing else but to dive into this kind of a CS-strong project and never ever look at coding CRUD applications. A while back I was one of them, I practically dreamed of joining a project around compiler development but wasn't able to find one. Why not give a chance to one of them?

I do not believe AutoCAD was written by supermen. Most of the successful projects were done by people who simply wanted to get the thing done and they really wanted that.

most resumes we see are either doing simple CRUD apps, or SharePoint customization

What is to expect if most jobs require just that? People might have studied CS at the uni and even have been really good at it, but you can't expect them to remember it if they have never used that in practical programming in 10 years. Obviously nobody is going to be reading over old CS books every year just to keep it fresh if this knowledge is not used anywhere.

  • 11
    Amazing answer!
    – user2567
    Apr 29, 2011 at 7:18
  • 33
    Yeah fine, but I've worked with passionate enthusiastic people who have not got a clue. They are a dead weight, and you do not want them in your organisation. So some BASIC aptitude tests to weed out the really dumb schmucks is a very good thing to do. Apr 29, 2011 at 7:47
  • 3
    The last paragraph describes me to a tee.
    – ozz
    Apr 29, 2011 at 8:23
  • 20
    Seen a lot of "aptitude tests" that were utterly useless, even had glaring errors (and pointing them out made you fail the test, when finding and pointing out errors is part of our job as developers...).
    – jwenting
    Apr 29, 2011 at 12:23
  • 2
    @Developer Art, perhaps that was lucky for you? If you couldn't convince them of the wrongness of an interview question, imagine what troubles you would have on the job. May 2, 2011 at 15:23

A book that I really like is First break all the rules. It has a lot of information about the differences between average managers and good managers. One of the key insights that good managers said over and over again was summed up by one of them in the sentence, I've never waited too long to find the right hire, and I've never fired the wrong hire fast enough. Yes, it is frustrating to take a long time to hire, but it is worth while.

A second point that you should keep in mind is that when measured on project throughput, there is a productivity peak for teams of 5-8 people. You don't get back to the same productivity until you have a team of over 20 people. Be very, very cautious about growing a team past the size where small team dynamics work. And if you're going to stay below that threshold, then you really want those 5-8 people to be good.

Both points speak strongly towards holding out for the right hire.

  • 2
    +1 for that quote. It mirrors perfectly what I've come to realize over the last few years.
    – Kris
    Apr 29, 2011 at 12:43
  • what's interesting with the 5-8 peak, is that as soon as you get 10 people, you can just split :) Of course, the work needs be splitted too, and preferably not randomly... May 2, 2011 at 19:33
  • @mattieu-m: A lot of people have that theory. If the two groups actually wind up needing to interact heavily, then it doesn't work. If they can be given truly separate concerns, then it works well.
    – btilly
    May 2, 2011 at 20:58

Everyone claims to "hire only the top 1 percentile". If that were true, 100% of employed people would all be in the "top 1 percentile" of all people, so 99% of all people would be unemployed (in any given field). As this is clearly not the case, and we've all experienced people who're clearly not in that group (why else do you ask this question at all...) we know this isn't true.

In fact organisations made up solely of such people would be highly unstable. Too much ego, too many conflicting ideas. It'd either fall apart as everyone does his own thing, bog down in never ending theoretical discussions about the relative merits of everything, or evolve into a constant shouting match as sentiments flare whenever a decision has to be made.

  • 13
    The trouble is, just because you hire only the top 1% of candidates who apply to you doesn't mean that you are hiring the top 1% of developers. 8') A far as *superheros go, they are frequencty considered a problem for the rest of the team. One person working at 200% but reducing 5 people to 50% isn't a net gain.
    – Mark Booth
    Apr 29, 2011 at 12:03
  • 2
    +1: Statistically, most people are within a few percentage points of the mean. Anyone who doesn't appreciate that is living in a dream world. And you're absolutely right: people who are too far from the mean are disruptive, whether they're above or below average in ability. Apr 29, 2011 at 13:33
  • 5
    @Satanicpuppy: Statistically, given a normal distribution about two-thirds of the people are within one standard deviation from the mean, and something like 98% are within two standard deviations. This says nothing about what the standard deviation is, or in fact if any arbitrary distribution is normal. Programming ability among programmers is definitely skewed, and could even be the right tail of a normal distribution. Apr 29, 2011 at 14:52
  • 11
    A main reason why programming talent among programmers might be skewed and/or the right tail of a normal distribution would be if programming talent in human beings were normally distributed. The sub-sample of human beings who become programmers is a biased sample of that distribution; that is, the people who are average or worse at programming rarely become programmers. This could make an "average" programmer have above average talent relative to the population in general, and it could also make programmer distribution talent look like the right tail of a normal distribution. Apr 29, 2011 at 16:37
  • 2
    @david: "Nobody can be that far below average"? I wish I worked where you work. Apr 29, 2011 at 21:30

The first thing you need to ask is why you're getting resumes that aren't up to the standards you want. I've worked with a lot of good people, so they're out there, and the application sounds very interesting to me. If you can't get people who can do Fibonacci sequences and binary search (which is more difficult than it seems; according to Knuth it was several years between its first publication and its first correct publication), you're doing something to drive the good ones away.

Are you asking for more skill than you're willing to pay for? Are you advertising in the wrong places? Is your company unattractive by location or reputation? This is your first and most basic problem, and the one you urgently need to solve. You and your colleagues doubtless know some good people who aren't working for you. Show them what you've got, and ask them whether they'd be tempted, and if not why not. You may be too close to the problem to understand it unaided.

Don't hire people because they're the best that applied. Hire people because they will be able to do something you want done. If you hire mediocre because that's all that applies, then you're slowly going to lose good people, and you're going to wind up with people whose algebra is shaky trying to do things with computational geometry. (Hiring mediocre because you have a job for a couple of mediocre programmers is another thing, but you have to be able to hire quality people where you need them.)

  • 7
    Because HR departments are vastly incompetent at screening software candidates. Requirements: 10 years in coffee script, 40 years of programming PHP, education: B.S./B.A.
    – Incognito
    May 3, 2011 at 13:24
  • 1
    @user1525: It could very well be HR incompetence, but the important point is to find out why and how to correct it (or find that it isn't correctable, so it's clear that it's time to jump ship). I wouldn't jump to conclusions. Your answer does suggest another approach: have good people submit resumes and see what HR does with them. May 3, 2011 at 13:50

"most can't do Fibonacci sequence and a simple binary search"

Your criteria are certainly wrong. In my group we are all physicists or engineers. I bet nobody could do binary search because we did not attend CS courses and in true life we use a library for that. I would even say: someone who writes binsearch himself does not know how to focus on important things.

It is of much greater importance, if the candidate is smart and fits into the group. If you want to check his programming talent, give him/her a job to do at home. Note how long it took him/her and discuss the results to find out if it is the candidates genuine work.

  • 3
    It may not be expected that the applicant get the binary search exactly right, but if you can give the applicant some hints, he or she should be able to get close. IMO, it's more interesting to see how people try to solve challenges presented to them than for them to have an encyclopedia in their head. May 3, 2011 at 18:24
  • 11
    I'm a physicist by training and I can do binary search blindfolded and with one hand tied behind my back. Sorry, but not knowing how write a simple binary search implementation is... poor. No other word to describe it, just poor.
    – quant_dev
    May 4, 2011 at 6:10
  • yes, you are right. Binary search, at least the basic idea, could be done indeed. I can do it too.
    – michael
    May 4, 2011 at 13:11
  • ... at least the basic idea (although I could not do Fibonacci without first looking up what it was). But a test like this puts people in advantage who just attended cs classes or simply prepared the questions accidentally. It is more useful to give candidates a real world programming example. It shows how they solve more complex problems without immediate pressure and it might also show the candidates, what kind of work you expect them to do (pick a good example). Much more useful than textbook questions IMHO.
    – michael
    May 4, 2011 at 13:19
  • 2
    Not knowing the definition of the Fibonacci sequence off the top of their head isn't worrying. BUT, being unable to write a program to compute it after it has been explained is worrying (even if all you expect them to do is compute subtotals in a simple CRUD app!). Oct 20, 2011 at 2:33

I think that "hiring the best" is becoming too much of a cult.

Most programming work is routine and not creative. Even when working on really creative new projects. Most of it is humdrum, and often based on patterns. this is particularly true for UI.

Most modern systems also require so many people to write them, that inherently, they all can't be the best. Most people are average, even if they are not, they still have to do lots of "average" person's tasks.

That being said, demanding basic competency and minimum sensible requirements is not unreasonable and not something that you should compromise on.

Think about routine surgery: Depending on your risk tolerance, you would probably prefer to have an average doctor perform it rather than wait 10 years for the Dean of the medical school to have time to do it. That does not mean you should let the orderly perform the surgery.

  • Not to quibble... but the "average" doctor, who has performed hundreds or thousands of that type of surgery might be preferable to the Dean of the medical school who may have more knowledge but not nearly the experience
    – JoelFan
    Sep 14, 2011 at 11:47

"Hiring the best" tends to mean "hiring the best that are currently available roughly where we are" anyway, and means different things to different companies. Some want rockstar coders, others want meticulous software engineers and the next one down the road wants experienced software craftsmen. There is no "universal best", so keep that in mind, and maybe your job spec suggests you're looking for one type of programmer and the interview says you're looking for another type programmer. Suddenly, you don't get matches.

That said, I don't like working with so-so programmers. So-so hasn't got anything to do with experience (they might have been programming for 20 years and still aren't very good at it), but everything to do with aptitude and enthusiasm. If the so-so affects either of those two, you have an issue. There's also no point in hiring someone whose contributions need to be reworked by other members of the team because they code isn't good enough. More bums on seats isn't always in the answer, more bums on seats can unfortunately also mean more work for the better members of the team as they're trying to do their jobs and clean up the mess the so-so programmer has delivered.

Some people don't come across as rockstars, but are solid mid-level programmers. They're good to have on the team and that's not what I mean with "so-so programmer". The latter is someone who barely avoids getting fired every year at performance review time.

  • 1
    ugh, even the term "rockstar programmer" makes me want to puke.
    – ozz
    May 3, 2011 at 14:04

As a Manager type, I agree hiring "the top 1%" isn't practical, and isn't necessary. My advice would be to hire the right team to build and maintain your product (might be two very different teams, as build vs maintain are very different in their needs)

I would strongly suggest that you identify the people you currently have on your team who are "key people" (e.g. get things done, have good attitudes, can work with uncertainty/high level requirements well, etc.) and then hire people they have worked with in the past (and respect, obviously). This eliminates lots of the uncertainty around the interview process, and helps gel the team.

Also, more "longer term" - invest heavily in an intern program. If your programming team is 20 people, get 5 interns a year and give them real work. Bring back the one or two you like each year and bring in 5 more random variables. This is probably the best way to keep your team filled with good programmers. You can then hire outside opportunistically, and raise the bar for those candidates.

As has already been mentioned, pay attention to your interview process. Make candidates write code (or better, walk through their solution to a "1 hour take home" problem) make them eat lunch with the team. Get to know their technical and interpersonal skills. And never be afraid to say "no" even when you are desperate for 20 more people for a big project that starts next week.


In my experience Paretto Principle applies to programming too: 80% of the work is accomplished by 20% of the developers and vice versa. OK the numbers may be exaggerated. In reality you will have something like 20% of the employees doing 50% of the work (by work I mean good work, not merely lines of code). It's actually more like a bell curve. So in a team of 10, you will have 1 hero, 2 great guys, 4 average and 2-3 pathetic ones.

A lot of companies use the Bell curve to weigh appraisals. So pretty much no matter how bright your candidates are they will fall into their levels. You cannot have a team where everyone is at the same level. Doesn't happen.

  • 2
    +1, I agree. But I think the question is: Do you need the "pathetic ones" (e.g. for team morale or whatever) or would the team do as good without them? And can you recognize them in a job interview?
    – nikie
    Apr 29, 2011 at 7:39
  • 10
    Define pathetic. If they are good plodders who do the boring grunt work but can't come up the the leap-of-wonder, you still them. But if they are just hopeless and can't do anything, then they are a waste of space. Apr 29, 2011 at 7:49
  • The only reason for keeping the pathetic ones is that you cant get someone better to replace them. They do what we call "donkey's work": minor or massive changes that do not need much thought.
    – DPD
    Apr 29, 2011 at 8:22
  • 1
    Is it possible to find them in the interview. Yes depending on the interviewer's skills. I let them handrun a few texbook programs and problems. If they pass this level i give them some more complex problems to judge if they can think. Pathetic ones may be good at syntax but it is only becuase they learn it by rote without really understanding it. They will flop at problem solving. Some will pretty much tell you that they cannot think on their own and can only work in Ctrl+C, Ctrl+V language
    – DPD
    Apr 29, 2011 at 8:29
  • 4
    Donkey work drones at least do work. Its when they want to re-write 10 years of developed stuff in Haskell with a couple of links to OCaml, in 3 weeks, and everything else they touch turns to cr*p. Then you REALLY DONT WANT THEM! Apr 29, 2011 at 9:27

There's already a bunch of answers here but I think there's still a point that needs discussing: the impact that hiring the so-so guys has on your software quality and how it makes your life as a manager much harder.

The answer to "is there any need to hire the very best developers?" is always a big fat YES. Of course in reality, this is not always possible. The dangerous mistake that I think you are doing by even considering this question is to think "our software is so simple even a so-so guy can do it". This is WRONG.

Your software will get done, don't doubt that, but expect very different results from an excellent team than from a so-so team. You'll have more bugs, more performance problems, more maintainability and scalability problems, and so on. You'll have to babysit your so-so guys through more complex problems. You'll have to babysit the so-so guys though proper architecture decisions.

If you accept this, and are ready to manage this, that's ok. Just be prepared for the process and for the results.

  • +1. Yes. The idea that you can hire guys who can't even write a binary search with help and have them be anything other than pure dead weight - net negative producers, probably - is utterly ridiculous. May 17, 2011 at 15:59

I think it is not really a problem to hire great developer. The real challenge is to make them want to work for you.

Is there any need to hire the best ones?
I believe so. Great developer is not only the one that get everything done on time. Not only such an individual is way more productive than others. Great developer is also leading by example and simply put inspiring to other team members. Other could greatly advanced while working with them.

OK, so you are going to lower your standards. That's cool, probably you will change your mind after you hire some really lousy individual. The one that will answer all your CS questions flawlessly but who cannot really write one single line of production code. Good luck with that :)


Lets take a step back.

What are we trying to do? Write software.

Why do we think we need to hire the best? Because that freakin' Arnold kid couldn't hack his way out of a wet paper bag and now the SQL is all screwed up and I can't log in.

Okay, so what is the best? I don't know, he's probably someone who wants a lot of money and has a resume six feet long with a great portfolio and worked at google or something. He should have a degree, and maybe some letters at the end of his name. Yeah, that sounds like the best to me, and by the best, I mean someone who isn't that freakin' Arnold kid. Oh, and he should know how to do some really hard crap I heard about in school like "write a bubble sort" or whatever they call it. I'll ask one of the other guys to name a few tricky things they had to do in school, yeah.

Sounds like you just don't want that freakin' Arnold kid? Would you? I'm tired of having buggy code, stuff takes forever to get done, and these new guys I interview tell me I need to re-write everything!

Right, so what do you ask the freakin' Arnold kid to do? Create a PHP website, write some jQuery, have the PHP do some basic CRUD with MSSQL, and change the background colours around.

Does that sound like a task well suited exclusively to the very best? I'm sure the best could do it, but probably anyone who's got the right skillset that matches this could do this.

So, you don't need the best? Right, I just need someone with the skillset that meets my goals.

Oh. Yeah.

  • @user1525, it's not a CRUD app. It's engineering software.
    – Graviton
    May 4, 2011 at 4:09
  • Not always. A lot of jobs out there don't require any knowledge of data structures, algorithms, or computational complexity. Sure, they're not the jobs at google search, but there's a huge demand for that. Just look at most postings on job boards, "I need a jquery plugin" or "give me an iphone app that looks like these psd's". People either want the best or the cheapest.
    – Incognito
    May 4, 2011 at 13:11

Your question title mentions a "Normal Desktop Application", but your text talks about needing to apply knowledge of computational geometry and linear programming. Those are applications areas that have spawned huge, multi-decade research programs with massive societal consequences of any advance (recall, linear programming abstracts resource allocation). As a result, there are a lot of sophisticated approaches to solving problems in these areas that work very well.

A bad hire

  • may not have even heard of these classes of problems,
  • might not be familiar with the common solutions,
  • probably wouldn't know about the better stuff that's out there (hint: most undergrads never hear about the fancy stuff, if they hear about the problems at all), and
  • almost certainly would take ages to implement such things (considering that I've seen some of them give an entire graduate seminar in data structures fits, professor included).

In other words, think about whether you're really working on something pedestrian. If you are, great, hiring should be much easier. If you're not, hold out for someone who can do what you need.

  • you don't need to rewrite the whole computational geometry/linear programming libraries; all you need to do, as far as my application is concerned, is to be able to know how to cast the problems at hand into appropriate computational geometrical/linear programming terms and know when/how to use the existing libraries.
    – Graviton
    May 4, 2011 at 10:25

Surely I'm not a superstar programmer by Joel's standards. Nonetheless I have written quite some successful projects in my 20 years career as a developer. I could have solved your questions. But less from my experience at work, where in fact a lot of the more complicated work is done by asking your database or a library function to do it.

But if you decide to hire less experienced people, you should consider using technologies that are easy to handle. For example if you planned to use C++ for the whole project, then limit the C++ part to libraries written by your best people and let the others implement the user interface in Visual Basic.


Write down the values you search in an employee who will join your ranks.

When the only appreciated value is programming competence you will find yourself quickly surrounded by people who value just that. Since most truly competent programmers have a more elaborate value system, they will refrain from joining your team.

However, it is more likely you are searching for innovative, creative, trustworthy, erudite, curious, self-learning, sociable, competent and dedicated people. Show that your company understands and respects these values and is willing to help its employees develop them further.

Understand and embrace the values of your current employees and communicate them in your job applications. Good companies, with a sustainable value-system, attract good employees.

  • -1: if you said (and the OP talked about) money of course it would makes sense. I don't understand how this answer would helps him though. You're basically saying that he do not put enough marketing in his application if I understood right? Well, maybe that would help a small bit but I don't usually see a lot of highly competent people not putting at least a reasonable amount of value on .. duh .. competence ? .. like I said, replace "programming competence" with money and your answer makes a lot of sense but sorry I'm not getting it.
    – n1ckp
    May 3, 2011 at 1:33
  • If you don't understand my comment, maybe you should not mod it down. Anyways, what I mean is quite simple. Over time, I met quite some excellent programmers. They know their languages, algorithms, math, physics... However, what made them great in the first place was an interest in more than just the craft. They often value curiosity in themselves and in others. They see independent erudition as an important trait (or value) or they are inspired by those around them who are creative. Often, these values are more important than their income.
    – Dibbeke
    May 3, 2011 at 1:51
  • @Dibbeke: well I modded it down also partly because I don't see how this is related to the question. Nice rant though and I don't disagree with your last comment (although your answer is something else) but I still fail to see how it would help the OP or answer the actual question.
    – n1ckp
    May 3, 2011 at 3:25
  • @n1ck When you said marketing, I started wondering if basing a hiring process on basic values is really the same. I don't know, but I do recognize that building a social network of trust and respect is heavily influenced by it. This in turn influences the reputation of your company and helps you attract those top-notch software developers.
    – Dibbeke
    May 3, 2011 at 7:55
  • @Dibbeke: not sure if I got your last comment but I think I agree at least a little with you. But again, I'm not sure it is helpful to the OP (although I see more how it is related to the question now). What makes me say that is he never talked anything about his company, so yes maybe it could be a cause that his company has bad reputation, but I think you're jumping to conclusions ..
    – n1ckp
    May 3, 2011 at 12:45

In any organisation you have people with more experience and people with less. Not only that, but an expert in one field can be a novice in another. Sure an enthusiastic amateur can do more harm than good to a code base, but that's how they get to learn - from fixing their mistakes and discussing their experience with their more experienced colleagues.

My suggestion would be that rather than trying to hire superstars, you try to hire people who are reasonably bright, will fit in with your company culture, are keen to learn and have an appreciation of their own limitations.


Certainly you should aspire to hire only the best. That doesn't automatically mean you'll be successful at it - there's only so many of "the best" to go around, and there will be winners and losers in the battle to attract them. Much of it will come from your aptitude and willingness to work hard at the problem, and the resources available to you.

Giving up before you begin is the surest way to lose.


Binary search is an interesting problem because it is well known that most programmers will actually struggle to write it correctly (Bently writes about it in Programming Pearls). Perhaps it's not so bad to test for it so long as you aren't ruling out candidates based on their failure to solve it. If they solve it quickly and correctly then at least it hints at what type of programmer they are so you have more information in that particular case.


you do need to hire the best. but the term has been quoted out of context many times. you need to find the best candidate with the skills required for that position, and not the best programmer in an overall sense. Software development is broad and not every position requires the same technical knowledge.

Ask yourself this question ( you kinda already did..): If you have another engineer in the same position for 5 years, would you expect her to remember fibonanci series and binary searches?

if the answer is no, then change your interview pattern. May be you need to know a dozen search algorithms if you want to work on a search application like google or bing. Everyone else just uses map.get("");

target your interviews to what the position needs , not a textbook-generic good programmer.


If you really don't care about quality then I'd suggest using one of the outsourcing websites and starting with small projects. Then you can pay them if they can do the work, and have an easy way to bail if they can't.

However, I question whether there is really much routine coding in a desktop engineering application. They can be very complex, and most programmers aren't that good at managing complexity. You could easily create a lot of instant legacy code that will tie up your team for years to come. In general, the first hires for a new project are the most crucial and will set the tone for the whole project.


I totally agree with most of the comments above that refer to fitting a person to a problem. This usually results in a long term relationship rather than hiring a superstar to work on a regular problem - which will just frustrate him to leave quickly.
Having said that, You should always try to hire for your company rather than a particular position. Because this same guy is going to switch between teams sooner or later with personal contacts etc. and he might turn out to be a deadweight somewhere else. Ensure your company has very strict internal transfer guidelines and that you have a clear picture of what you will do in your team for the next couple of years before hiring a person who you think might not meet the company bar (but will solve the current problem). I have seen too many cases where mediocrity in developers has made the team work extra hard to fit around them.

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