Please describe how you would refactor a class for easier testing.
During the interview for a senior software engineer's job, you'll be asked many technical questions. These are meant to provide the interviewer with information about your skills and experience and help them determine if you're qualified for this role. The technical questions will span several different topics and, in some cases, may ask you to demonstrate your programming skills. As the interview progresses, the questions will become more specific and challenging.
"When refactoring a class into smaller ones, I examine the class and see if I can be constructed into different responsibilities and grouping of methods. Refactoring opens the class up to implementing new features. I would also look for opportunities to refactor the class for parallel or concurrent processing, thereby increasing its performance and reducing the time to accomplish a task. This would require the utilization of threads, sub-processes, and background jobs, using commands such as cron and Resque. Here is how I would proceed with this (insert the methodology to the class the interviewer presents you with)."
You should review the processes and procedures you currently use to develop software and research those typically used within the industry. This will help you to be familiar with these and ready to respond or demonstrate your programming skills during the interview. Even though you may have a great deal of experience to be confident in the methodology you use, reviewing them before the interview will keep them fresh in your mind. Practicing questions like this will also prepare you to respond to the interviewer's questions easily.
Community answers are written by other candidates practicing this set. Reading how others frame the same question is one of the fastest ways to sharpen your own.
Anonymous Answer
There are a few key principles to keep in mind while refactoring a class for unit-testing. One of those key principles is to make sure that no single function is doing too much. If you have a single function that is thousands of lines of code, then that function is doing too much and unit tests for that function are going to quickly become ugly and unmanageable. I would evaluate the function, see what responsibilities it is currently assuming, and see how those can be broken out into smaller and more manageable functions with their own set of expectations that easily translate to simpler unit tests. That same approach can also be applied to the class itself and it may be that the class needs to be split into multiple classes.
Another key principle when refactoring is making sure the refactor is more readable than the current code is. If you're going to abstract the class by splitting it out into multiple classes, it's important to balance the amount of abstraction you plan on doing and not overcomplicate or oversimplify something. You can easily abstract any single class and break it out into a series of classes and interfaces that extend other classes and interfaces which in turn extend more classes and more interfaces and you eventually end up with a web of dependencies that is more confusing than it is helpful.
Amanda's Feedback
Good job! You've explained that you'd make sure no function was overworking by evaluating functions and breaking them down if needed. You'd also ensure the refactor is more readable than the current code while making sure to balance the amount of abstraction. If you've recently worked on a project that required you to refactor a class to optimize testing, share what the project was, your role, any obstacles you came up against, how you overcame them, and what the positive outcome was. Anytime you can provide an example that illustrates that you've actually done the kind of work discussed, your answer will be stronger and more memorable.
