The Interview That Changed My Perspective   Picture this: I'm sitting in a technical... Tagged with webdev, go, programming, ai.

Dev.to is a community platform for developers, offering resources, discussions, and networking opportunities to empower individuals in their coding journey. Developers can learn new programming languages, frameworks, and tools, engage in discussions on best practices, and share their experiences with fellow developers to enhance their skills and grow their professional network.

A developer built a delayed commit feature for GoCommit after an interviewer questioned their GitHub commit timestamps during work hours. The tool allows developers to schedule commits outside restricted hours, addressing privacy concerns and work-life boundaries. It intercepts commits during configured work hours, presents alternative timestamps, and uses Git's native date flags to set both author and committer dates. The feature integrates with GoCommit's AI-powered commit message generator and raises questions about whether coding schedules should be public information.

Why Do You Push Code During Work Hours?" - How an Interview Question Led Me to Build a Delayed Commit Feature

The Interview That Changed My Perspective

“I notice you push code mostly during work hours.”
As opposed to what?! This IS my job.

I really respect the motivation behind this — privacy and work-life balance matter. But from experience running large production systems, I’d be cautious about tools that rewrite commit timestamps.
On a real project with thousands of daily users, every commit is part of a long chain: developer → tester → staging → production → logs → incident review. If a crash happens, those timestamps help us trace exactly when and how the code changed. Once we start bending that timeline, even for innocent reasons, we lose part of that clarity — and clarity is what keeps systems stable.
I completely agree that judging developers by their GitHub commit times is wrong. But the fix isn’t to disguise when we work — it’s to change the culture that confuses timestamps with dedication.
In healthy teams, honesty in the history is a sign of trust, not control. Tools should protect that, not hide it.

Being the person I am, I would have said something like “I push code whenever I feel that it’s necessary.” 99% of my code pushes will be within working hours and you will always find that I put at the end of my shift.&quot; That doesn’t mean, I won’t fix something and push code beyond working hours but those are reserved for break/fixes.
I feel that their must be a work/life balance to help me stay sharp.
The nights are for morale and whisky.

The interviewer is how old? 60? 70? 80?!
The concept of generic “work hours” for IT professionals is sooo last century.
This is a huge red flag, in case the interviewer actually was intentionally using this as a negative point, rather than just having a conversation.

I promise you, if you bring up my commit times as a gotcha, I will walk out of the interview. That’s corporate goblin bullshit.