September 14, 2015 at 9:36 pm
Comments posted to this topic are about the item Who's a Good Developer?
September 14, 2015 at 11:54 pm
Hi Steve,
There are several metrics that can be used:
1. How fast can an everyday problem be solved? Does a complex query take the DBA 30 minutes to do or 2 days?
2. How accurate/thorough is the work done? This is measured in code-reviews: after how many code-reviews, were changes made that made a difference to the data-output (rather than, say, to the speed or efficiency of the query)?
3. How efficient is the work done? Likewise, it is measured in code-reviews.
4. How extensive is the body of knowledge of the DBA? This is measured in how often a DBA must look something up. For example, if asked to implement, say, log-shipping, could it be done there-and-then or would the DBA need to go and read up about it first?
5. How complete is the body of knowledge of the DBA? About what does the DBA not know about? I know of Service Broker but never implemented it. There are surely many things that I don't know about. A complete checklist of the all features available within the SQL Server spectrum would be the way to go to measure that what is not even known about.
6. How interested is the DBA in learning more about technology? This can be measured yearly in new skills practiced and mastered.
All the best,
Sean Redmond.
September 15, 2015 at 1:33 am
I've interviewed loads of staff over the years including a few technically brilliant ones that were rejected unanimously by myself and whichever colleague was interviewing with me.
I've also worked with a few where they didn't particularly shine at the interview, produced a competent but not outstanding technical interview test but I'd work with them again without hesitation.
What made them stand out was their attitude and work ethic. They embodied a "keep calm and carry on" mentality. They were competent without being flashy, took on more than there fair share without complaining and could be trusted absolutely. If they didn't know something then they would say so and seek advice from their peers.
Who would you choose for the long haul, a technical whizz with low social skills or someone of slightly above average competence who fits well with a team?
September 15, 2015 at 1:37 am
David.Poole (9/15/2015)
I've interviewed loads of staff over the years including a few technically brilliant ones that were rejected unanimously by myself and whichever colleague was interviewing with me.
- Technically brilliant but would get eaten alive by developers
- Technically brilliant but would annoy the heck out of everyone
I've also worked with a few where they didn't particularly shine at the interview, produced a competent but not outstanding technical interview test but I'd work with them again without hesitation.
In other word, someone competent is someone that doesn't have higher cognitive ability than his recruiter (or is able to hide it well during the interview).
Thank God my last recruiter wasn't that shallow...
September 15, 2015 at 1:43 am
"Who's a Good Developer" is quite an open question and is best answered by answering the question "What do we want this person to do?"
For example, there are roles where a very methodical, accurate approach is the best even if this results in a slower development process compared to others. There are roles where frankly you don't give a damn about the quality of the code as long as it works according to certain metrics and is completed quickly (i.e. cheap) - you may not want to go back and edit this code later but there are projects where this isn't the primary issue. There are other roles where you have particularly hairy problems when you want a developer who can approach these problems from various angles, often unexpected ones, and produce clever solutions.
However, in general and as already noted above, you want somebody who fits in the team and company ethos, who is enthusiatic for the job and is not afraid to learn or to embrace new concepts and ideas. I'm sure we've all seen "dinosaurs" who have pretty much refused to do anything other than the way they've always done it even when shown better or more efficient ways to do it.
September 15, 2015 at 2:36 am
Kyrilluk (9/15/2015)
David.Poole (9/15/2015)
I've interviewed loads of staff over the years including a few technically brilliant ones that were rejected unanimously by myself and whichever colleague was interviewing with me.
- Technically brilliant but would get eaten alive by developers
- Technically brilliant but would annoy the heck out of everyone
I've also worked with a few where they didn't particularly shine at the interview, produced a competent but not outstanding technical interview test but I'd work with them again without hesitation.
In other word, someone competent is someone that doesn't have higher cognitive ability than his recruiter (or is able to hide it well during the interview).
Thank God my last recruiter wasn't that shallow...
I don't think that was David's point. There are clever folks who like to whinge about all the work they are given, who complain about everyone else, who are unhygienic or similar, or who try and introduce clever patterns or whatever into the middle of a perfectly serviceable project. This is disruptive and counter-productive - most of us have seen that sort of thing. Mercurial or thorough, you need people that can follow the style of an existing project and get the job done with minimal disruption.
September 15, 2015 at 4:40 am
"There are several metrics that can be used:
1. How fast can an everyday problem be solved? Does a complex query take the DBA 30 minutes to do or 2 days? "
A note of caution on the above, this is where work ethic is crucial. One DBA may only take 30 minutes, but then will they move straight on to the next task? Similarly a DBA who takes two days may be a keen learner and each time they tackle a complex query their solution time gets lower and lower... or they may always take 2 days...
I have always thought that a persons "current" technical ability is very over-rated. Skills that are common to most other jobs (team working, work ethic, discipline, ability to learn quickly etc) are still the most important for a developer as well IMO.
Ideally you want to trial a new employee, but then it is hard to get people to give up a secure job for a "trial" position somewhere new...
September 15, 2015 at 4:42 am
I don't believe you can measure quality without experience (i.e.: working with the person). It's silly to think you can with just an hour or two with someone during the interview process, so why try so hard?
We all have to make tough decisions. Is this someone who can do the job or not? Is this someone who is going to fit on our team or not? Etc. Everything can change when you actually do hire the person and put them on the team.
What I do believe is that not all DBA's, developers and so forth are created equally. Sometimes you get lucky and find a rockstar. But most of the time, I feel you have to create them. My job as a leader is to build good people to the best of my knowledge.
So, I tend to look for people who seem like they have their head on straight and who are both looking to learn and able to be trained. That way if they are not the best, we can help them get closer to being amazing through education and training because ultimately what we do is not brain surgery.
September 15, 2015 at 5:34 am
Having managed developers and architects in the past, I think some observable, measurable and repeatable traits can be used to differentiate a good developer from a mediocre developer.
The first one is easy: ask yourself this question, "Which developer would I turn to when needing to solve a complex problem in a crisis?"
The second question is also easy: "Who is the most reliable developer in terms of meeting requirements, bug free code and good analysis?"
The third question: "Who lives the team/company vision most of the time?"
I have had people work for me who were great at development but were bullies when it came to working with others on the team. I have had others who were thoughtful and although they appeared to be plodding through were actually doing the best development work. I have had others that were absolutely brilliant from a theory standpoint but could not face the computer screen long enough to do any coding worth the cost of employing them.
September 15, 2015 at 5:40 am
You're asking the wrong question.
The question of "What makes a good developer" is highly dependent upon your industry, your work environment, methodologies and a hundred or more other factors, to say nothing of the exact position you're hiring for. No single answer will suffice.
A better question as some have alluded to is "What makes a good employee for my company or team?" To be sure there's a certain skill set and/or education level you're looking for, but as just about everyone who has done hiring knows, that's just the beginning. I was initially hired to do desktop support. My boss chose me because I was the only one who mentioned I would try to go to a person's desk or remote in to actually see what was happening before trying to fix it. Since then I've pushed myself to learn nearly everything else. They actually like me. 😀
As far as skills go, I'd much rather hire someone who may not necessarily have the sharpest skills but is willing to listen and learn rather than the "expert" who just doesn't fit well into my team or company.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
September 15, 2015 at 6:04 am
I liked this article 15 Quick Short Interview Questions Useful When Hiring SQL Developers[/url]. While it is geared toward hiring how many developers can answer them on your teams? Granted you need to make sure you include relevance for the particular type of work that you do.
I agree with the comments on enthusiasm and most importantly discipline, I have a policy of no surprises. I also believe that being humble is a mark of a good developer. You never know when the issue is going to arise to bring you back into check. We were talking about tangible however. So provide the test, review their body of work over a period of time. Ask yourself how often they were there at the moment of crisis but not the one who created it. Finally I look at their aptitude for growth and what their desires are.
That sounds like a review, so I guess the my only way of determining who is a good developer is to spend my time in providing that ever important feedback. Then I will have an idea of if they are a good developer.
September 15, 2015 at 6:33 am
It is easier sometimes to identify the bad developers. As for good, not as easy. You may find that you have a hot shot developer that can literally throw the work out in lightening speed. This is great in getting stuff out there to visually see and test. The problem is, it is full of bugs. Fortunately you have another developer that is slow as molasses and could never get the code written as fast as your first developer. But thank goodness this slow guy exists because he/she can find and fix all the bugs. So as a team they can't be beat. Alone they each fail. Is one better than the other? Who cares.
September 15, 2015 at 6:41 am
"I suspect you'll find it to be a very abstract idea. Perhaps it's like pornography, where you know a good developer when you see them, but if so, then have you always been able to tell a good developer right away? In an interview?" PMLS, maybe an autocorrect on photography? Either way cheered me up no end
September 15, 2015 at 7:03 am
Then that would be a personality issue or a bad fit for a team. I've known such people.
A good interview takes note of the candidate's demeanor, social interaction, and (believable) responses to technical questions. Indeed...it is something of an art. Which is why its good to have more than one interviewer who can gauge either personality or proficiency.
September 15, 2015 at 7:27 am
Re: P0rn.
It's correct. It's a famous judicial line.
Viewing 15 posts - 1 through 15 (of 32 total)
You must be logged in to reply to this topic. Login to reply