How long does it take for you to determine if someone is going to be a good developer?

Question

I think you can tell within a very short amount of time in terms of people's problem solving abilities, ability to think in different layers of abstraction, in asking good questions... do you agree?

Answer 1

If they are already experienced programmers, yes. Otherwise, no. Problem solving and all that can be taught, but as all things, other people will perform better than others. So if someone isn't able to do all that, it may just be because they've never been taught this.

Answer 2

The people can learn things faster because in software they learn subject practically by writing programs rather than reading theory.When they apply practically they develop lot of qualities inside them.

Answer 3

I look for "issue ownership" i.e. whether the person is able to step up to the plate and says: "yes , let me have a shot at this. I think I can do it".

Languages can be taught but attitude is difficult to correct.

Answer 4

I think that you can determine within the space of 20 - 30 minutes of talking to someone whether they are 'naturally talented' at the attributes that would make for a good programmer in general.

Talking to someone though, just generally doesn't cut it I've found. We always technically test our candidates for new roles, with a 90 minute written theory and 90 minute practical build a working program style test. The benefit of this, is that it not only gives us an idea of whether they have a natural ability, it gives us an idea of where their strengths and weakness are (or even whether they really can touch type).

There are people however, that may not be as naturally talented but are willing to work hard to improve some of the skills that they need (this can be harder to determine this type of person I think).

You need to make sure you are clear what you are looking for, and the attributes that fit. Not all programming jobs are the same, and the qualities you may want for an ace coder to build the latest Facebook, could be different from the qualities you want in somenoe maintaining a legacy system. As long as you are clear, you will find the answer faster.

Answer 5

As I see it, there are two distinct questions here:

How long does it take for you to determine if someone is going to be a good developer?

vs

I think you can tell within a very short amount of time in terms of people's problem solving abilities, ability to think in different layers of abstraction, in asking good questions...

I've worked with people who were outstandingly good problem solvers - their solutions were brilliant - but, as developers, they were mediocre to poor.

Knowing if someone is a good problem solver - that I can work out pretty quickly if I'm working with them (noting that not everyone works well on interview-question style problems). A few hours at worst, sometimes in a few minutes.

Knowing if someone is a good developer takes longer - is their code consistent? Does it work? How quickly can they make changes to accommodate changing requirements? How easy is it to pick up their code? How quickly can they pick up someone elses code? Are they constantly working on improving their skills? Working this out can take weeks or months.

Answer 6

I think also important is, how determinated are they.

Do they give up quickly? Or do they try until the problem until it is solved?

When learning abilities and persistence go in hand, you're seeing a good potential developer.

Being persistent always help for problem solving.

Of course, achieving results is mandatory otherwise they will fit in the following demotivator phrase from Dispair Inc.

Winners never quit. Quitters never win. But if you never win and never quit then you're just stupid.

Answer 7

I've seen both good and bad developers in my workplace over the last few years. I can usually spot the bad ones within a few weeks. Of course, one must allow people to settle in and learn our specific domain. One must also accept that even for the good ones, reaching max. productivity will take time.

But there is one signal I usually spot very early: if they sit by themselves, apparently working, but getting nowhere, and don't ask for help, then I know we're in trouble. We've had a few of those. No one expects a new employee to be self-driven, but if they can't even ask for help, then they're doomed in my opinion.

In one case, we actually forced help upon the person after identifying the problem, and when even that didn't work, we were at a loss. Luckily, the individual decided to leave after a couple of months.

Answer 8

There seems to be a strong correlation between people who program for fun and people who are good at it. I am surprised at the number of programmers I've met in the industry that see it as little more than a paycheck, and are astounded that somebody might want to go home and program some more, just for fun.

So, I would say, ask what kind of projects they've been involved with in their free time.

Answer 9

According to Malcolm Gladwell in Blink, The Power of Thinking without Thinking, the amount of time it actually really takes for you to form your judgement on whether someone is a good developer or not is much less than you would think. You are far more likely to base your opinion on how someone looks or sounds, or reminds you of a favourite uncle, rather than their actual ability.

That is why basing your selection of candidates on an aptitude test before you see them is an excellent idea. It prevents you from pre-judging the results you get.

Of course, a candidate's people-skills are important too, but not as much as their technical ability. There's no point letting someone through an interview just because you like them if their technical ability is non-existent, but you don't want to work with an obnoxious, arrogant, rude but technically competent individual either.

Answer 10

From my own observation, the bad ones are identifiable by one or more of these symptoms:

Asks no questions the first week. I've never yet seen a program so well documented that someone new wouldn't have questions.

Doesn't ask for help when stuck.

Lays the blame on someone else when there is a problem - more focuses on finding someone else to blame than fixing the problem

Can't follow organizational standards

Does not undersand very basic concepts. I've seen a few programmers through the years that didn't understand IF - when you don't have basic understanding from your education and previous experience, I have found it unlikely you will ever be a programmer as your mind just doesn't work the right way. Most of these I've run into were right out of school or came in as Interns. They even had good grades. None survived a year in the industry.

Is asked to do some simple maintenance task and instead of spending an hour fixing the issue with the pull-down menu spends two weeks completely rewriting that part of the application. Often combined with the not asking questions thing, so they write the application missing some of the reasons why it was written a differnt way and now a working system that wasn't perfect doesn't work at all.

Inability to accept that someone else might have a better idea is a real flag as well.

They object to using source control or systems designed to manage work or quality.

The ones that turned out to be the best ones:

They dive right into the work and ask good questions. If there is an obvious solution that wasn't used, they ask why.

They deliver their work on time or they tell their boss if something has turned out to be more complicated that then orginal estimate and will be late.

They suggest improvements but don't try to shove them down everyone else's throat (especially by stealth development behind everyone else's back), they will consider other's ideas as well.

They admit fault when they are at fault and come up with a way to fix the problem

They make a real effort to understnad the whole system not just the little tiny part they are asked to work on. They make an effort to understand the business as well as the way the program works.

They want to use use things like source control because they undersand the benefits.

The manager can depend on them to create stuff that works (not bug free perhaps but certainly fewer and less obvious bugs than the less skilled developer.) Clearly their stuff has been unit tested whether this was a requirement of the company or not.

When given requirements for a new project, they will see and ask about obvious missing information rather than just trying to code to a bad requirement. So if the requirement says there must be an approval and this is what to do after it is approved, they will ask, "Hey what happens if it isn't approved?" rather than blindly follow the requirement.

Other people start to go to them for help troubleshooting a problem. When asked to do a code review, they will often actually see the code problems.

They learn from others and will teach others as well.

Answer 11

I've seen a guy who absolutely didn't know what he was doing turn into a developer good enough that he was on my shortlist the next time I had to staff a project. (And I had a pool of 50 or 60 people to choose from.) Why? Because he knew that he didn't know what he was doing, and he wasn't afraid to let me know that either.

I knew two things after the first time I met with him: 1) He was going to need a lot of handholding, and 2) if he had any aptitude at all for the job, he'd be good at it.

For the same project, I hired another guy because I'd seen him at work and he seemed to know what he was doing, and I needed a project manager. It took me three months to realize that he was doing nothing useful at all. He actually didn't know what he was doing, and that was something he kept to himself. If he'd come to me with that on day 2, instead of me coming to him with it on day 90, things would have turned out very differently.

My experience isn't vast. But it's given me a lot of faith in the importance of intellectual honesty to software development. It's not too hard to spot a tendency towards intellectual dishonesty, as long as you're looking for it.

Answer 12

My opinion is to become a good developer first thing depends on guidance of superior. Then their own interest.If the person having good interest in programming and his/her guidance is very good he/she will become a good developer.

Answer 13

While it is easy to tell the bad ones quickly, you need to see what people produce in order to determine how good they are.

"Good" needs to be defined also. Good for one team could be a terrible fit in another.

To me what matters is that the person is doing the job that you need him/her to do. They should be a contributor, someone who helps get things done, and does their work on time. You need to measure them against your standards to see if they are good enough for you. Hopefully you have milestones frequently enough that you can measure that in a reasonable time.

If they are new they should keep getting better. If they are not then they have probably reached their skill level.