Discovered developer doing Leetcode puzzles when he should be working

Question

I hired a remote developer to work on a project with a client some months ago. He has been playing around on LeetCode throughout the working day hours, when he has active tasks in progress. I'm estimating for up to two hours per day.

They are not communicating that they are blocked on their tasks, so I consider this stealing from the client and myself.

How can I deal with this person to stop this behaviour?

The developer is slow at delivering work, and their contract states 8 hours/day work time.

Answer 1

I consider this stealing from the client and myself.

Steady there... that's a pretty big accusation to go throwing around. And you run the very real risk of torpedoing any chances of a constructive conversation if you take that mindset.

First up ask yourself - if you weren't aware of this activity on leetcode would you otherwise be happy with this person's output, timeliness of delivery etc? Because if so you might be looking at this wrong, for many people solidly working for the full eight hours of a work day is difficult and short informal "breaks" can actually help maintain a higher productivity over all. Whether that's stepping out for a smoke break, checking the news, answering a question on Stack Overflow or, yes, doing a puzzle on leetcode. People aren't machines - and as such we all have our little quirks that we have or do as part of being productive.

So if you're happy with their performance - I'd suggest you do nothing.

But what if you aren't? If there are performance problems - missed deadlines etc then you need to address those exactly as you would any other time. Communicate with them, let them know that you need more from them and ask if there's anything stopping them delivering. I wouldn't mention the leetcode activity at this point, I still think it would be counter-productive, them getting defensive and feeling spied upon isn't likely to help matters (even if your concerns are justified) - see if they improve. If they don't, and you're still seeing similar levels of activity on leetcode you could bring it up then as a last ditch effort to shape them up. But ultimately what matters is whether you're getting results from them, and if you're not then you need to replace them with someone who will.

When you go to a restaurant you don't go watch the chef and criticize his technique - you care about how the food tastes, not how it was prepared.

Answer 2

I'm going to assume this developer was explicitly hired to perform X hours of work a day for this client.

Do you have any proof that they aren't doing X hours of work a day? Unless their contract/agreement requires them to do those X hours during "the working day hours", your only concern is that those X hours are getting done.

I'm a remote developer. I'll often take breaks in the middle of the working day to exercise, play with my kids, do laundry, shop for groceries, clean my home, etc. That in no way means I'm not delivering the X hours a day I'm supposed to.

So unless you have proof that they aren't doing the X hours they're paid to do, you're really just spying on someone's private life. Which, in my opinion, is pretty abhorrent behavior for an employer to do.

From some of your comments it appears that you think the "developer is not 'good'", and their performance is "subpar". If this is the case, that is all you should be concerned about. You are paying someone to deliver a certain volume of work at a certain quality; they either meet your standards or they don't.

If they meet your standards, you shouldn't care what else they do during the day or what hours they do it in. If they don't meet your standards, you shouldn't care either: Let them know their output and/or quality isn't up to your standards, and either give them the opportunity to improve or replace them.

Answer 3

You mention in the comments that you have serious issues with this particular developer's output. This is your problem right here, not the hours and not that they are on a coding tutorial site for a few hours a day. Their output might even be something that they are trying to remedy by going onto Leetcode.

You're going to be much better off having a conversation with them about the obstacles they are facing. Perhaps they are not skilled enough in the technologies you use. Is it possible the challenges in question are related to tech being used by the client?

Let them know that if they are having difficulties in getting the work done, you need to know. And you can even help them if need be.

Answer 4

As others already said, if you are unhappy with their output, then please talk to them about their output. If you expect a better output for the money you pay, by all means say so and act accordingly.

However:

They are not communicating that they are blocked on their tasks so I consider this stealing from the client and myself.

While you have bought their time, programming isn't a job where you can hack at a keyboard for 8 straight hours. You will always have phases (and the more often the more senior you get) where you have to wait for something. This very answer here is for example brought to you courtesy to a typescript open api generator bug that I fixed... and now I have to wait 15 minutes for all tests to pass. Has my employer bought my time and are they entitled to order me to just stare at the slowly moving progress bar on my screen and not post here? Yes they are. But insisting I do so would not make their task go any faster.

In the office, I would use this time to get up, stretch my legs, use the restroom, maybe clean the coffee machine or fill the community kitchen dishwasher. Not exactly the tasks in my working contract and certainly not bringing our app closer to completion. Since those tasks are not something you can repeat as often as you like (at some point the coffee machine is clean enough), I do answer questions on Stack Overflow. Because I have to wait.

Now you could ask "But there is so much more work to do, why do you wait, just take the next ticket!". Well, yes. That is fine when tickets are no-brainers. But they aren't. You have to load up all the knowledge required and that means "unloading" all the previous knowledge from the ticket in waiting, because brain capacity is limited. I work for you so I filled my brain to the hilt with everything I need to do the task I have, there is no extra room I held back.

In actual hardware that is called "setup times" according to my dictionary. The time a machine takes to be setup to do something else. If you have a machine furbicating widget A and you can set it up to instead fobicrate widget B, then you can do something else with the machine if you don't need widget A furbicated. Lets say between 11:00 and 12:00 the foreman for furbicating is on their break, you could set up the machine to fobricate widget B in that hour. But setting up the machine does not come free. It takes time. If it takes 45 minutes to change it to widget B and then 45 minutes to change it back, your order of widget A will be delayed if you actually do so. Just because you can does not mean it's a good idea.

The same goes for knowledge workers. Imagine the brain to be a memory space, you can upload all the context for task A. And then you have to wait 20 minutes. Uploading context for B might take 15 minutes, but it will delete the context for A. Now... you could do B while you wait, but then you will need another 15 minutes to drop B and upload context for task A again. Which is a net loss. Do it once and task A will be late, do it multiple times a day and you will have performance problems because all you do is context switching instead of staying in one and working.

For me, cleaning the coffee machine, answering Stack Overflow questions or stretching my legs all keep the context of what I did before. They aren't super challenging. Starting a new piece of work will lose the context and I have to aquire it again, costing time.

As an employer you do have the right to frustrate me by ordering me to watch the progress bar instead of posting here. But again... the task does not finish one second sooner if I actively watch it.

So... your focus should be on whether that developer reaches the goals you agreed on. Quite frankly, whether they slave away 8 hours typing franticly on their keyboard or whether they meditate 6 hours and then slowly type their perfect solution or whether they are on hackerrank should not concern you.

Do they get their work done, or not?

Answer 5

Developers aren't factory workers. It is a tough job that requires thinking and downtime. Doing Leetcode problems might just be part of his creative process. It's also tough to compare developers to each other. Everyone's different and has different productivity and ability.

Answer 6

There is only one question you should be asking yourself.

Can we replace him with someone who performs better?

If the answer is "No", or "I don't know", or "We don't have the time", or it will be "crazy expensive to hire someone else and get them up and running" then it's not like you have much of a choice right now.

I'm sorry if I'm stating the obvious. But the market is crazy right now. Developing good software is crazy difficult. And good developers are very hard to find (mostly because the number of new developers keeps on doubling every 5 years). And even if you could find a sole developer who is seemingly just as good, there is no guarantee that their performance won't be just as slow if not slower.

...so I consider this stealing from the client and myself.

Hey, I love using metaphors. Metaphors are a great tool for communication. But be careful with metaphors. They can frame your thinking in the worst ways. If you're not careful, they could induce you to torpedo a business relationship that has been quite lucrative for you.

Because no, most pass-through contractors/recruiters still get their commission even if the contractor takes longer to do the work.

Now perhaps, your contract is not structured that way, and perhaps, you're eating the cost of the delays personally. But if that's the case, I think that opens up a plethora of other issues.

And no, you can not control what he does at home unless you take a hands-on approach and pair program remotely with him 60-90% of the time, which is probably not a viable solution either (otherwise you would have done so already).

The bottom line is this. Focus on the parts you can control. And forget the rest. And if you haven't told the client about this Leetcode issue, don't tell him. But do tell the developer. He needs to know that people might get the wrong idea.

Answer 7

It's none of your business what happens on their Leetcode account.

But at least your employee will be in a better position to interview for the next job once they decide they had enough of your snooping and micromanagement

I consider this stealing

and your attitude

Answer 8

Is it also in the contract that you get to specifically define what "working day hours" means to a remote developer? I am getting a micromanager vibe from you, but you don't know if the developer is doing any work at times other than this notion you have in your head of some fixed, immovable time frame. You're also not considering that it's really tough to wake up in one's home and sit at a desk all day. Are you expecting this every day? Really?

I guess the real question comes down to this other notion of "slow" that you've mentioned here. What (or who) is your benchmark? Is the developer turning over quality work, or work that needs a lot of fixes to make it work correctly? What's the total benefit that the developer is bringing to the project and team?

If you harass or start the blame game with this developer, you may find yourself short staffed. The market's at a place right now where nobody needs to put up with a micro-manager. The numbers have proven that remote workers are actually more productive than workers were when they were still commuting to offices. If you're choosing to make demands beyond the inherit plusses of having a remote worker, maybe it's time to look at yourself to figure out if your approach is a bit extreme. Consult with other managers that you trust. There are some things that you're just not going to be able to control as you could in the past.

Answer 9

Most answers, including mine, agree that the actual problem is the sub-par output.

Yes, being distracted (and potentially not working the promised 8 hours per day) is one possible reason. Even if one thinks that remote work is flexible, doesn't have to happen in a single 9-to-5 block etc., one could still bring up the online activity one noticed and suggest that staying focused would improve output. But spending time with Leetcode indicates lacking motivation. And that is not a one-dimensional problem.

Once we recognize this as the actual issue, we could do what any good boss would do: Ask whether there is anything you can do to help the developer. This question has multiple functions: It shows the developer that you care. It shows that you think it's not them to blame. It shows them that you think they are valuable because you are willing to invest in them.

Suggestions for trying to improve work satisfaction and motivation:

• Is there anything they'd rather do instead of the assigned task?
• Would they rather like to be teamed up with somebody else, or work in a team to begin with (instead of alone)? Missing the office work interaction is a common issue raised by remote workers.
• Do they need better equipment? Even contractors may appreciate financial support for a better machine or screen. Bad equipment is a major nuisance, and the actual cost of hardware pays off quickly if it leads to greater productivity because labor is expensive.
• Do they need more information, better documentation, or an assigned go-to person for any questions they have? Asking a person in the know often replaces hours of frustrating attempts. While the go-to person's performance likely will suffer a bit the net effect is often positive. Being left alone with problems is frustrating, while working together increases motivation.
• Do they need better software tools?

Answer 10

Save yourself hurdle for the future and stop assuming that you can assume people hired for remote work sit and work for X hours just like the regular office workers, because you can't effectively control it. If you're not OK with that, don't hire remote workers.

Working with remotes is similar to outsourcing - you need to concentrate on the output, and not on the amount of reported hours. If you're satisfied with the output-to-cost factor, it's great, if not, it's time to look for other remote partner.

I assume you are obsessed with the reported hours because you bill your client based on the input from the remote worker. Sorry, but it's lazy on your side. It's your job to report hours to your client based on your judgement, and not just lazy forwarding the hours reported by the employee. If your role is the forward man, your boss could ask, why should they pay you?

Answer 11

Pick your battles carefully.

If the developer is doing good work and delivers with high quality on time and budget and if you and the client are generally happy with the results you are better off leaving it alone.

Focus on outcomes and results, not on the way it's done. Everybody has their own personal work style and rhythm. If it works, don't mess with it.

If there are issues with the quality and timeliness of the work, you should certainly discuss this, but make it about the outcome.

Answer 12

You are simply not going to get 8 hours of pure programming, per day out of anyone on any long term basis without serious burnouts. 5 hours a day is really the most you can expect and even from seasoned pros there is probably going to be a decent break in between projects if things are done in a healthy manner.

This again stinks of people who have never tried any prolonged programming sessions and don't know what it takes out of you. The high-level thinking that programmers do is not easy and it leads to real mental fatigue. Maybe you should try and program for 8 hours and let us know how it makes you feel before accusing anyone of theft.

And just BTW you sound like one of those entitled business owners who are not willing to pay an Indian more than 10$ per hour and then is surprised when he get mediocre work.

Answer 13

They are not communicating that they are blocked on their tasks so I consider this stealing from the client and myself.

Unless the client is paying for piecework, rather than for hourly work, it's understandable that you would be unhappy. Likely the client would as well.

Any advice on how to deal with this person to stop this behaviour?

If this developer is otherwise solid, getting tasks done within the expected time frame and writing good code, then give him one warning. Make it clear what his job is, and how he should be spending his time. Make it clear what the repercussions will be if this behavior continues.

Otherwise, get rid of him.

You probably only have found a small part of what he is actually doing. He has demonstrated that you can't trust him, and trust is vital for remote workers.