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?
"I think there is a bug in the compiler"
They're constantly posting questions to StackOverflow on how to solve even the simplest of problems.
True story. He clicked on the "little minus sign" on his application and it disappeared. Had to ask where it went.
"So, what's a 'class'?"
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 [1] as a good starting point.
[1] http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.htmlTheir first code check in consists solely of one of the following:
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.
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...
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?
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.
True story - we hired a programmer who just couldn't "get" indentation. His code was crappy too!
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.
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.
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.
They seem shocked that they are the only naked person in the building :-)
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...
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.
He wants to use Visual Basic to solve a problem.
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.
They report a bug because the compiler "changes the color of his words."