Steve Eichert

I think getting somebody to write some code (either over a couple of hours at your place of business, or as a "take-home assignment") is a good idea. If you do it at your place of business make sure it is not too high pressure. Coding while somebody is looking over your shoulder can be hard enough at the best of times, and is not indicative of a "real-world" situation (unless you're doing pair programming, in which case the dynamic is probably going to be a little different to a job interview).

I once had a sadistic thought that if I was doing the hiring I would present somebody with a list of N languages (Perl, Python, Lisp, C++, C#, VB.NET etc) and ask them to rate themselves in order of best to worst. Then I would ask them to write a bubble sort or something in their worst language (I would provide the MAN pages or MSDN or whatever, and have the environment set up). I want to work with people who can learn new things. Maybe then ask them something a little harder in one of their "middle of the road" languages, and finally something hard in their "best" language. Lucky for my company I'm not in charge of the hiring.

Tell me about it!
Developers lie! Developers lie! Developers lie!

Well...sorta. If you have no experience, you have no way of knowing what you don't actually know, do you?

It depends, did you ask them to code on a whiteboard?

I can never remember the syntax of anything, so I guess I'd come off as a crappy dev as well if that indeed was the case.

I can't code shit. If shit is what you want, I am the wrong person.

Sorry, couldn't resist.

It's unfair to address the whole .NET community in this way. It could be the developers you want is satisfied with status quo, and that's why they won't show up in your interviews.

Do you dislike VB developers as a whole, too?

What do you mean by "they can't code worth a crap"? I agree with the coding exercise, which we sometimes replace by having them send in some code beforehand which is something recent, something indicative of their work, and we ask them to explain it during the interview!

I know its unfair, and I was mostly saying it "tongue in cheek." We've had a couple contractors come in recently who did pretty good on our written test (not coding), but, when it actually came to coding in the real world they just didn't get things done.

We've been thinking about a code sample as well, perhaps, I'll bring that up as another option to our team here to see what everyone thinks.

Anyway, Thomas, you should really work on your "shit coding" :-)

I had an experience mentoring a new grad who got an A in c++ but couldn't tell me what an object was.

I think a huge part of the problem with people not being able to code is that coursework does NOT prepare you for the field. Not in the slightest. Every programming class I ever took in school went like this:

1. Variables
2. Conditional logic
3. Loops
4. Simple file I/O **note this is where the really bad programmers started slowing down the class b/c they just didn't get it anymore. Some classes we never got beyond this.
5. Very simple database I/O

First off, the majority of "homework" is not even remotely similar to what you'll work on in the field. Second, everything is so basic and straightforward that the students don't ever encounter a problem that isn't quickly solved in the textbook. A programming class is just following the samples and regurgitating whatever the prof just showed you.

This just doesn't prepare students for the critical thinking and problem solving that is needed to be a good coder. The only way to become a good coder is by alot of self study, which most students just don't have time for, or to get a great mentor. The catch-22 on the mentor thing is that very few respectable programmers will hire someone who "can't code worth a crap".

I don't know what the solution is, but I have always felt that programming should be more of a tradeskill than a university degree. The best way to learn is through mentoring and experience, just like carpentry etc.

Lazycoder weblog » Why can’t anyone code in .NET?

At my work our process for hiring people is pretty grueling.

We have a recruiter meet with them, ask them some questions, etc. If they workout, my grand-boss(he is a techie) starts his interview process and asks a candidate to rate themselves on everything from css to oo concepts. Then after they rate themselves he asks weighted questions for each category. Then he actualizes their score to what he really thinks the person is qualified for. He has given about 1,000 of these so there is alot of data to compare to.

If the person passes this stage of the interview they come back for a 6 hour "work" test. It is supposed to be a simulation of working on stuff during the day. We give them a room and a computer with an internet connection and a list of tasks that no one could possibly complete ranging from everything from c#/vb.net to t-sql.

If after all that you still want to work here, and you did well on the test (delta of how you code versus how much work you completed) then we put you through a microsoft style "Peer Review." We usually get 1-2 developers as well as a business person (we call them account execs) in a room with you 1 at a time.

This is more of an ogre test than a technical test, but I am always certain to ask some really difficult tech questions.

That is our hiring process. It isn't perfect, we have had some people that just completely misrepresent their skills and don't do well, but we are able to detect lots of "bad apples" early on as well.

Were these coders (notice I didn't say programmers or developers or architects...) recently out of school (i.e., <5 years experience)? If so, you should aim higher and go after 5-15 year experienced developers (who hopefully graduated before the "great curriculum dilution" occurred).

As I've commented on other blogs, a lot of recent college grads are suffering from a watered down curriculum. E.g., here in Silicon Valley, all the junior colleges and 4-year schools have not only combined 2 or 3 data structures and algorithms courses into a single course, but moved it from sophomore year to junior year...effectively removing it from all AA degree programs. At this point who would want to hire a AA to do ANYTHING? (Can a AA who didn't take any data/alg course even be hired as a CODER? Not on my watch!) And if they're delaying this vital coursework until 3rd year, what course is getting bumped off the 3rd/4th year curriculum (to make way for the data/alg course) and what courses ARE they teaching in 2nd year instead?

I've investigated curriculums in the past year and verified they're being watered down and stretched out with less material over the 4 years. A lot of this has to do with Java indoctrination: too many quarters are wasted covering the bloated Java class library, taking away from core skills (not only data/alg but also database concepts, TPM and MQ concepts, n-Tier and client-server concepts, modeling and simulation, numerical methods, computer architecture, etc.). To make things worse, a single combined data structures & algorithms course is now OPTIONAL at many schools! (And just try and find ANY non-Ivy League CS program that still uses Knuth's "The Art of Computer Programming" in ANY course!) Thus, who would want to hire ANY such under-skilled graduates?!?!?!

Another problem is that most CS graduates in the past 7-10 years are Java-centric. Only if they graduated in the past year would they have any formal .NET coursework, and probably only a token course or two (e.g., a C# course and intro the .NET Framework course). Thus, a lot of Java-centric developers are just LYING about .NET Framework experience, since they figure: "What's the diff between one framework and another? They're all the same aren't they? Esp. since .NET is a subset of Java, isn't it? Besides, I can learn it ON THE JOB!" (Those are actual quotes out of the mouths of recent grads BTW...)

It's gotten to the point where if I interview anyone with <10 years experience, I request their transcript to review the courses they took. Then, I even go so far as to ask them to bring in their best piece of code they wrote in college and start out the interview with: "If you were redeveloping this over again today, what would you do different and why?" Using their own piece of code (which they own and SHOULD BE intimately familiar), they should be able to demonstrate a certain amount of self-critical objective analysis and prove they understand refactoring.

If instead they demonstrate an arrogance, e.g., "this code does NOT have ANY bugs!" or "I wouldn't do ANYTHING differently!", then they have some explaining to do. (Sometimes, very rarely, you may encounter a programmer that really is THAT GOOD and can be excused a bit of arrogance and hubris, assuming their code is THAT GOOD. But, usually, they're just BSing ya...)

I've been using the above technique for over 20 years, since refactoring is a key skill that all developers MUST have (and is NOT taught in most 4-year CS schools)...BEFORE they can even be called a developer. (The second key skill that makes a programmer a developer is "code reading"...which I've also used in interviews. The third key skill is debugging, of course. The latter two skills can be judged by presenting them with a sample piece of code to read and debug.)

In summary, it may be too early in the life of .NET to expect that there would be a large talent pool that knows the framework extensively, and you may have to lower the bar (i.e., reevaluate your expectation levels) on certain skills. Also, avoid the "shopping list syndrome". Else, you'll just ulcerate yourself trying to find someone with all 39 skills you think everyone should have...

Jeff,

I would love to interview at your company! Sounds like my ideal interview style. Give me a computer with an internet connection, what couldn't you do? hmm...

I like to take the "give them enough rope to hang themselves" approach. First, I have programmers bring in a piece of source code and then I have them rate themselves on a 1..5 scale on items from platforms to programming methodologies (depending on the job). Then I grill them on the topics to find if they're telling the truth. It's pretty easy to peg someone who marks themselves on 4-5 on the .NET Runtime and can't explain something simple like boxing. I've found this to be more effective than dropping a coding excercise in front of them.

I remember one guy who apologized to me for wasting my time after he marked himself 5s in C++ and didn't understand basic threading issues. I didn't have to gun for him, but after sitting through a barrage of questions where he replied 'I don't know' he understood he wasn't getting an offer.

You guys are brutal interviewers! I don't think I'd pass half the interviews I'm hearing about what with being under pressure and all.

I'd actually be satisfied with the interviewer bringing their own code sample, walking me through it, being frank about what they don't understand based on just a few probing questions (no hanging rope), and answering some questions about how they learn something they don't know.

Do they have a blog? What's their favorite .net site? Describe one programming methodology and what they like or dislike about it. I guess I'd be more inclined to ask very basic tech questions and then just have a conversation to determine the programming attitude. You don't need everyone to be super coder (Check Eric Sink's weblog for more on that <a target="_new" href="http://software.ericsink.com/entries/No_Great_Hackers.html">http://software.ericsink.com/entries/No_Great_Hackers.html</a> )

&quot;...they come back for a 6 hour 'work' test.&quot;

OMG, I hope you are paying well. :-)

The only company I've ever done that for was Microsoft (MCS and Corp). Outside of that, I probably wouldn't even consider an interview of that length. We all value our time and there's no reason you can't have 90 minute interview and decide on a contract-to-hire based on that. Also, keep in mind that some placement agencies have a 1 week satisfaction guarantee deal you can work out. Not happy, drop the person and don't pay. Look into that maybe?

Interviewing Candidates is a tough task. I sorta agree with Eric &amp; Sean above, nobody knows everything technically and I don't care who it is, they can be made to look like an ass in an interview.

.. When I interview, all I look for is the right background, and the right attitude, and it doesn't take me 6 hours to find that out (about 60 minutes is enough).

ABC's of the right candidate -

Attitude
Brains
Current Background

... thats it really !!! :-/ screw coding in the interview for the sake of it. But if you do ask someone to code, and he refuses .. thats just bad attitude. Also, in my interview, I make it a point to show them where they will sit and where they will work and what they can expect on an everyday basis, because I want them to be happy and content in the job they are about to accept.

To reiterate Sean's comment, if I had to spend 6 hours on every prospective employment, that would make my life hell. Don't waste your AND my time.

I have taught several different languages and I am currently teaching vb.net at the local college. I have note during my college education, that instructors tend to give midterms, quizzes and finals but very little actual programming (less grading for the instructor). I believe this is great for teach theory but not for creating programmers, so I changed the way I teach my class. 70% of a student’s grade is based on programming. They have programming assignments every week. They also have bonus coding assignments (large projects) during the course. They are graded on style, documentation and execution. They must design and code for maintenance and assume another programmer will also be working and maintaining their code in the future.
Like math, the only way to learn and master programming is to code. Just reading about it is not the same as doing it. I believe our training must be more on-hand if we want people coming out of college CS programs with useful (marketable) skills.