I apologize if this isn't the correct place to ask this question, but I'm hoping to get some insight from the community on a problem I'm facing.

I recently finished an interview with a company as a web developer. I'm the first and only developer that is about to be hired in this company.

They have a web application that was created by a software company, and they have received the source code of the app.

Years went by, and now they want to refactor their web app, but this time by hiring a full time web developer that takes responsibility of anything regarding the web app.

I just finished the interview and everything went perfect! but here comes the problem ..

They wanted to test my refactoring ability, so they gave me a couple of tasks to refactor. I said that's great, send me a copy of the source code and I'll refactor the web app locally and show you all the updates I can make. but they refused for security reasons, 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.

They instead wanted me to do a live refactor during an online call by accessing the IT admin's screen using a software and accessing the C panel from his computer and modify the code live inside the C panel.

It was pretty difficult, I explained to the IT admin that this is difficult for a variety of reasons:

  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.

  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.

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.

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.

I'm feeling a bit overwhelmed and I'm not sure how to proceed, so I posted this question here to learn from you experts and those who had a similar experience.

  • 6
    Interviews are a two way street. If the interview process is overly uncomfortable then it's possible the job might be as well. How they react to a reasonable push back before you work there might indicate how they will react once you work there. Commented Aug 21, 2023 at 20:09
  • 8
    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. - That may be true, but what would stop you, or anyone else, from stealing the intellectual property that the source code represents and contains? It seems perfectly reasonable to me that they would not want to "share" the source code with you.
    – joeqwerty
    Commented Aug 21, 2023 at 20:30
  • 5
    @joeqwerty: That's what an NDA is for, though I haven't often heard of one in interviews. And/or you assign the interviewee a more reasonable task which involves assets that don't have to be protected. Sounds like these folks were clueless about how to interview, which may suggest they wouldn't be good people to work for. Circular file and do the next interview. (Darned touch keyboard...)
    – keshlam
    Commented Aug 22, 2023 at 0:24
  • 3
    Live Refactoring as an interview task! YIKES! Refactoring is something I wouldn't touch until I had a good idea of both the code base and the goals of the company. Typically, the real goals of the company are not known until quite some time with the company. I would push back with something like "I would love to refactor, but here are the issues that I would need to know far more about before I even attempt such a task." (I had an interview where the bug in question took 6 months of working with the code to find the real cause. Fix in interview? No way.)
    – David R
    Commented Aug 22, 2023 at 14:19
  • 4
    Looks sketchy, like an attempt to get free labour. They're assigning you tasks on their source code before you even became an employee for them.
    – IDDQD
    Commented Aug 23, 2023 at 16:59

6 Answers 6


You're trying to get a professional position. So you use the tools given you and get on with the tasks. The time for using your own choice of tools and resources is when you have the job.

Overwhelmed is not something that you should allow to happen, it's just problems to solve.

Telling them it's perfectly normal to give out source code is fine, pushing back if they refuse isn't. You don't get to set the parameters of your test. Unless you have special skills and leverage you either do it their way or you vote with your feet and go elsewhere.

  • 1
    Part of being professional is getting up and saying "Nope, I need real tools, not play tools".
    – vidarlo
    Commented Sep 6, 2023 at 18:20

What have you learned about this job?

  1. Their web app is a cpanel app. That probably means it's on shared hosting, meaning in turn that they don't have a big operations budget.

  2. They rely on cpanel. They didn't mention git or anything, which probably means you'll have to set that up if you go to work there.

  3. They are willing to have a candidate hack on a live site! You didn't say whether they'd give you access to a dev or staging site, hopefully that's the case. It definitely means they don't have a workable dev environment so you'll have to set that up.

  4. For your interviewer, "refactor" is a buzzword. You can't refactor anything in an hour any more than a builder can repair a house foundation with a SawzAll. Both take knowledge of the structure. But they don't know that.

  5. You'll be a solo developer, the only practitioner of our great trade in that environment. You'll need to find a peer group outside your workplace if you want to keep learning. You'll have to educate people who, at worst, think all this web stuff is magic.

If you want to pursue this job you should do your best to do the evaluation task they want in the way they want. Doing the task their way, even if silly, will give you an insight to what your job will be like, where the organization's power centers lie, and whether they'll be hostile to any attempts from you to create a dev environment.

Things to know before you commit a chunk of your time on earth to these folks.


The following depends on how exactly the assessment task was phrased, but I would recommend a somewhat different approach:

Yes, do point out that for a full-fledged refactoring, a much deeper understanding of the code is required. That you would use an IDE that helps you to efficiently discover references across the code etc.

But the task at hand is, IMHO, well feasible if the following interpretation holds: Show them what's the first things you note in the code fragments you see, that you basically understand the syntax, and how you would approach some of the aspects you recognize.

No, this will by no means match a full refactoring, but it shows (to some extent) you know what you are talking about.

Really, it's not that different to other "live programming" tasks I have been subjected to during interviews. The interviewers do not expect production code there, they want to see you essentially know the craft and how you approach a task/a piece of existing code, and whether you can actually apply the keywords (in this case, from the topic of refactoring) you mention when you describe what you would do.

This is what I see as a realistic expectation for such a task, and it is what I would base my answer on (while, again, pointing out that a real refactoring requires more familiarity with the full codebase).


Notwithstanding the notion of sharing the source code, disclosure agreements, and all that -- this company is requesting that you perform unpaid work on a system that they maintain, which benefits and furthers their own interests, as a requirement for your candidacy. This is unethical, and likely against the law in many venues (I am not an attorney).

It'd be one thing for someone to write some sample code, UNRELATED to "real" code, with a few classes and then ask you to do some refactoring. It's a whole other ball game to continue as they've requested. If you continue, you're implicitly signaling to these people that it's alright for you to be in a work/income situation where integrity is optional.

I've had to push back on such situations, and the hiring manager seemed surprised but subsequently offered a more reasonable approach to get me through the hiring process.


Clearly, asking you to do live refactoring of code that you have never seen before is an unreasonable request. So the purpose of this task is not to test your technical skills. Instead, its purpose is probably to see how you will react to being put in an impossible situation (i.e. it's a Kobayashi Maru test).

What the interviewer is looking for is:

  1. Can you be assertive and explain politely but clearly why the task is impossible, and what could be done to make it more achievable ?
  2. Can you tell when you ideas for improvement are not getting traction ? Do you know when to back off ?
  3. Can you make the best of a bad situation and work with the tools and within the constraints you are given, even thought they are not ideal ?
  4. Can you accept that in some situations, for reasons that you cannot control, you may have to compromise on the quality of your work ?
  • 4
    Maybe this outfit is doing a Kobayashi Maru. And, maybe they're playing 4D chess. But probably not. It's more likely that the interviewer heard the word "refactor" and is using it to try to understand what needs to be done. This is a solo dev job in a company that relies on a web app that's now in an opaque box. They're scared of it. Most of the job is going to be internal communication teaching them not to be scared of it.
    – O. Jones
    Commented Sep 4, 2023 at 12:17

I've been chewing on this question for a bit and finally realized what was wrong.

The access to the admin panel and the computer was actually a diversion, and you unfortunately failed the overall test.

Before refactoring, the first thing is to establish objectives. The system obviously works somewhat, that's why they are asking you to fix it instead of making a new one.

Asking for the source code doesn't establish objectives. That's not even the point. The point is to look at the system a little bit, and then start asking questions, such as:

  • What parts are working? What parts are not?
  • What are the metrics used to determine they need to be fixed?
  • What are the side-effects of fixing this part?
  • How tightly coupled are the components?
  • Can we run multiple systems in parallel?
  • How do we roll back failed refactoring?
  • Are backup systems on standby?

You must log in to answer this question.

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