July 1, 2010 at 9:16 pm
Comments posted to this topic are about the item Are We Not Testing Enough?
July 1, 2010 at 10:10 pm
I would start by having development managers who have a high enough level of competence to be able evaluate the talent of the people they hire.
However the way the world seems to be going is to hire whoever is willing to work for the least amount on money, regardless of their ability to produce professional level applications.
Eventually, the IT world may rediscover the idea of hiring people that have some idea what they are doing but that may take a long time to come around again.
July 1, 2010 at 11:50 pm
The testing which is done is often lacking because it tests for all the wrong things in all the wrong ways. Doing more of that only makes things worse. In recent years, the trend in computer science classes has been, and rightly so, to get students to think, design, consider, and only write code after that is done. Then, both on class examinations, and in these tests in job interviews, they are given a problem, asked to start coding right away, and to do so under pressure. Recently in an interview, I had a manager ask me to quickly write some code in C# involving the number of days between two dates. The only sensible way to do this is to use the datetime class, but naturally he said that he wanted me to do it the hard way, and oh by the way, do it quickly.
What's wrong with this picture? First of all, a good programmer needs to know about existing classes which get the job done with a lower probability of error. Secondly, if you find that you are spending a lot of time programming under pressure, that is a sure sign that the existing management is grossly incompetent and can't plan the project properly.
What we need, in the words of the late Commodore Grace Hopper, USNR, is leadership. You can't manage men into combat, you have to lead them. That holds true for development of software as well. And, you need programmers who know how to think creatively, not a bunch of robots that you can push buttons on.
July 2, 2010 at 12:01 am
No test can reveal how an employee would perform in the future. Some minimum standards are necessary, at least to weed out clearly unqualified people. Past experience, certificates, degrees, and so on, are just possible indicators and not the only ones for predicting future performance. Same goes for competence. Having credentials is one thing, but actually putting it good use for the problems at hand are a whole another thing. A lot also depends on how well organizations utilize unique skills in each person. Just like people, organizations also evolve and become better, or worse, at tapping into such skills.
July 2, 2010 at 1:25 am
I think some kind of technical programming test is essential for determining a base level of capability. Anyone can say they 'know SQL' in an applicaiton but does this mean 'SELECT * FROM Customers' or something more demanding? The interview is a good tool for finding out whether someone has the ability to learn, and as an employer it is important to see this as key to developing 'OK' staff into highly capable ones. And then of course they leave 🙂
July 2, 2010 at 1:43 am
Sometimes not testing programmers is a good thing - we've 'lost' a few employees who had no aptitude for programming at all!
July 2, 2010 at 2:09 am
I'm a believer in contract-to-hire. It gives everyone a chance to "kick the tires" and if it doesn't work out, you cut your losses. Oh sure, the contractor can walk away but so can your FTE. For the contractor, it's easy these days to explain away a 3-month stint (for example): "Oh, it was a 3-month contract." Enough said.
Three months is a comparatively small investment for a long-term hire and it's unlikely a huge amount of IP is going to walk out the door if it doesn't work out. It confuses me why people are hung-up on full-time positions. It's really an illusion for both sides.
James Stover, McDBA
July 2, 2010 at 2:20 am
There are plenty of books on this topic. Smart and Gets Things Done by Joel Spolsky is an excellent guide, covering the How and Who to hire. It very clearly articulates everything you probably knew or suspected already, but it acts as your base reference point. Happy hiring!
July 2, 2010 at 2:24 am
I think that the argument is skewed slightly towards the employer. Sure they should be trying to get the best person but some companies don't try hard enought to attract the best people.
You have to remember that companies are often interviewing because somebody left who wasn't satisfied with the job. Very rarely does the company try to figure out what that was before hiring someone else.
I've been to interviews where the tests and questions made you think you were going to work for google but the job paid slightly more than what I was on.
I honestly think you should be hiring people who will be stretched slightly or even massively, not people who will walk it, because they will get bored.
July 2, 2010 at 2:29 am
Hello everyone,
Sorry for the standard nonsense, but first post here, long time reader.
Anyway, as a a developer, and not a DBA *ducks from the thrown stones and bottles* I think there should definately be some testing for us, but as DBA's or any SQL roleis essentially company ciritical - there should be some form of testing.
However, this should be testing based upon experience. It's all very well having a standardised test that a person with 10+ years of experience can breaze through, but if you're dealing with somebody just out of University or College... well, that's clearly a different matter. And if your testing is too intense you could stand to potentially loose a very talented young asset, just because they don't yet have the experience.
On a personal note, I wasn't tested when I got my job. However that's because of my reasoning above, and I eventually went on to create the test we currently use (creating a simple ATM system in C#), and I did hear of one horror story of an experienced programmer wanting to google how to convert a string to an integer :w00t:
July 2, 2010 at 2:46 am
What type of position is it?
Junior or Senior?
As for Senior programmers who have been in the job for a while (and got it done), yes, for sure, do some testing and just see how they do it. Any manager worth his or her salt will just sit by, ask questions why but not suggesting a way of work. At least not if they want to evaluate skill.
In my last round of interviews the only interviews asking technical questions where not with the manager to be but with coworkers to be. Bringing along some of the output of my previous work and coding examples was worth more than 1000 words talked. Artists have portfolios - why have programmers not case studies with them? There are always things that are not confidential that can be copied and shown. I keep mine to around 3 sheets of paper - enough for an initial evaluation plus out of this come more questions how I work and questions I can ask too.
The best interview (and the subsequent job offer after the second round) just took 3 hours and it didn't feel like it.
As for Junior positions it's more the attitude than the skill that is important. In a recent hire situation we had some very specific requirements language wise so the pool of applicants was pretty scarce.
Fortunately we found someone who knew that he wasn't good as developer but was willing to learn. We decided this on a peer level as our manager let us "grill" the applicants. This person is after a year one of the most productive team members and still learning. His real strength is that he not only learns fast (bit enviable to me he can just learn by reading) but is open minded about approaches to development.
So for me the answer is "It depends". The only real thing out of this for me is that taking time pays off. I can understand that managers want to "save" time (and money) during the hire process but as they say in project management out of the three variables Quality, Money and Time only two of the three are ever under control.
If Money and Quality really matter, take your time.
July 2, 2010 at 6:02 am
I absolutely think there should be testing, and I would gladly apply for any job that did so, not only to get a shot at it, but to find out where I am lacking, and what I can do to improve. Obviously if the job is a junior position, you'd want a junior level test applied, with the opportunity of a couple of senior level questions just to see what the applicant does, but anything that shows you how they think, or requires them to explain why they did what they did should give you a better understanding of the applicant than any cv/resume you read.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
July 2, 2010 at 6:12 am
I'm not so sure about testing. The interview process where I work includes considerable time at the white board. We talk about queries & table structures & TSQL. I'll put up queries with problems and see if the interviewee can solve them. It's not testing. It's interviewing. It's assessing their attitude, aptitude, knowledge, approach... All of this makes up a good hire. Slapping people in front of a test... not so much.
I remember one interview I did years ago where I got put in front of a test, filled it out, and the interviewer said "Pretty good, but you missed this easy one here." I don't remember the details, but they had a logic error. I walked them through the correct solution, showing where their method broke down. They got all excited because they actually had the bad code in production. Another guy got the job... he "passed" the test.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 2, 2010 at 6:38 am
Interesting question. We all code differently and usually my way is not the only way. We are all subjective in the best way to write code and usually favor our particular subset of coding. As a potential employer you need to inquire about their style of programming, but I don't think it is necessary to have the interviewee write specific lines of code.
Rather than test coding ability, I would really like to inquire how a person thinks through and solves a problem. So rather than having an interviewee write code on the white board, I would rather pose a problem and look to see how he/she proceeds from my problem to either some form of pseudo-code or process diagram.
Mike Byrd
July 2, 2010 at 6:44 am
As a database developer for an online trading firm, I went through a total of four technical interviews, but took no test. The technical interviews - which were conducted by my soon-to-be managers and colleagues - were sufficient to establish that I had sufficient knowledge of database development. More importantly, they established that I had the right attitude to work with a team of dedicated professionals committed to improving their skills on a daily basis, and ultimately this is what proved to be more important. Technical skills can be learned: finding the right fit for the team trumps any test that might be given.
Roland Alexander
The Monday Morning DBA
There are two means of refuge from the miseries of life: music and cats. ~ Albert Schweitzer
Viewing 15 posts - 1 through 15 (of 52 total)
You must be logged in to reply to this topic. Login to reply