How do you deal with a sloppy teammate?

If you know me, then you should know that I possess no people skills. I am a developer. One of the traits of a real developer is the lack of any social skills - it is why we develop and spend our lives around it so that we can minimize 'conversations'.

I have a teammate who has done a lot of sloppy code. Not sloppy code as in me being pedantic and whipping someone with my shoelace for using inline ASP.NET or using 'var' in C#. I mean proper sloppy code. This has happened in the past and in those cases, I have either

a) made changes to his code and told him what I did so that he'd learn
b) sat with him and told him what needs to be changed so that he'd learn

OK so far. But, his latest was a bit too much. I had told him to write a control which would call a service and return the ID (details not important). He did write it, but it doesn't return the ID! It just calls the service. No properties exposed, nothing. This is in addition to other points which I've told him about before, but he has just ignored.

I am not sure how to approach this problem. Do I tell the team leader? Do I tell him? Do I tell them both?

What I fear about telling just him is that he's going to think "Oh, he's fixed my code for me, I can now move on. Whoopdeedoo," and he'll never get it right.

Should I continue cleaning up after him or be a tattle-tale?

Get me a job instead, I right clean code...

No really is their any way that you could suggest having someone review his code rather than you having to rewrite it for him. Why is it that you have to rewrite his code? Does the team leader not make these checks. I can understand helping someone but clearly your help is wasting both your time and his since he is not taking it on board.

PS, my computer is dead taking all my code with it. :(

a. Lesson learned - I can write sloppy code; someone else will fix it.
b. Lesson learned - I hear a buzzing in my ear, write sloppy code and wait for (a) to happen.

:)

You certainly need to be a tactful, but you have to go to your boss and say - through your regular update report - "still waiting on joe to get me that code for the widget."

Eventually, you'll get into a 3 way pissing match, but ultimately, if the code needs to do X, and it doesn't do X then the person responsible for X will need to do it, or demonstrate why they can't do X.

(I'm assuming that you are peers - if you are in a supervisory role, then things are different).

I may agree with SJWhiteley, but I'd like to ask a couple further questions, first:

1) Why does he write sloppy code? The question has to do with his motivation. Does he simply lack skill? Does he not give a rat's arse whether he gets it right or not (just lazy or bored)? Or is he some kind of passive aggressive character who is actually quite capable, but is using poor code and unresponsive behavior to manipulate you/drive you crazier than you already are. If the reason is one of those earlier ones, then I'd agree with SJWhiteley that he learned the wrong lesson when you fixed the problem. If it's the latter, though, which really does happen, then your problem is FAR more difficult to deal with, because he knows how you feel and is enjoying it. The best thing to do in that case is probably get that 3-way pissing match going really quickly, especially if your boss will actually do something. You have to confront people like that and expose them, or else your life will get steadily worse until you end up under a bridge with a bottle of Thunderbird half in you and half on you.

2) I probably had a second question at one point, but by now I've forgotten what it was, so I'll make one up: If the guy is incompetent, is it because he is unskilled or is it a case of basic stupidity? The first can be taught, the second has to be managed for.

If the guy typically receives reviews such as: "Employee works well...when cornered like a rat in a trap." Then I would advise you to play LOTS of practical jokes on the guy. You won't get better production out of him, but you wouldn't anyways, so what's the loss? At the very least you can get some entertainment value from him. You won't get good work from him and there isn't much you can do about that, so entertainment is a viable alternative.

Meanwhile, this guy is probably complaining to the supervisor about you... about how you can't simply trust his coding, how you feel the need to constantly rewrite his stuff... etc. Needs to be nipped in the bud ASAP.

Hopefully you guys are using somekind of source code repository so that you have proof of his inadequate code.

-tg

I was about to say somewhat TG said but in a different manner. Are you sure your Team Leader/Manager cares what you speak or reports to him/them?

In my previous job, I had the same problem, and since I was looking after the project, I was expected to take care of all such problems. I reported the similar case to my project manager and instead of even letting me complete my sentence, I was blatantly told to shut up and asked me to mind my own business since that guy was having more experience than me so that made him a better developer involuntarily (atleast in my manager's eyes).

I would tell the guy to clean up his act! If it is a paid job? I would concerned if I was the client that the guy does not know what he is doing. If it is training I would tell the lecturer/team leader that this guy is not pulling his weight on the project.

I am rather surprised to learn that you are not the team leader. And in that regard goes my suggestion, you should work hard to be the team leader so will have more power to 'educate/eradicate' your subordinates.

I would firstly stop correcting this guys code.

If it would be noticed in time that this guy is writing messy code and components that don't work properly then let them catch him out.

If not then you will be probably be better off having a word with the team leader.

Say something Along the lines of i have concerns about person x. I wouldn't' go in with both barrel's though just let them know there is a problem.

Quote:

---

Originally Posted by NeedSomeAnswers

I would firstly stop correcting this guys code.

---

Bingo!

You don't need to tell anyone anything...let his job performance speak for itself.

But if Mendhak is like me that is a very hard thing to do. I often fix peoples mistakes in work, not for them but because I take pride in my job and I will not let anyone see their may be cracks.

At my work the solution is very simple add a task to his todo list to solve the sloppy code. The manager occasianyly looks at this list as well, hopefully for him he solves all request promptly.

And evreyone who says don't solve his code is right. It should stay his problem... keep it that way.

I have always been the developer that has people skills. I am hybrid with the ability to talk to people on their level and get things done effectively. My code can be mediocre at times so sometimes my coding skill does have peaks and valleys accordingly. This is why I felt I might be a better manager and supervisor than a down in the trenches programmer after 10 + years in the field.

I would choose to sit down in an "informal surrounding" and have a chat with the guy. Pick a place after work and agree to meet on that scheduled time and location. This eliminates defensiveness on his part and feeling like he is being critically picked apart. And then I would explain the situation of the documented times I have had to step in and correct the situation. I would ask him what his feeling are about the situation and ways that he might improve his performance. Then I would recommend he read the Pragmmmatic Programmer which is a pretty good book for tightening up code and documentation and all phases of the SDLC.

Then I would emphasize the need for both timeliness and accuracy in his work. You can send a project on time but if it not delivered with all its requirements then it is useless and likewise the counterargument if it is accurate but it is delivered late then it also lacks worth.

Reporting someone to a manager can be interpreted as "throwing someone under the bus" from a career stand point and this can cause problems down the road from the perspective of forming internal resentments with people you have to work with for the time being. People that might be incomptent in how they perform a task but now they have now become both incompetent and uncooperative once reported. Try the carrot before you try the stick.

Quote:

---

But if Mendhak is like me that is a very hard thing to do. I often fix peoples mistakes in work, not for them but because I take pride in my job and I will not let anyone see their may be cracks.

---

That's fair enough but if people don't learn from there mistakes or are just lazy that must become very frustrating. I mean i like helping people out and take pride in my work but you can't keep doing someone's job for them.

Quote:

---

I would choose to sit down in an "informal surrounding" and have a chat with the guy. Pick a place after work and agree to meet on that scheduled time and location. This eliminates defensiveness on his part and feeling like he is being critically picked apart. And then I would explain the situation of the documented times I have had to step in and correct the situation. I would ask him what his feeling are about the situation and ways that he might improve his performance. Then I would recommend he read the Pragmmmatic Programmer which is a pretty good book for tightening up code and documentation and all phases of the SDLC.

Then I would emphasize the need for both timeliness and accuracy in his work. You can send a project on time but if it not delivered with all its requirements then it is useless and likewise the counterargument if it is accurate but it is delivered late then it also lacks worth.

---

The problem with this is if you are not this guys manager, then why should he listen to you ?

You might not even have a social relationship with him, and unless you are a manager or team leader of some sort, i can see a lot of people getting hacked off by you telling them there short comings in a sit down meeting.

I understanding where you are coming from Christopher but to me that sounds like an approach that is a lot easier for a team leader or manager to take than just a work colleague.

Quote:

---

Originally Posted by NeedSomeAnswers

That's fair enough but if people don't learn from there mistakes or are just lazy that must become very frustrating. I mean i like helping people out and take pride in my work but you can't keep doing someone's job for them.



The problem with this is if you are not this guys manager, then why should he listen to you ?

You might not even have a social relationship with him, and unless you are a manager or team leader of some sort, i can see a lot of people getting hacked off by you telling them there short comings in a sit down meeting.

I understanding where you are coming from Christopher but to me that sounds like an approach that is a lot easier for a team leader or manager to take than just a work colleague.

---

Put it this way..he doesn't have to listen to his colleagues at all. Nothing says that he does. He could keep going down the path that he is going which will lead to be reprimanded by his superiors and possibly fired if reported enough times for failure in performance. I mean why continue to pay someone an annual salary if the next programmer has to always make corrections on his work.

The impact on the operational budget is reduced considerably and efficiency based on the workload is maintained... albeit you have fewer programmers you have a team of more competent programmers minus one that wasn't lending anything to the operation in the first place.

It is pretty simple math.

It is in his self interest..his better self interest to listen to what is being said. And past that point your responsibility ends if he chooses not to do so.


However, to choose the tack of mentorship and so that he can self correct and learn might be a possiblity if he is receptive to the prospect..is a positive one and not just one slated for managers altogether.

A colleague who is respected for his computer savvy and prowess in IT is just as effective to fill that position of leadership. You can lead a team to be either great as independent thinkers or a collaborative unit that works well together. Remember the expression a team is only as good as its weakest link in the chain ?

Mendhak and others like him might find themselves referred to as a group as delivering sloppy code as a unit because this guy's code reflects on the whole organization. It creates an impression that if one guy on the team can submit this kind of work then the others must be no better.
(Though this is a generalization, I have seen this in IT a lot in my time as a developer.)

The same applies to IT groups of developers. Users and clients see the IT departments as a whole not just as individuals, so when one person drops the ball the impression of the whole staff goes down.

The thing of it is..I am on a unqiue end of that comparison, Mendhak mentioned in his topic. I am a developers who is given very little in the way of instructions or clear specifications to begin a project. I get very muddled or vague instructions from my manager.

And then when I ask him for clarification, he says he shouldn't have to spoon feed me otherwise he could do it himself. And yet he can not reproduce those results himself. He is a spaghetti coder himself and most of the stuff he writes is incorrect from what I have seen demonstrated on my end.

Now I don't consider having a basic thorough understanding of what is being done and how it is being done as spoonfeeding, in fact it saves me from multiple trips to his office having to ask x or y questions. Following this he get impatient for results and then loud and rude and then either I deliver the project he has in his mind that he wants or he gives it to another developer. Either way I suffer due to a lack of organization of the department as a whole however structured and methodical I may be in my practices. Right now ,I have to generate a crystal report.

He has given me one sentence of vague explanation for what is to be done and one view name however several views are required to create the report and he has released that information and he says it is my legal responsibilty to know every view, and every table we use and that I have been there for 2 years and that I should know that.

Now we have well over a 500 - 1000 databases sitting on x servers each of which might have hundreds of tables and views and within them x fields. Now I have not worked on projects that have dealt with said information nor am I a DBA. I might know x databases but certainly not all of them.

So my point it that it can swing both ways you can have sloppy workers and sloppy managers and both can impede the progress of an existing project. One is actually harder to deal with because incompetent management is hardly accountable and is harder to get rid of in the organizational chain hierarchy. The sloppy worker can be fired outright through case building over time.

Quote:

---

The thing of it is..I am on a unqiue end of that comparison, Mendhak mentioned in his topic. I am a developers who is given very little in the way of instructions or clear specifications to begin a project. I get very muddled or vague instructions from my manager.

---

I sympathise that's probably an even worse situation !!!

I have been somewhere quite a few years ago (8 years in fact, wow time moves fast) now. I would get a spec from my manager, i would develop to that Spec, then i would go to the user to do some testing, who would say "you have missed out the 'process' that happens here or the Document produced there".

Obviously in my Managers eyes this was my fault, i should have clarivoyently Known or found out somehow !!!

Once i was given a piece of work just before i was due to go on Holiday, i mean i had to leave Work bang on time as we were flying that night, my manager knew this and yet they gave my a piece of work to do which i could only just about get done, but not test in anyway.

I told them this, that the components had not been tested but i really had to go, and they said yeh fine go it will be fine. They rolled out the change while i was away, and there was a fault, a minor fault with it. When i got back i get a right earful in my appraisal.

Anyway i eventually was 'let go' by the said company because my manager didn't think i was good enough.

Turned out to be the best thing that ever happened to me, my next job was for a company where i had a brilliant manager & a much better company than where i had been.

I am on the end of that curve where the bad manager has all of the cards to build his case in terms of his authority, performance evaluation and annual review though I've been documenting what has been going on. Though he has been an ogre of micromanagment and harassment to some extent. The main problem is one of communication and proper directions to get the job done right the first time.

I have been passed over for raises and bonuses while others have by his recommendation gotten them due to his evaluations/ and assessments. This is where IT jobs become less about merit and accomplishment and more about politics. About who is on the good side of whom. People who had complained about him in similiar fashion when I arrived but have stopped now that they have been rewarded by him even though he continues the same lack of protocol , and organization and berates others blameshifting the lack of progress on them and not taking his share if any for the accountability of why the progress on a project hasn't been met.

With this economy, a new condo, a new car and a baby, I might find myself out of work as well but I am interviewing right now to see if I can leave on my own terms.

If you really want to help him you should first stop correcting his code and ask him to do himself. If he still doesn't do it correctly, you should escalate the matter with the Team Leader/Project Leader/Project Manager. He may feel a bit bad but that's in his interest if you bring the matter to their notice. They are the right persons to take decision in this matter, not you.

And jokes apart, If I were your Project Manager, it would have been you who would have got all the warning/scolding/firing, because you are doing someone else's work instead of concentrating on yours. Each team member is given a certain amount of task and it is expected that the same team member does it, not someone else. Otherwise why would I put 2 team members for a work if one is doing all the work.

I would just for my part in closing say if the positions were reversed would you want the guy to go your manager and report you for faulty code from the beginning and place your job on the edge ? How would you look at him exactly ? It it better to look at things from all angles and in the long term because if you complain to his superior you may still have to have a working relationship with him afterwards and this will be strained because it will come to light that the complaint came from you. I am not saying you won't have to do that later but it is important to give him some length of rope first before becoming the hangman too early.

In the short term, it would create the disciplinary action to motivate him to clean up his act, and you might get the results that you want but the expense might be too high.

I am not saying you have to be a diplomat, that is not in your job description as a developer. However, the corporate world of IT is also a political one and it is like chess and you have see moves and countermoves twenty steps ahead of when you make them. Its not just about the work. It is also about the team relationships, the organizational relationships that are necessities to get the work done.

Quote:

---

Originally Posted by mendhak

I had told him to write a control which would call a service and return the ID (details not important).

---

There seems to be a problem with the team leader here...

How come you gave the guy work to do, has the team leader assigned you to mentor this guy or assign tasks to him or something? If that's so, you can follow any action that's appropriate according to company practice - that could be to eat his lunch and tell him to get his act together or write a few test cases and let him know that his code will be complete when it can successfully pass the test cases. It all depends on how you do business in your company.

If, on the other hand, you're not personally responsible in any way for the guy I think that it's the team leader's immediate problem and you should leave it at that. Not the coolest way to go through the project but that's the way it has to be. Obviously he's going to slip (and this may result in more work for the other team members) but it's up to the team leader to decide what to do with the guy.

I still say that the solution depends on what the source of the problem is. The observed results can arise from at least three different causes, each of which needs to be handled differently, so identifying the cause is the first, critical, step.

Not all organisations work the same. Our Team Leaders are in semi-managerial roles, I get to do the design bits. Why should someone else have all the fun? ;)

You're right, he's not actually my responsibility, but as someone mentioned, I don't like this stuff in our application. It's a brand new app, we've learned a lot from previous apps and are trying to get this bit right. It's like project OCD. I can't help it. I have to have something done about it or I can't breathe. When I see some moron use inline code, I can get them to fix it by standing right next to them while they do it. That's small stuff though.

I have no way of telling if he writes bad code or if he lacks skill or if he's stupid. How do you tell the difference?

The clear message I'm getting here is that I shouldn't have corrected his code. I'll adhere to this. I'll have a talk with him and the team leader, although that's the bit I dread, being the tattle tale - I'll tell them that the task is not done despite claims to the contrary. I suppose it's for the greater good. And of course, this makes me nervous.

I have read all your posts, thanks for the responses.

Quote:

---

Originally Posted by mendhak

I have no way of telling if he writes bad code or if he lacks skill or if he's stupid. How do you tell the difference?

---

He passed the interview and got the job didn't he? If he did that then I doubt he is really stupid! Maybe he is lazy.

Quote:

---

Originally Posted by NeedSomeAnswers

I would firstly stop correcting this guys code.

If it would be noticed in time that this guy is writing messy code and components that don't work properly then let them catch him out.

If not then you will be probably be better off having a word with the team leader.

Say something Along the lines of i have concerns about person x. I wouldn't' go in with both barrel's though just let them know there is a problem.

---

Quote:

---

Originally Posted by Hack

Bingo!

You don't need to tell anyone anything...let his job performance speak for itself.

---

Writing sloppy code doesn't mean that the code/component won't work properly or at all. If his/her unorthodox code could get the work done in almost same time, then I guess no manager or leader would mind his style of work and s/he will the benefit even after not following standardized method of coding. (Well speaking from my experience, I could be wrong)

I could have agreed with the lower performance in the long run though. But how many top level people care about that anymore.

Quote:

---

Originally Posted by Nightwalker83

He passed the interview and got the job didn't he? If he did that then I doubt he is really stupid! Maybe he is lazy.

---

I think the team mate is really smart, if he is getting someone else do the work. At the end of the day, when the appraisals come into picture, nobody will remember that each delivery had bugs that were fixed by someone else.

:wave:

Quote:

---

Originally Posted by Nightwalker83

He passed the interview and got the job didn't he? If he did that then I doubt he is really stupid! Maybe he is lazy.

---

Oh, I don't know about that.... we had one guy at my last job.... seemed to talk the talk during the interview.... references seemed kosher... we brought him on board as a contractor.... at the 3 month mark, fortunately we had discovered that he really wasn't all that.... and got out of the deal. His coding technique... was unorthodox to put it mildly. We had him write some queries we needed for a report.... given X inputs, we wanted ABC outputs..... and true to his credit, if you input X, you got ABC..... but if you put in Y, in stead of getting DEF.... you would get WERTDRYFTJHRFD. So some one started investigating what he had done.... he had built thist complext series of Views and SProcs and functions.... that were all interwoven with each other and hid basically what he had done.... hard coded the report. Even months later we weren't sure if it was a stroke of genius... or an attempt at hiding what he didn't know how to do. We eventually re-wrote the query, replacing the nearly 20 DB objects with 2 queries and increased performance 1000-fold.

-tg

Quote:

---

Originally Posted by mendhak

Not all organisations work the same. Our Team Leaders are in semi-managerial roles, I get to do the design bits. Why should someone else have all the fun? ;)

You're right, he's not actually my responsibility, but as someone mentioned, I don't like this stuff in our application. It's a brand new app, we've learned a lot from previous apps and are trying to get this bit right. It's like project OCD. I can't help it. I have to have something done about it or I can't breathe. When I see some moron use inline code, I can get them to fix it by standing right next to them while they do it. That's small stuff though.

I have no way of telling if he writes bad code or if he lacks skill or if he's stupid. How do you tell the difference?

The clear message I'm getting here is that I shouldn't have corrected his code. I'll adhere to this. I'll have a talk with him and the team leader, although that's the bit I dread, being the tattle tale - I'll tell them that the task is not done despite claims to the contrary. I suppose it's for the greater good. And of course, this makes me nervous.

I have read all your posts, thanks for the responses.

---

That's exactly right. You have no way of identifying the source/cause of the problem only the effect. As for the tattling part you mentioned well good luck with that.:) He is not your responsibility but that door also swings the other way . It isn't your responsibility to code after this guy or for that matter go to your mutual boss to complain about something he is responsible for delivering unless he is working on a project that you are sharing that affects your part of it somehow. That's the sticky part.

I suppose I also am looking at your post from the perspective of the other guy. I work with a teammate whose job is to publish applications or reports on the network I have written. Now apps/ reports can and often do have bugs and I try to keep both to a minimum but instead even with the minimum he goes straight to the boss about how this doesn't work and this works funny in my code without ever having talked to me about it and his cubicle is right next to mine. Now he doesn't have an obligation to tell me anything and that's fine. But is my eyes now he is a jerk who is looking curry favor and now when he needs help or if he required my help then I would tell him I was busy and had no time for him..because that's the tone of the work relationship that was set by his actions.

Quote:

---

The clear message I'm getting here is that I shouldn't have corrected his code. I'll adhere to this. I'll have a talk with him and the team leader, although that's the bit I dread, being the tattle tale - I'll tell them that the task is not done despite claims to the contrary. I suppose it's for the greater good. And of course, this makes me nervous.

---

I don't think you need to go to the team leader at this stage and I'd advise against it. I think Pradeep had it right. Not only should you not correct his code, but you should ask him to correct it. That doesn't need to be confrontational. A freindly "Dude, you forgot to return the ID" while grinning from ear to ear would do. No doubt he'll make other mistakes, at which point keep grinning and keep getting him to fix them. You're being freindly, he's getting embarrassed and evetually he'll start to get right the first time. The only drawback is if he is just being an ass as Shaggy mentioned. If that's the case it'll become obvious quite quickly because he'll give you attitude and then you'll be justified in raising it to you team leader.

I second FunkyDexter's method, what if this guy has say an issue at home or something and you go complaining about him only to get yourself embarrassed. At least if you follow this method you have exhausted all options and where polite and respectful in the process. My view is most management are aware of issues even if you think they are not and you may, as you say be seen as a tattle tale.

As it turned out, the Team Leader wasn't in today and I ended up talking to him instead. I sat with him for about 40 minutes and showed him everything that was wrong. He saw everything was wrong, acknowledged it and said he'd be more careful in the future. Do I believe him? Not at all.

I absolutely disagree with anyone who says that this should be 'let go'. I code because it's my hobby, and it just happens to be a job. Yes, there are people who view it as 'just a job', which is very unfortunate because even if I don't clean up their mess now, someone is going to have to clean it up in the future and they will wonder why this was passed.

Quote:

---

Originally Posted by abhijit

I think the team mate is really smart, if he is getting someone else do the work. At the end of the day, when the appraisals come into picture, nobody will remember that each delivery had bugs that were fixed by someone else.

:wave:

---

Not really - the people I work with who will evaluate him aren't that obtuse, and they'll be asking me for my opinion of him when the time comes.

It's not a very formal environment here, it's almost remnant of the code-companies from the 90s where the managers would step back, let us do our stuff and then give us pizza when we got the job done. Almost.

I've had people like techgnome's example join the company with devious ways of doing things. Devious in a malicious sense here. The mess they leave behind isn't worth the politeness and beating around the bush. Case by case basis.

We hired a guy who was supposed to take over some things I had done (back when I wasn't paid to code). I went out to lunch with him to discuss this and that and figure out what his skill level was. I couldn't understand a damn thing he said, and it turned out that nobody else could either. He didn't last long.

It sounds to me like you have found a person who just does sloppy work. It will never really be fixed.

Quote:

---

Originally Posted by mendhak

As it turned out, the Team Leader wasn't in today and I ended up talking to him instead. I sat with him for about 40 minutes and showed him everything that was wrong. He saw everything was wrong, acknowledged it and said he'd be more careful in the future. Do I believe him? Not at all.

I absolutely disagree with anyone who says that this should be 'let go'. I code because it's my hobby, and it just happens to be a job. Yes, there are people who view it as 'just a job', which is very unfortunate because even if I don't clean up their mess now, someone is going to have to clean it up in the future and they will wonder why this was passed.

---

I agree with you. In fact some time back I had to clean up existing code from a developer using VB6 about 3-4 years ago. Not only was it spaghetti code that was sloppy and unorthodox but I found that he used third party software..something from Infragistics if I recollect and it was a trial version of the software because the license key expired. When I told my boss she was livid because to replace it would cost $ 500. I think they got off cheap but that was my worse experience to date. The programmer in question was my predecessor I replaced when I was hired but they looked so angry that could have spit nails.:)

Quote:

---

Originally Posted by techgnome

Oh, I don't know about that.... we had one guy at my last job.... seemed to talk the talk during the interview.... references seemed kosher...

---

Obviously, one would implement a checks to ensure the person knows how to do the job they are actually applying for.

Quote:

---

Originally Posted by mendhak

Not really - the people I work with who will evaluate him aren't that obtuse, and they'll be asking me for my opinion of him when the time comes.

It's not a very formal environment here, it's almost remnant of the code-companies from the 90s where the managers would step back, let us do our stuff and then give us pizza when we got the job done. Almost.

I've had people like techgnome's example join the company with devious ways of doing things. Devious in a malicious sense here. The mess they leave behind isn't worth the politeness and beating around the bush. Case by case basis.

---

I hope you are right. I have seen things go either way from a point of view of employee evaluation.
:wave:

Quote:

---

Originally Posted by Nightwalker83

Obviously, one would implement a checks to ensure the person knows how to do the job they are actually applying for.

---

And praytell, just how does one do that? How do I know that the guy I just interviewed knows how to do the job?

-tg

Quote:

---

Originally Posted by techgnome

And praytell, just how does one do that? How do I know that the guy I just interviewed knows how to do the job?

-tg

---

I worked with a company that prefer giving tests to their candidates.
This is not for experienced programmers.

The tests are simple like create a webpage that will take two inputs and add them to the database or create a login page.

You'll be surprised at the results, since each programmer has his own way of doing the simplest of tasks. You could eliminate the sloppy ones.

Quote:

---

Originally Posted by techgnome

And praytell, just how does one do that? How do I know that the guy I just interviewed knows how to do the job?

-tg

---

There is one way techgnome to decipher whether someone is really good at programming or mediocre or perhaps even none of the above.
Well... in one of my own interviews going back a few years in the final round of interviews,I had to sit down in an open cubicle and take a test to prove I was capable to hold the position. I had given them references and talked a great deal about my background but that wasn't enough. They needed proof.
The Senior Developer made up a test comprised of a scenario that they normally deal with in the office that required a programmatic solution to solve.

They wanted to see my logic( pseudocode or using the programming language they based their applications off of) as to how I would solve the problem and it was a timed test as well..I had a half an hour to complete it. It was graded shortly thereafter and they gave me the job.

Quote:

---

I absolutely disagree with anyone who says that this should be 'let go'. I code because it's my hobby, and it just happens to be a job. Yes, there are people who view it as 'just a job', which is very unfortunate because even if I don't clean up their mess now, someone is going to have to clean it up in the future and they will wonder why this was passed.

---

Absolutely right, if you let it go it will just keep on happening.

Actually your Team Leader being off has allowed you to give this guy a chance which is positive.

If they do indeed carry on as before the very fact that you have tried informal ways of correcting the problem first means that he can have few complaints if he doesn't listen !!

Also if you do eventually have to go to a Team Leader then you can say, "I have done all i can to correct X Persons coding issues, i have sat with them an explained proper process but they refuse to listen"

It generally puts you in a stronger position i would say.

Quote:

---

Originally Posted by techgnome

And praytell, just how does one do that? How do I know that the guy I just interviewed knows how to do the job?

-tg

---

There are simple tests you can give the applicant to find out whether he/she is suitable for the job! As abhijit suggested a simple test like writing code for a web page or whatever could take care of the sloppy applicants.