Fog Creek Software
Discussion Board




How soon would you fire an incompetent developer?

Hi All,
Just a hypothetical question, if you were in charge of hiring and firing( or are),  how long would you take to remove an incompetent developer, if you had  done the mistake of hiring him?

anon
Sunday, February 16, 2003

Speaking as the coworker of an incompetent developer, I'd hope you fire him as soon as possible.   

anon
Sunday, February 16, 2003

For all kinds of reasons, you need to fire someone who's incompetent as soon as possible.  (Note that incompetent is different from 'lazy' or anything else that's changeable by the person with some effort or coaching.)

The longer you wait, the worse it is, both for them and for you.  Doing it as soon as you're SURE means they can get on with finding a job that suits them better and you can get on with finding a more competent person.  The longer you wait, the more emotional commitment there will be from everyone involved.

There are legal reasons too - if you wait two years then it's pretty hard to justify letting someone go for incompetence, if you ever landed in court.

Judge:  "If this person is really incompetent, why didn't you let them go earlier?  Obviously they were fine if you employed them for two years."

Note:  For better (real!) legal advice consult a lawyer who specializes in employment law.

aa
Sunday, February 16, 2003

Disclaimer: I never did HR stuff. Consult a human resources guide from the small business development office in your town.

Time before notice: How about 6 month after probation? Just in case you were wrong--gives the company a chance to reach one or two quarterly or twice-yearly reviews and allows Human Resources to take its proper course.

Accounting: Most managers account for this possibility when hiring so they budget for the cost of acquring and training two or more engineers for at least a year when they are attempting to keep one.

One possible approach: You should just let the developer know why you believe he his (her) skill sets can't be updated fast enough to do the required contribution to your project. Explain why there are no other projects that require his help. Explain to him that he should start to look for jobs that better match his skill sets and offer to help. It gives him the heads-up to start looking for another job and eventually let the current one go. Just do it in a rational and helpful manner--usually your help won't be perceived as a threat.

Personal note: I am happy that I never had to do this yet, but I have given references to the fine engineers I have had the honor of working with during the end of their terms with companies I was a part of.

Li-fan Chen
Sunday, February 16, 2003

I'm not talking of somebody who's skillsets fall behind, I am taking of somebody who fails to finish any project wether large or small given to him, and always screws up.......

anon
Sunday, February 16, 2003

First, if you haven't done so already, ask his fellow workers what they find about a team member before you mark someone as incompetent.

Second Break that relationship as soon as possible.

Some think that the worst that can happen with incompetent team members is that their return rate is zero. They add nothing to the process while receiving salary. It's much worse, the return rate of incompetent team members is generally negative. They take time away time and energy from the good guys. Leaving an incompetent team member around is one of the best ways to kill moral and efficiency.

<quote src="Steve McConnell's Rapid Development">
In a review of 32 management teams, Larson and LaFasto found that the most consistent and intense complaint from team members was that their team leaders were unwilling to confront and resolve problems associated with poor performance by individual team members.

They report that "more than any other single aspect of team leadership members are disturbed by leaders who are unwilling to deal directly and effectively with self-serving or noncontributing team members."
</quote>

Jan Derk
Sunday, February 16, 2003

Verify proper policy with HR.  If you don't have HR, ask a friend at another firm to ask his HR. 

I suggest you start documenting him ASAP.  Document every screw up, and make him sign it.  Give him a bad review. 

Then, when the day comes, you arrange a pseudo meeting for the entire team, except him.  When they are away in the room, you have security remove him from the building, and inform him he has been let go.  His "stuff" can be mailed to him,and HR can wrap up the details remotely..  This will obviate the risk of him trashing your network or stealing code/materials or going postal after he learns he is being fired.

Good luck

Bella
Sunday, February 16, 2003

> It's much worse, the return rate of incompetent team members is generally negative. They take time away time and energy from the good guys. Leaving an incompetent team member around is one of the best ways to kill moral and efficiency.


100% true.  A bad apple creates more work for the rest of the team.  Incorrect work that must be fixed, etc.  Team members with bad attitudes do nothing but waste everyones time as well.

Bella
Sunday, February 16, 2003

anon, I think we work with the same guy.  Not only is my guy one of the worst "senior" programmers I've ever had to work with, he's the laziest too.  For his last three projects, he didn't even start until _after_ the deadline.  And the stuff he did deliver was so bad that it had to be re-written by the group that wanted it.

Our boss doesn't seem to care/notice and is constantly finding an excuse for this guys work or timeline.  The current excuse is "he works really late". Working late != working hard.  In this case it means he spent all day on the phone talking to his friends and must stay up late to get his "work" done. 

How do you solve the problem when one of the members on your team doesn't do any work and the boss doesn't notice or care?

Joe Blandy
Sunday, February 16, 2003

Bella,

I disagree with that scheme of removing an employee.  All it does is treat him like your throwing out the trash.  Its not cut and dry like that.  These are human beings too, to make him look like some evil enemy will cause more resentment and possible backlash.  And what kind of example will you be showing to the rest of the employees.  Its a business, not some cold military bunker.

I would suggest talking to the person.  Spending some time to maybe discover what is causing this disruption.  Who knows, life could have turned pretty sour for the person (divorce, death, finances, etc.) and his personal life maybe unstable right now to focus clearly on work.  Maybe they are still searching for the right qualities of work that they most enjoy, and are testing the waters as you are them.  To react on the person simply based on the judgement of others shows a cowardice manager.

Business is business.  And its the people that make the business.  Treat them like human beings, and not like cattle.  In the end if the decision is made to part, then atleast there was a chance to develop some mutual understanding.  The last thing anybody needs today, are more bitter people.

sedwo
Sunday, February 16, 2003

I agree with Bella on the documenting part.

There should have been some reasons why you hired him to begin with, what were those? Write them down, see if that person is doing those.

Get some other senior member's (in your team) opinion, see what they have to say.

Maybe he/ she is one of the late starters? Do you see this person putting in any extra effort?

Prakash S
Sunday, February 16, 2003

Caution. Are you SURE someone is incompetent? If so, what is your objective metric? How do you measure competence? And what is your level of industry experience to make that judgement? These are rhetorical questions to be applied diligently to every such case.


The label "incompetent" can be applied with a lynch mob mentality because someone doesn't have a personality that fits the predominant style of the members of the group or the leader(s).

Many times this can be agism. Someone in their 30s or 40s can be crucified by co-workers in their 20s, and vice-versa.

Everything negative you've ever heard about promotion by incompetence or demotion due to appearing a threat due to personal style can be associated with the label 'incompetent' applied to a developer.
In fact, in many development groups I've worked in, being deemed competent and gaining respect of others seemed to be as much about personal style - knowing the right lines, being a smartass at the appropriate times - as it was about getting work done.


A concrete example of style clash would be someone from a larger and more formal environment who is concerned with process, hiring into a small company skunk works where everyone pulls designs and architecture out of their asses. The "formal" individual appears to only be writing emails and reading to the less educated or formal types around him, thus is pegged incompetent and wasting time.


Sometimes too, 'incompetency' can be associated with working on an unfashionable piece of technology that isn't interesting to others in the same company or group. You're incompetent by association because you are working with retro technology, for instance (such as the the few in a group that are charged with maintenance of legacy applications).


Lastly - there is a social cost to labeling someone incompetent and pulling the trigger that is similar to capital punishment. If the person has gotten a bum rap due to style and political differences, you will automatically alienate other individuals in the company and instantly create a class of suspicious employees with no trust in the management nor the company process.

Tread carefully!

Don Wallace
Sunday, February 16, 2003

"Then, when the day comes, you arrange a pseudo meeting for the entire team, except him.  When they are away in the room, you have security remove him from the building, and inform him he has been let go.  His "stuff" can be mailed to him,and HR can wrap up the details remotely..  This will obviate the risk of him trashing your network or stealing code/materials or going postal after he learns he is being fired.

Good luck "

Sure, if you want to mark your company as inhumanly callous, underhanded, and brutal, that's a great strategy.  I'm sure the rest of the team will get right back to work instead of start worrying/gossiping about who's next, or if the next meeting is a real one or a decoy to have someone forcibly removed.

Or, maybe this was a troll.  It's hard to say.

Robert

Robert
Sunday, February 16, 2003

Well actually, it's not my problem, but a friend's at another firm.This senior developer with 8 years experience in C++ does not seem to care or know about knowing the difference between a copy cstor and a default constructor, as well as where to use "virtual destructors", also ends up using switch statements instead of virtual functions....
seems to me to be a C guy, claiming to be a C++ fellow.
I really don't have a lot of details...that's what my friend says.......

anon
Sunday, February 16, 2003

>> This senior developer with 8 years experience in C++ does not seem to care or know about knowing the difference between a copy cstor and a default constructor, as well as where to use "virtual destructors", also ends up using switch statements instead of virtual functions....
seems to me to be a C guy, claiming to be a C++ fellow.
I really don't have a lot of details...that's what my friend says.......


On the other hand, does this person get his work done at a module level? Does he deliver whatever he's asked to deliver and does it work?


This sounds like a perfect textbook example (potentially) of a personal style mismatch where someone is being crucified or derided because he's not kewl enough. Sic: a bunch of C++ gurus scorning the one guy that conservatively sticks with a limited subset of the language but who *gets his work done.*


The items you listed would grate on me as gaps in understanding of the tool, but they're not fatal flaws in and of themselves.


On the opposite end of the spectrum, I've maintained simply horrible code written by wankers who overreach their knowledge with techniques that they really don't understand, or who glop up what should be simple procedural code with object soup that is much more difficult to maintain than straightforward code using less advanced constructs. Now, THOSE (overreachers) are the people that should be run out of their jobs!

Don Wallace
Sunday, February 16, 2003

Well, I'm curious, some of you guys *seem* to think any level of incompetence is just someone having a bad day, bad point in their life, etc.  For you people, when would you just actually KNOW the guy is incompetent or would you ever?

For example, I worked with a guy once, he was given a relatively simple task. I expected it to take him 1 week, at most 2.  It took him 6 weeks and when he finally gave it to me it was buggy and not working.  After futzing with it for a couple of days and realizing was was pretty hopeless I re-wrote it from scratch in 2 days.

As far as I know, the entire 2 years he was there he never delivered anything useful to anybody.

At another company there was a guy that in 9 months could not manage to get a single display up on the screen yet the boss would not let him go.  No, he did not have other special responsibilities.

Gregg Tavares
Sunday, February 16, 2003

I'm talking of somebody who writes pretty unreadable code, and delivers maybe 20% of the time, and who takes a huge salary chunk claiming to be senior......

anon
Sunday, February 16, 2003

In Australia people do not get fired for incompetance.

I am with Erik Naggum, incompetance should be a crime and I know a lot of people who should be in jail.

braid_ged
Sunday, February 16, 2003

"ends up using switch statements instead of virtual functions...."

Oh... this is your definition of incompetance.

Is this a troll? At least come up with a fake name for your troll rather than anon.

But if this is serious, you are just totally lame. Where do you work so I can avoid it? you're the one whose rear should be tossed out.

Jeez. Freaking language snob. Get some work done. I would magfer you're the one who gets no coding done while this other dude codes cyclones around all of you there.

Uberanonimator
Sunday, February 16, 2003

It's no troll, and I don't work there,what my friend said is the guy  could use any methods he wanted, but has to get the work done, but not only does he not produce the required output, but produces unreadable junk.........

anon
Sunday, February 16, 2003

> I disagree with that scheme of removing an employee.  oyees.  Its a business, not some cold military bunker.

Yes, there are many ways to do it. I was sharing how my last client would do it.  He do not have to follow suit., 

Bella
Sunday, February 16, 2003

>  I'm sure the rest of the team will get right back to work instead of start worrying/gossiping about who's next

Or, they could simply concentrate on doing their jobs, thereby not having to worry about this happening to them.  I am speaking about the culture of Tier 1 blue-chip financial firms, not some liberal advertising or fashion agency.  There are 500 waiting in line to take your job, so they do not need to worry about being "gentle".  Sad but true.  And don't shoot th messenger.

Bella
Sunday, February 16, 2003

Yes, there are many ways to do it. I was sharing how my last client would do it.  He do not have to follow suit.,  "

- This seems to be the common practice on the street from what I have heard.

Prakash S
Monday, February 17, 2003

[Or, they could simply concentrate on doing their jobs, thereby not having to worry about this happening to them.]

No, seriously Bella - where do you work? No way do I ever want to be in a faceless Brazil like you describe.

Where I work, I work with people. People who care about each other, and people who communicate. Not people who spend eight hours a day in their 8'x8' prisons then go home, never speaking to one another for fear some manager will pick them off like a Morlock jumping a wayward Eloi.

Then again, maybe I just watch too many movies. [g]

Philo

Philip Janus
Monday, February 17, 2003

If I were in the position to fire this guy, I would make sure to sit down with him and let him know why he was being fired.  Make it very clear to him your feelings, and back it up with examples.  Then give him the opportunity to explain himself.  You might learn something.  Or you might not.  But it's possible that there's something about your work environment, politics, or some other factor that is part of the problem.  Don't pass up the opportunity to find out what an "outsider" thinks.  You might be surprised.  If he understands your points about him, make sure to listen carefully to his response - he's not as incompetent as you think.  But if he doesn't get why you're so worked up, can him - he doesn't have enough self-awareness to dig himself out of his hole.

ODN
Monday, February 17, 2003

There's a differential that needs to be understood.  People are not incompetent, they might be incompetent at performing some task or job, but that doesn't identify who they are.

That's why there are procedures to manage this kind of situation.  The first stage is to investigate the reasons for the problem and see if they can be fixed either by training and/or better supervision.  It might be that in that process its discovered that the individual is very unhappy and would be happier doing something else.

Unless they culpably misled someone about their skills, experience and so on, its the responsibility of management to endeavour to place them somewhere were their competencies are suitable and where they would be happier.  Because when all is said and done management put them into that job or that situation.

If its not possible to place the individual within the organisation satisfactorily then they should be given an exit strategy that gives them time and resources to find another  job.

Simon Lucy
Monday, February 17, 2003

What do you mean by incompetent? Do you mean that
- they don't know what to do because they have never been taught
-they are unable to apply what they have learnt
-they aren't really interested
-they are lazy
-they have poor time management skills.
-you just don't like them

Generally, most of these can be solved. Either by training, or some attitude readjustment (either yours or theirs).

Sacking someone should be the last resort. And it should not be done in a nasty way. That is the quickest way to disillusion the rest of your staff. Remember that your staff are the one crucial thing in your business, and that staff morale is vital. Make sure you nurture it.

regards, treefrog.

treefrog
Monday, February 17, 2003

" I would make sure to sit down with him and let him know why he was being fired.  Make it very clear to him your feelings, and back it up with examples."

- sounds like an instant recipe to bring a lawsuit against yourself and the company!

Prakash S
Monday, February 17, 2003

Presumably this "incompetent" developer was hired by ... a manager of some sort. This manager has the freedom to do all sorts of things to ascertain the capability of candidates, and a wide choice at the moment.

It is actually quite easy to assess developer capability just from talking.

So I would say we're talking about incompetent hirers here, not an incompetent developer.

Further, the allegedly incompetent must have reasonable skills and capabilities to have been offered the job, and hence I would blame incompetent management, rather than the developer, for failing to utilise those stills properly, if indeed there actually is any genuine deficiency.

Is a manager
Monday, February 17, 2003

Try counseling him, before firing him.  These problems may be correctable if confronted head-on.

Don't place a livelihood in jeopardy if you can fix the problem.

programmer
Monday, February 17, 2003

How soon?  Yesterday.  As long as the incompetence is genuine, and not perceived based on personality characteristics.  Don't feel bad that you are making them lose their living - think about the number of good unemployed programmers who could be filling that position. Incompetent programmers need to get with the program or get out.

At least 25% of programmers and software managers are incompetent and are only a drain on the company's resources and other employees' time. This industry still has a lot of deadwood while there are good programmers out of work. Think about it - of the people you've worked with closely enough to know their competence level, what percentage of them would *you* hire if you had your own software business?

T. Norman
Monday, February 17, 2003

"Further, the allegedly incompetent must have reasonable skills and capabilities to have been offered the job, and hence I would blame incompetent management, rather than the developer, for failing to utilise those stills properly, if indeed there actually is any genuine deficiency."

The incompetent person may have more skills than somebody who has never programmed before, but that doesn't mean they are good enough to justify their salary.  They may have been able to truthfully put "4 years of Java" on their resume, but that Java was a mess of gobbledook that made rampant use of cut-and-paste instead of inheritance and had to be frequently rewritten by other programmers.

Blame the management AND the programmer, not just one of them.  "Management" in this case refers to not just the manager(s) who interviewed or made the hiring decision, but also the higher-level managers who put the hiring decision makers in their position.  Some companies still rely primarily on HR to do the interviews, even though they (HR) often don't know enough about the relevant technology to evaluate the competency of the candidate.

T. Norman
Monday, February 17, 2003

> If I were in the position to fire this guy, I would make sure to sit down with him and let him know why he was being fired.  Make it very clear to him your feelings, and back it up with examples.  Then give him the opportunity to explain himself.  You might learn something.  Or you might not.


ODN, You might learn that you have just opened up the potential for a lawsuit.  This is why you are NOT in a position to fire someone.  B/c you have no idea of the issues involved.  HR policies exist for a reason.

Bella
Monday, February 17, 2003

Not a manager said:


>> It is actually quite easy to assess developer capability just from talking.


Absolutely not so. You need to see actual work that the person has delivered, or you need to have some sort of programming test that tests specifics. Wait until you get burnt on this one.


I worked with a guy that had a serious, beard-stroking, "senior architect" demeanor. He was apparently hired in the first place based upon this personal image. He also taught C++ courses. Whenever I talked with him, I though "gee, he knows his stuff."


Then he was fired from my client. Then I picked up his work, a C++ based network routing program, awhile later.


Gag. It was FULL of race conditions. He used STL queues to communicate between threads and the queues weren't thread safe.  He sprinkled "Sleep()" calls throughout to pace the code to an unGodly slow speed just so it wouldn't crash as often. His C++ classes didn't even use the constructor to initialize the objects.


This guy TAUGHT C++ and he didn't know what a constructor was used for. As for comprehension of real time coding considerations, fuggedaboutit.


I was taken in hook, like and sinker by the personal image stuff. The substance behind the demeanor was absolutely different from reality. The guy was a joke but he SEEMED to be competent and he talked like he really knew what he was talking about.


Based on this experience I think the exact opposite can hold true, too. An immensely competent developer can be thought a dead head due to personal style issues but may be a star performer in actuality.


In conclusion - there's reality and there's perception. Two *completely* different things. So I take everyone's *opinion* about competency with a huge grain of salt.


All that matters is delivery.

Bored Bystander
Monday, February 17, 2003

In many cases, incompetence can be easily detected by talking to them.  If an English-speaking programmer claims years of experience in C++, but can't answer what a constructor is, or can't tell you the difference between public and private, they don't deserve a job.

It's like a basketball player who can't make a layup by himself when given ten tries, but wants to walk on to your college-level team.  If he makes the basket, you don't know yet if he's good enough, but if he *doesn't* make it, you don't need any more evidence to tell him to get lost.

However, once they get past that and can speak to the basics, determining actual competence is more difficult.  Still, the majority of incompetent programmers currently employed probably would have long been eliminated by some basic technical screening.

T. Norman
Monday, February 17, 2003

>> In many cases, incompetence can be easily detected by talking to them.  If an English-speaking programmer claims years of experience in C++, but can't answer what a constructor is, or can't tell you the difference between public and private, they don't deserve a job.

The person that I described who developed the bungled network router would be able to tell you *everything* you needed to know about C++ constructors. Remember, he was teaching C++ at a local 2 year college.

Then you'd look at his code, you'd run it in the debugger, and you'd find it crashing because of uninitialized variables in classes that had ... empty constructors. He could TELL you very convincingly what a constructor is used for. He just couldn't write code utilizing this very simple construct that he taught, to save his life.

What I'm pointing out is that the commonplace intuition you're describing that *ought* to work in an interview situation can be evaded quite easily if the candidate has good bullsh*tting skills.

I basically learned from this to not even trust my own intuition any more. The problem with conversing with someone w/o factual evidence of their ability appears to be that if *you* have similar skills, you will 'read' ability into facile explanations - just as honest people don't expect others to lie.

Get facts and evidence of past work, instead.

Bored Bystander
Monday, February 17, 2003

<quote>
> If I were in the position to fire this guy, I would make sure to sit down with him and let him know why he was being fired.  Make it very clear to him your feelings, and back it up with examples.  Then give him the opportunity to explain himself.  You might learn something.  Or you might not.

ODN, You might learn that you have just opened up the potential for a lawsuit.  This is why you are NOT in a position to fire someone.  B/c you have no idea of the issues involved.  HR policies exist for a reason.</quote>

Uh, anyone care to explain this? How does explaining the reasons for a person's firing and discussing it with them open "the potential for a lawsuit". Last I heard you could be sued for any damn reason whatsoever, and not a single form of doing any activity in life assured you protection.

Maybe I'm just missing something.

Brian Hall
Monday, February 17, 2003

Bored Bystander:

I agree, the incompetence of the person you are referring to would not have been exposed in an interview. I was just speaking of the more general cases where you don't need further evidence to determine incompetence.  If a person doesn't demonstrate a certain basic level of knowledge, you know right away they aren't any good (provided you give them a little time to think about or restate their answer, taking into account the nervousness of the interview situation).  If they do demonstrate that knowledge in a conversation, you don't know if they're good or bad yet ... you have to take the process to another level to find out.

T. Norman
Monday, February 17, 2003

"h, anyone care to explain this? How does explaining the reasons for a person's firing and discussing it with them open "the potential for a lawsuit". Last I heard you could be sued for any damn reason whatsoever, and not a single form of doing any activity in life assured you protection.
Maybe I'm just missing something. "

- depends on the imagination of the person getting fired, he/she could bring in race/ sex/ ethinicity/ etc to sue a former company; and no company wants that kind of publicity.

So they treat other humna beings like criminals and security escorts them to the door.

Prakash S
Monday, February 17, 2003

T. Norman: Excellent point! I agree. I didn't grasp your point earlier.

Bored Bystander
Monday, February 17, 2003

[being deemed competent and gaining respect of others seemed to be as much about personal style - knowing the right lines, being a smartass at the appropriate times - as it was about getting work done.]

It must be hard for managers to rate developers objectively. And once the word gets around that a person is incompetent, it might be hard for them to be perceived fairly.
On the other hand, it's hard to imagine a reasonably competent person being perceived as incompetent only because of their personal style. I think personal style is definitely a biasing factor. On the other hand, personal style can't be everything. Having the right background knowledge and being capable of learning can't be faked so easily.
And if it turns out that the person is really incompetent (lacking the required knowledge and abilities), they should have a chance to catch up if possible. If it turns out they are incompetent and something about their personality prevents them from learning, then you have to wonder why they were hired in the first place.

PC
Monday, February 17, 2003

*sigh*

I'll suggest the following...

Give the person two or three written notices and "interventions", with an opportunitiy to shape up.  (Naturally, if they show no improvement after the first, one is all that is needed)  The person who has a problem with some aspect of things will shape up in time, get the monkey off their back, etc. and if there's any sort of a brain up there, become a productive employee.  The person who needs to be fired will give a demonstration of why they should be fired.

The process needs to be documented in writing, everything on the table and adequately explained.  It needs to be documentable if improvement has been made.  This also prevents lawsuits.  Most people with good manners would probably leave on their own accord if they realized they weren't able to measure up the job and save their dignity.  This very much beats the suddenly-firing-somebody-on-a-friday sort of procedure and potentially gives you the opportunity to fix the situation without playing hardball.

But get it over with relitively quickly.  One incompetant senior developer will cause junior developers to think that mediocraty is acceptable.

took-the-blue-pill
Tuesday, February 18, 2003

"Most people with good manners would probably leave on their own accord if they realized they weren't able to measure up the job and save their dignity.  "

- not true, I don't think you get severance pay if you leave on your own accord, OTOH - depending on company policy, you are given X weeks/months of severance pay.

Prakash S
Tuesday, February 18, 2003

One of the hardest problems I've faced when managing a team is one guy who I would have to describe as "incompetent". There was nothing wrong with him socially within the team, it's that his code just didn't work as well as everyone else's.

He originally joined the company 15 years earlier as a hardware engineer, then the company downsized their hardware activities to focus on software, so moved sideways into software to avoid being laid off. I don't really think he wanted to do software, he was just sort of stuck there.

I think everybody on the team would agree he didn't meet the quality standards the rest of the team adhered to, but nobody wanted to fire him because he was a nice chap.

Eventually, we found a specialised hardware / software project for him to concentrate on, and things improved.

Better than being unemployed...
Tuesday, February 18, 2003

On the subject of the guy who taught college and yet was a bad hire, and the use of that claim to refute my point, I would say that it sounds like you weren't good at interviewing.

If I was interviewing a guy who taught at a college - or any recent graduate for that matter _ I would straight away know they would have all the buzz words and all the answers ready to rattle off. Thus my interviewing would probe other things. It would anyway.

I suppose interviewing is like development; there's a lot more to it than seems obvious.

Is a manager
Tuesday, February 18, 2003

It depends.

If I'd hired my best friend, and he was being a completely incompetent programmer, honestly it'd take me a long time to fire him.

In the general case, I'd first document the problem (as objectively as possible), then talk to the employee about the problem(s) at least once.  If that bears no fruit after a reasonable amount of time -- like, say, a few weeks -- I'd fire him or her as soon as possible.

It's not worth delaying.

Brent P. Newhall
Wednesday, February 19, 2003

*  Recent Topics

*  Fog Creek Home