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.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – motosubatsu
    Commented Feb 11, 2022 at 9:23

13 Answers 13


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.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – motosubatsu
    Commented Feb 8, 2022 at 14:08
  • 57
    There is always an instinct is to go 'policy', that is: 'you can/can't do X while working' instead of the more managerial 'why is performance good/bad'. Using policy to create output can lead to toxic environments, where actually managing the situation and lead to positive and cooperative solutions. Though, the situation may dictate otherwise.
    – RomaH
    Commented Feb 8, 2022 at 17:02
  • 4
    Yes, this is an excellent reason why programmers should not work on a per hour basis. Just because I refined my workflow to where a 8 hour job takes me 6 hours to do, I should have my pay docked???
    – Neil Meyer
    Commented Feb 10, 2022 at 20:02
  • Although I don't disagree with your answer, the OP has stated "The developer is slow at delivering work". As far as your restaurant analogy goes, if the food takes a long time to arrive, the customer has a right to criticise the establishment. In this situation, the OP (restaurant manager) has noticed one of the chefs is slower than the other apparently because he's playing on his phone a lot and presumably wants to address the issue before the client complains. Whether the food tastes good or not is a separate issue. Commented Feb 16, 2022 at 13:19

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.

  • 45
    I agree with this answer. The real problem is that the author does not appear to be happy with the productivity of the contractor they have hired. There is a simple solution to that problem, end the contract, and find a contractor that is more skilled. Of course the author will pay more for the better developer. The author should also make sure to put their productivity expectations within the contract itself.
    – Donald
    Commented Feb 7, 2022 at 14:34
  • Good point indeed
    – PM 77-1
    Commented Feb 7, 2022 at 21:44
  • 2
    Well, one still could bring up the online activity one noticed and suggest that staying focused would improve output. Commented Feb 8, 2022 at 12:51
  • 2
    @Peter-ReinstateMonica But they might be totally wrong about that and "staying focused" might actually reduce output. I very much doubt that "work 8 hours without a break" is good advice for even many people, much less all of them.
    – cjs
    Commented Feb 10, 2022 at 3:59
  • @cjs True enough. Commented Feb 10, 2022 at 8:44

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.

  • 13
    On the other hand, a cynical but somewhat plausible assumption would be that he is fully aware of the output issues and that is part of the reasons why he's started doing leetcode, to prepare for job interviews elsewhere.
    – Peteris
    Commented Feb 8, 2022 at 4:29
  • 4
    This. Leetcode is more for job interviews than real life development problems, even if job interviews use it as proxy for overall development skills.
    – ojs
    Commented Feb 8, 2022 at 7:57
  • 8
    @Peteris: If he’s looking for a new job it can also be because he’s unhappy with OP or the tasks given by OP.
    – Michael
    Commented Feb 8, 2022 at 8:25
  • 1
    "Their output might even be something that they are trying to remedy by going onto Leetcode." - Agreed. I use Stack Exchange and stuff all the time as a means of study to maintain my performance at work. Just today, I had noticed an esoteric question on another SE site (a particular one which I actually do usually try to avoid during work hours, but it still caught my eye for just a second). In a few minutes, this led to me finding out about View->Show Symbol->Show All Characters in Notepad++, which can be useful for displaying things like CrLf. Commented Feb 9, 2022 at 17:58
  • As with all things in life a easy going attitude is more productive than an adversarial one. You may find that the employee underestimated how hard the work is. Maybe just putting him on some more newb friendly projects is an easy fix. Like Leonard Hofstader once said, you catch more flies with honey than with vinegar.
    – Neil Meyer
    Commented Feb 11, 2022 at 7:19

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.


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?

  • 13
    I'm reminded of my previous job where part of the onboarding was to practice manually compiling a codebase we were in charge of managing the automation of the compiling of - where in those onboarding steps, the compiling steps that took a while had follow-up steps "Get a cup of coffee from the coffee machine for 15 minutes - it'll take a while.". Some steps just aren't expected to be made faster just because someone's at their desk the whole time watching it. Commented Feb 8, 2022 at 0:00
  • 5
    @nvoigt I agree with all of this, except that I'm not sure that "you have the right" is the best way of thinking about this for anyone involved. Employers have a right to be idiots, I guess...But employees of such employers also have the right to leave. The point is that it's never in anybody's interest to micromanage at that level. Commented Feb 8, 2022 at 2:39
  • Obligatory: heeris.id.au/2013/…
    – VGR
    Commented Feb 8, 2022 at 22:14
  • 1
    Also obligatory: compiling...
    – Spratty
    Commented Feb 9, 2022 at 11:12

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.

  • 2
    I was just going to post something like this: Not all programmers work the same. The best way to manage programmers is to set a clear task, set a clear deadline and set agreed upon fee. Might I suggest a “per hour” model might not be the best tasl/payment model for the original poster to use? It seems like agreed upon task fee might work better? Or perhaps if this developer is really good, it is not a big deal if they take breaks like this? 8 hours for one developer might not be the same as 8 hours for another developer? Commented Feb 8, 2022 at 17:48
  • As someone who did factory work to make ends meet at university - even factory workers need regular and substantial breaks throughout a shift.
    – HorusKol
    Commented Apr 5, 2022 at 19:56

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.


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


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.


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?

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?


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.

  • 2
    @JoeStrazzere - The OP has not mentioned at all that the client isn't getting the X hours they've paid for, just that (someone with a similar username to) the developer is doing leetcode during "working day hours". Totally possible that a remote developer is satisfactorily delivering X hours of work a day. Commented Feb 7, 2022 at 14:07
  • 1
    @JoeStrazzere Chances are you might have Youtube or music playing while working which could in theory rack up 80 hours per week. Does that mean you're on youtube all day or are you working alongside? Perhaps he's on leetcode puzzles in between the task at hand. No way to know from OP's statement for sure.
    – Dan
    Commented Feb 7, 2022 at 14:08
  • 2
    The developer is not "good"
    – Richard
    Commented Feb 7, 2022 at 14:12
  • 11
    @Richard: if the they are "not good", than start fixing this. Set clear goals and metrics and see if that helps.
    – Hilmar
    Commented Feb 7, 2022 at 15:24

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.


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.

  • 8
    Nowhere was it stated that the developer isn't performing the X hours a day they are paid to do. It is quite possible, given that they are working remotely, that they are delivering the X hours, yet still taking personal time "throughout the working day hours". I deliver my 8+ hours a day, and still sometimes go for an hour+ jog in the middle of the the day, or take my kids to the playground - am I stealing from my employer? Commented Feb 7, 2022 at 14:11
  • 18
    No. Just as if I worked in an office I wouldn't inform them that I'd need to take breaks to use the bathroom, or eat my lunch. Commented Feb 7, 2022 at 14:31
  • 15
    The difference between "taking the kid to the playground" and leetcode is that when you take your kid, you are gone. When you do leetcode, you are available. You can answer questions, you can help colleagues, you can be invited to spontaneous meetings and (if you take my example) if all test suddenly turn red, you can quit leetcode and start working again in a heartbeat.
    – nvoigt
    Commented Feb 7, 2022 at 19:46
  • One could ask what's the point of being available when they're not getting their job done anyway.
    – ojs
    Commented Feb 10, 2022 at 15:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .