For the purpose of actually refactoring the code, this is not a good setup. Legalities/ethics of having done so without pay aside, I still would not even consider committing any of your changes, as you clearly were not well-informed at the time of making them.
However, as an interview exercise where people are judging your abilities, a live exercise is not unreasonable by itself.
2- Refactoring inside the C panel is difficult, I need a code editor like Visual Studio Code to easily navigate through the project and better understand what is going on.
Anything I say here is influenced by just how prohibitively unreadable the source code was; but I would argue that it was a bad call to argue that you need an IDE. Sure, it makes things easier, but the goal is not for you to fully peruse the codebase or make perfect improvements, it's to display your abilities as a developer.
1- I'm completely new to the code base, I need sometime to understand what's going on with the code and study it good.
You've lost track of what the goal of the exercise is. The goal is not to make an improvement that is ripe for merging into the codebase. The goal is to showcase that you have the necessary skills to make these kinds of improvements once you're employed.
What an interviewer would be looking for would be more related to what you're thinking and how you're trying to approach it, rather than what you write or what file you open.
As an interviewer, I would read between the lines here and infer that you're likely to lose track of goals by fixating on other things. This is just an educated guess, not a proven fact about you, but this is how interview exercises work.
In a company where you'd be a one man department and there'd be no one with the technical expertise to rectify your mistakes or scope creep; this is a point of concern, and it makes you a less favorable applicant (if there were others).
I explained to him that it's perfectly normal to share a "COPY" of the source code for a potential hire, as any modifications will only reflect in my local machine, and not the hosted app, they are two separate instances.
You've missed the mark here.
Their concern isn't that you can somehow alter their live website, it that they would be giving you an entire solution that is their property, and nothing is preventing you from taking this code and doing something else with it, maybe even selling it to a competitor.
If you are aware of the concept of digital piracy, then "perfectly normal to share a "COPY" of [digital asset]" should not have come across as a harmless statement to you.
If anything, your response here would negatively impact my assessment of you as a technical applicant, especially in a company where you will be a one man department and there's likely not going to be a second line of defense for technical mistakes.
To be perfectly frank, I have rejected dozens of applicants who met all of the vacancy's criteria but during the interview would show their current employer's source code when showcasing their knowledge/skills/experience, even if they only shared their screen and showed a handful of files. You simply do not share private code, and this is a significant no-no from anyone with a sense of security.
Providing a digital copy of the entire codebase is several orders of magnitude worse than that. Asking for it, and then persisting after having been told no already, is a very concerning behavior on your end.
they seem to be afraid that I might steal, hijack, or attack the web app in any shape or form by having a copy of the source code.
I want to reiterate on this point, because you state here that they explicitly claimed that it had to do with their live website, and my above feedback assumes that you misinterpreted this.
Even if that's what they believe and even if that was the only concern they had, and they had no concerns regarding the spreading of their proprietary product source code; then it was still the wrong call to argue with them and insist after already having been told no.
It's okay to try and redirect things, but it needs to be a cooperative effort. If it's a yes/no back and forth, that's an unproductive attitude and it does not reflect well on you as an applicant.
Even if you were correct (which in my opinion you weren't) and they were wrong, it still means that you and this company are not going to find a common productive ground.
I'm still not convinced that this was their (only) concern though.
But unfortunately, he refused, saying that he can't share the source code to a stranger, as I haven't signed a job agreement yet.
It's not unheard of to sign an NDA at this stage for the company to feel more secure in revealing its code.
To be fair, from the POV of the company I understand not wanting to reveal their source code as a point of principle. Even though I also acknowledge that the odds of them being impacted negatively are exceedingly small, that doesn't matter; an unnecessary risk should not be taken just because you think the odds of it going wrong are low.
However, the subsequent advice is that an interview exercise should then be held using an example that is hand-crafted by the interviewers (or their peers) in order to judge particular skills that they're looking for in an applicant.
Based on this company not having any developers, this is obviously not possible, and I'm genuinely happy to see that they did not just copy/paste some regurgitated "developer interview questions" because these are not great indicators of developer skill.
This is where I would advise the company, if they were the ones posting the question here, to reach out to a recruitment agency. This is precisely their core focus: providing skilled interview ability (often relating to the nuts and bolts of the vacant position) when the company lacks either the manpower or knowledge to properly assess its applicants.
Alternatively, they could hire a freelancer to design an interview exercise and give them the basic rundown on what improvements to expect - but I would only expect this shortcut to work for a junior vacancy where the goals are simple and easily confirmed by laymen. I wouldn't trust this process when assessing applicants for a senior role.
