Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I have been mentioning in interviews that I had to fire an employee. It was very hard for me to fire the person and I really do not wish to have to repeat that experience so I try to warn the candidates.

Backstory:

Our company is fully remote. One of the clause on the contract of each employee is no moonlighting. They are not allowed to work on anything else professionally. They can work on personal software project if they notify me in advance. This is because in a fully remote companies there are not office hours and it's very hard to define what's work and what's not.

Employee Alice worked for us 3 months. She was not very responsive but her work was a 7/10. One day I found Alice was actually part of an agency and she was actually a Project Manager delegating all her work to other people. I noticed this because she had a MacBook but screenshots of her work were on Windows. When confronted she straight out denied the whole thing. After finding many more evidence she finally admitted she had delegated work to some "friend". I fired her with her pleading it was all a big misurderstanding. It was terrible, I felt so bad because even though I had found a lot of physical proof of her deception she was still playing the card of "please no really it's a misunderstanding". I doubted myself a lot fearing I had indeed fired an innocent person just being paranoid.

Now when I hire new employees I underline the NO MOONLIGHT policy and tell them I had to fire an employee in the past. It was ugly and I wish to not have to redo that.

I'm a single founder software engineer growing a team and having to deal with management for the first time. I'm unsure of most of my decisions. If you have some advice that you can give me in a kind fashion without making me feel even more inadequate that I already do it might help me become a better manager.



Since you've explicitly asked for advice, the only way to assess remote employees is by what they're delivering. If you employ them for 40 hours a week, but they can deliver what you're asking in 5 and still be responsive when needed, is there really a problem?

If they're also doing another job on the side, but it isn't impacting their delivery of the work you're asking for, that shouldn't be a problem. By doing away with a (largely unenforceable) policy of no moonlighting you also avoid the problem of having to fire people for breaching it.

I'm borderline on whether Alice here was even at fault. She is likely in breach of her contract for several other things, I assume there's a routine NDA in place which probably means that she shouldn't be sharing confidential company information with outside parties, but if not and she was getting work delivered is it really a problem if she did so by being good at project management rather than software development?


>assess remote employees is by what they're delivering

I agree but that is easier said than done. Software is very intangible and creative and I do not have experience in managing other developers.

One of my employees is a university dropout with 3 years working experience from a developing country and is the only developer other than me. I have no clue what's the amount of code he's suppose to deliver. I have very little metrics of reference to work with.


It's a really unethical thing to do, and you don't want unethical people working at your company.


If you want that much control over your employees you're going to get employees that allow you to take that much control over them. It's the new "pay peanuts, get monkeys"

No moonlighting, screenshots, this quote "This is because in a fully remote companies there are not office hours and it's very hard to define what's work and what's not"

Someone good enough to do exactly what you need is not the sort of person that only does exactly what you need. You're only interviewing people that didn't rule you out


I wouldn't tell them the story about having fired someone. You can simply state your no moonlight policy and be done with it. There is a credibility problem. They're hearing the story from the person that was involved and only that person that they don't know, and who has a high motivation to be dishonest in how they present it in that situation.

Imagine the person sitting there. This person who I don't even work for yet is starting off with telling me about how they fired someone. Are they telling the truth? Do they really feel bad about it? Maybe it's his way of letting me know that this is the way things are around here and he knows he can't come right out and say, "I love to fire people" so he's just trying to soften it. Why's it still on his mind? Does he have a hard time letting things go and holds grudges?

How would you feel if you took someone out to dinner and on your first date started telling you some story about how bad they felt about dumping their last romantic partner? Sure maybe it was the right thing to do. You're not going to feel better about them. The best you can hope for is you don't feel worse about them. It's all down side where the best you can hope for is a neutral. If you're playing a game where the best you can do is lose or draw it's better to just not play the game. Don't talk about firing people.


> Our company is fully remote. One of the clause on the contract of each employee is no moonlighting. They are not allowed to work on anything else professionally. They can work on personal software project if they notify me in advance. This is because in a fully remote companies there are not office hours and it's very hard to define what's work and what's not.

> I'm a single founder software engineer growing a team and having to deal with management for the first time. I'm unsure of most of my decisions. If you have some advice that you can give me in a kind fashion without making me feel even more inadequate that I already do it might help me become a better manager.

My feedback: drop the terrible policy. It's not legal in California for a reason.


But doesn't Google and many other tech companies in the silicon valley own all the code you write as a developer while employed? That's kind of a no-moonlighting policy.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: