I think we need to agree on a definition of what you mean by an API? Since you mention the PATCH HTTP verb, I’m assuming you’re talking about a web API, and within a web API, it’s perfectly normal to have multiple endpoints. It sounds like you have something like:
The next part you describe (“calculate the earliest date and update it in another column of the same table”) sounds really unusual. I think that the column you’re referring to there is also the “column indicates which employee among a particular department joined first.”? That is really strange in that it sounds highly de-normalized (repetitive), and if anything, if you want to cache that kind of data, it sounds like it would be a table suited for that kind of data (i.e. three columns of employeeId, startDate, and department).
If you don’t need to cache it (i.e. the table isn’t massive), it seems like a query against your current table would be able to handle this easily, something like the query outlined in https://stackoverflow.com/a/8477083/759517.
If the actual question is should the PATCH update the cache, I think that really depends on the business need. I could see cases where the cache is updated on each PATCH, where it might be run regularly (like a cron job), or where there might be another endpoint to trigger generating that data.
For the original topic/question (“Should one API be used for performing multiple tasks?”), I’d say there’s nothing wrong with having multiple endpoints for many tasks within a given API.