Forums
The interview was going well—as well as one could possibly expect. Alarik, the candidate, had a no-nonsense attitude, a high degree of precision to his speech, and a heavy German accent. He was applying for a job with Erik's company as a C# developer working on an inherited legacy codebase, and he'd almost earned himself the job. There was just one routine question left in the interview:
"So, why did you leave your previous job?"
"Ach," he said, his face twisting with disgust. "It was my superiors. They did not wish to improve the codebase."
This was the first red flag. Erik's company had a terrible codebase, littered with technical debt. He was all for improving it, but it had to be done carefully to avoid breaking their bread-and-butter application while they struggled to keep the company solvent. He'd been leading careful efforts to tackle the worst bits while still delivering new functionality. "Can you tell me more about this?" he asked, frowning just a touch.
"I was all set to develop unit tests for every unit," Alarik replied. "It would have saved effort in the long run, but the bosses did not see return on investment. It is always about money with them, never craftsmanship."
Erik chuckled weakly. "Well, we're a small company, run by developers and former developers. We don't have MBAs here running the show, so we definitely appreciate craftsmanship. But I'll warn you off the bat, the product you'd be working on has no unit tests. We're working towards that, but we're not there yet."
Another disgusted noise. "Tch. If you hire me, I will need time to improve this. Perhaps not the entire codebase, but at least the core functionality."
"I appreciate your candor." And Erik did—it meant this leading candidate was pushed back to second place. After all, he might be a great developer, but dictating demands in the interview wasn't exactly a strong recommendation.
They proceeded with the interview process, but their first choice fell through, so they ended up inviting Alarik back for a second interview. After all, not everyone who appreciates craftsmanship and prefers unit tests is necessarily inflexible.
"Do you have code samples we could look at?" Erik asked, hoping to convince himself the value of a good developer was worth some butting heads about priorities.
"Yes, yes, of course. Here, let me show you. I have brought you a unit test I wrote."
"Great," said Erik, feigning some degree of enthusiasm. This again ...
"This is a unit test for the Absolute Value function in the Math library," Alarik continued, pulling up the code with a few deft keystrokes.
Please tell me it's just a sample, Erik thought. Does he think I don't know what a unit test is? Or does he really not trust the built-in absolute value function? What kind of person has a unit test for Math.Abs() pre-written on their computer? Will he tell me some war story about some platform where Math.Abs() failed to work on some edge case?!
Erik mustered an insincere smile, sitting through Alarik's walkthrough. It was a well-written test, for certain, but he just couldn't shake the questions about why it was being shown in the first place. "This is a little simple. Do you have an example of a test you wrote for some actual business functionality?".
"Ah, yes. Here is my test for `String.split`."
Changing the subject, Erik asked about another sticking point: "You mentioned in our first interview that you wanted to break up class files that are too large."
"Yes. No file should be over 400 lines."
Erik thought back to one code file in their codebase that was over 11,000 lines, wincing a little. We're overdue to break this up, but I'd hate for this guy to come in and rearrange every one of our hundreds of files. "How strictly would you apply that rule to a legacy codebase?" he asked.
"It is good to be flexible," Alarik replied. "It's not a strict rule."
Feeling relieved, Erik drilled further: "What if you found a class file that's a thousand lines long?"
"That I would break up, of course."
"How about 500?"
"I would break it up."
"What if there's no natural way to break it up?"
"There is always a natural way to break up complexity."
"Well, how do you find that? Let's say you found a 11,000 line file. What steps would you take to break it up?"
"I would move blocks of code into other files."
That did it. Erik thanked Alarik for his time, deciding to wait 24 hours and then give him the bad news. In rejecting him, Erik still felt guilty—he felt like the team was sloppy for not using unit tests and having a huge range of source code file sizes.
No doubt we'll falter and fail, he thought sarcastically. It would serve us right for not employing the only person who could have taught us proper software development processes.
And yet, three years on, in submitting this story, Erik wanted us to know that the company was doing better than ever, still with 0 unit tests in a codebase that's loaded with WTFs, and still feeling guilty enough about this interview to write in.