tags:

views:

902

answers:

20

We recently had a new-hire who everyone loved in the interview, but when their first day came around......well, let's just say not everyone was as high on their skills as before.

The first issue came up at lunch, when he couldn't figure out how to get a very simple microwave to work. He was just randomly pressing buttons, finally got it to run for 30 seconds, and then proceeded to scrape off frozen mashed potatoes for the next hour.

That first afternoon, when asked to help debug something with a coworker, they continually suggested using vectors for everything.

What are some of your signs that someone just might not work after they have been hired?

+15  A: 

They're constantly posting questions to StackOverflow on how to solve even the simplest of problems.

TLiebe
better yet.. they don't know about SO...
Jakub
The fact they even know StackOverflow exists is at least something.
Binz
Better bother SO users than coworkers =)
Jader Dias
+6  A: 

"So, what's a 'class'?"

inkedmn
+6  A: 

To be honest if you are capable of seeing these things on a new-hires first day then your hiring process is pretty sucky. I'd use Joel's hiring advice as a good starting point.

Chris Arnold
+2  A: 

Excessive profanity or violent tendencies when they encounter a problem or experience disillusionment upon discovering what the work environment really is instead of what was promised.

Edit:

While the disillusionment may be common, mumbling a "I'm gonna blow up the building," under one's breath may get one into trouble pretty quickly if it was sincerely meant.

By excessive, I'm thinking of the person who with every 4th or 5th word would be a bleep on network TV like the Jerry Springer show for the profanity and one could wonder if the person has Tourette's or some other condition leading to such actions. As for violence, imagine the programmer that wants to bump chests and butts multiple times a day for no good reason.

JB King
Define "excessive".
Roger Lipscombe
Depends if Lotus Notes is involved
Greg
Well, I think the disillusionment bit needs to be taken with a grain of salt - I mean if you promise someone something completely different then what you are actually giving them - you need to expect some initial disappointment / disillusionment. The question is whether they can/are willing to adjust to real environment - which is not something you are likely to see in one day.
Streklin
+1 - once worked with a dude like that. He was constantly swearing and yelling in his cube, and kept complaining that everyone else's code was crap. _His_ code was crap, unreadable, not commented, unstable, and did not do what it was supposed to do... :)
KristoferA - Huagati.com
I'm going to put strychnine in the guacamole.
womp
+2  A: 

The person tells everyone on the first day how their life changed for the better when they realized they're one of the top programmers in the industry.

Kyle Walsh
+22  A: 

"I think there is a bug in the compiler"

JohnFx
The old classic rears its head once again!
Kyle Walsh
Hey, I once found a bona-fide bug in our c++ compiler, came up with a short legal program that made it crash, documented it and everything. Should I have been fired?
Beta
@Beta You did the right thing and supported your assertion and proved the bug existed. The opposite is something like disabling all optimizations for an entire shipping product because of "many compiler bugs". (I wish I was making that up.)
Brian Ensink
you must never have user the MS VC6 and before compiler with templates.The least little template syntax error would cause a compiler crash
pgast
Perhaps I was being glib for the sake of humor, but I was referring to the type of programmer who is so overconfident that their first instinct is that the compiler everyone is using must be broken, before conceding that it is POSSIBLE that it is the code they wrote yesterday that hasn't even reached the testers yet.
JohnFx
I remember writing a generic package that instantiated a generic package in Ada, and I struggled for a couple of days before I found out the compiler had an error, so my professor let me turn in an non-worker application.
James Black
I found a bug in Java back in the days of Swing 1.2. I made the mistake of telling everyone on my team... for the next three years every time something didn't work, they'd all roll their eyes and say "must be a bug in java".
womp
One time I found a bug in the VS2005 C# compiler. "b1 = b2 = true" would set b1 to 'true' and b2 to 'false'. It has since been fixed.
James Jones
+3  A: 

An unwillingness to talk about or show what they have been working on. Which probably means they haven't done a damn thing and/or don't understand what they're doing.

When you ask them about what they're working on, they answer in vague generalities.

Honestly, though, at all the organizations I've been condemned to work at, it takes at least a week just to get the guy a machine/login/etc, so congrats to you if your company is enlightened enough that you can get a new guy working on his first day and see that he sucks.

Brian Schroth
Like http://thedailywtf.com/articles/the_brillant_paula_bean.aspx
TrueWill
Exactly. And I'll add another to the theme of this answer: If when you ask them about what they're working on, the answer is along the lines of "almost done" every time, as if you don't remember that that's the same answer you have received every time you asked for the past 2 weeks. But I suppose you wouldn't be able to see that on the first day.
Brian Schroth
+6  A: 

Their first code check in consists solely of one of the following:

  • Adding hungarian notation to variables.
  • Removing hungarian notation from variables.
  • Adding line breaks before the opening braces.
  • Removing line breaks from before the opening braces.
JohnFx
Changing all tabs to spaces, or vice versa.
Simon Svensson
LOL @ "Changing all tabs to spaces, or vice versa."I've been at this programming thing for 20-something years, and just joining a team, I asked about coding standards. I was told, "ah, well, we're pretty lax, you know, whatever." So I check in some code, and the phone rings. The same guy who told me "whatever," says, "You use tabs?!?!?" Um, yeah. It's C. K+R. you said 'whatever.'So I put in some vim "comments" that made vim convert tabs to the unstated convention, and was happy.But jeez, even when you *specifically ask* about this sort of thing, you can't avoid stepping on toes.
smcameron
+2  A: 

They seem shocked that they are the only naked person in the building :-)

schmoopy
+7  A: 

True story. He clicked on the "little minus sign" on his application and it disappeared. Had to ask where it went.

Nat
Add code to application to disable minimize button. Issue solved.
Thorbjørn Ravn Andersen
+3  A: 

True story - we hired a programmer who just couldn't "get" indentation. His code was crappy too!

Craig Shearer
+1  A: 

He wants to use Visual Basic to solve a problem.

JasCav
And write a GUI to trace an IP.
Michael Todd
+2  A: 

1) ...prints out 200 pages of some manual and then proceeds to go through it and highlight something on every page in yellow, green, orange, or pink. (Not sure what the different colors were for, but we all had a lot of fun watching her do that...)

2) Dude hired as a backend programmer (i.e. should know at least the basics of SQL), yet kept asking me to write his queries for him. And it was not even complex queries, simple one or two table things...

KristoferA - Huagati.com
Why is reading a manual closely a sign of a bad programmer?
RossFabricant
Reading a manual doesn't have to be a sign of a bad programmer, but in this case she printed a 200 page pdf document of the kind that people normally just use as a reference, colored/highlighted every page, and was still clueless afterwards. Anyway, the bosses had great patience with her and let her stay around for a couple of months before they gently let her know that maybe she should consider a different career... ...which she did...
KristoferA - Huagati.com
Add the "was still clueless" to the answer ;-)
Thorbjørn Ravn Andersen
+3  A: 

I work for a large corporation. So that first week when they are just getting their accounts, computers, logins, la la, I pay attention to how they act, what they ask, and most importantly how they fill their time if no one tells them what to do. For example, three new hires. Two are constantly asking questions, even if they are dumb ones, they want to get going and understand things. The third sits there and waits for someone to tell them what to do.

Then there is the guy who has to print everything out. Send him an email and he will print it out and bring it back to you. Waste of paper and time.

Good communicators are very important. Those who practice speaking other's languages and ways of speaking can communicate what they are trying to say. Those who insist on saying things their way even if no one gets what they are trying to say need a refit job :) Ever see two people bang each other on the head resaying everything over and and over without making progress in the conversation. Not a listener those types.

Those who approach new topics from a top down approach vs offering solutions without fully understanding the actual problem or taking the time to think about it are also red flaggers.

Developers who can tell you about their past and the types of projects they worked on are great! But not if its one long continuous brag. I understand you want everyone to know you are not fresh out of the woods, but there's a happy medium and then based on what you share I can get a feel for you. Go getters and self starters are great!

Last of all, ,can you document? Do you put comments in your code simply because you tend to think ahead and want to make sure the important stuff gets said without everyone scratching their heads everytime they look at your code? When you send an email or write a document, is it clear and concise?

+5  A: 

I asked a guy to do some unit tests for code he wrote and he told me "I don't need to unit test - I write perfect code". He was dead serious. He is long gone but the phrase "I write perfect code" is a common sarcastic saying around the office.

What a tool that guy was. And in case you have to ask, his code was awful.

Loki Stormbringer
+2  A: 

If you can tell in a day that the programmer's not going to work out one or more of the following is true:

1) Your recruitment process is terrible and probably includes no skills testing or questions designed to determine if they have any social skills

2) The systems your team are working on are trivial

3) The programmer already knows the system you've hired them to work with

A day isn't even long enough to get familiar with your desktop and the network let alone all the documentation. If you're throwing even an experienced coder in the deep end on their first day with zero familiarity and you expect good code, you're dillusional. Give them at least a week. As for anti-social behaviour and lack of skill the first day is way too late in the process to be concerned. You should be weeding them out earlier.

Sammy
+5  A: 

We had one guy about 8 years ago who decided that the user wouldn't want to have to manually type in a date...but he didn't want to use any existing date selection controls.

So he took a combobox, and added 10,000 dates to it.

Without using a loop.

Just thousands of lines of Combobox1.AddItem, every line manually typed. Sadly, we didn't spot this until he'd been with us a few days, although it appeared he'd done nothing else since he started. I was told he'd interviewed well, and was cheap...

CodeByMoonlight
Let me guess, management had a tracking metric based on SLOC, right?
JohnFx
No, back then we were a tenth of the size and the company was only dabbling in IT. If it used SLOC I'd be screwed.
CodeByMoonlight
+3  A: 

We had a small, trivial issue that was being airily discussed over the desk where the amount of content in a string was causing a buffer overflow somewhere in the software.

New guy, who shall remain nameless, matter of factly suggests that we should simply change the variable type from a string to a long.

Evernoob
+1  A: 

There's the other side to this question too: how do you know when you're going to be the person who doesn't work out?

I should have seen the stupidity when they promoted the webmaster with no programming experience to CTO. I also should have seen the problem when I was given the project that sent 12,000 emails every five minutes by forking a process for each email, and that's the way they liked it. That was just the first week.

Or, I could have figured it out when I was reprimanded for making small talk with developers from another company at the lunch table at a conference.

Or maybe when they told me that they couldn't ship anything by UPS because they were in collections with them, or they forget to pay the electricity bill for four months, or they wanted to buy everything instead of leasing it.

However, I was blinded by the big bucks and the challenge.

brian d foy
+1  A: 

They report a bug because the compiler "changes the color of his words."