Interviews: Beyond the expected answer

A long time ago, a colleague recounted how his latest interview with a candidate went. Something about the candidate’s work experience seemed off, so my colleague decided to test him with a seemingly simple question.

"Ok, so if I want my script to run every x minutes, how would you go about it?" he asked.

Under pressure, the candidate started writing a script. My colleague was intrigued but let him continue. The candidate created a while loop that checked the current time at each iteration. If the minute was divisible by the given interval, the script would run. Otherwise, it would loop back.

He ran the PHP script, and they both stared at the console while it idled.

"That's one way to use up all the CPU resources," my colleague pointed out, amused.

Perplexed, the candidate pressed Ctrl+C to stop the program. He reexamined his code and decided to add a sleep() command at the end of the loop, setting it to 60 seconds. Now, every minute, it would print a string on the console.

But there was another issue. The script didn’t run precisely at the start of the minute—it was offset by 45 seconds.

Ctrl+C again. The candidate scrambled to adjust his program, reading back his code to figure out how to improve it. Time was running out.

Finally, the interviewer intervened: "You know what, it's fine. Let's move on to the next question. Just use a cron job next time."

The candidate froze. "What’s a cron job?"

That was the end of it. The candidate wasn’t hired.

At the time, we all laughed about it. Not knowing about cron jobs seemed like a major oversight for someone in his role. But looking back, I wonder—wasn’t his approach kind of ingenious? Sure, it wasn’t the most efficient or polished solution, but the logic was there. He was, in essence, re-implementing a key concept behind how cron jobs work.

What is a cron job? A cron job is a task scheduler that automates the execution of scripts or commands at predefined intervals on Unix-like systems. Developers define the schedule using a simple syntax in a file called the crontab. The cron daemon then checks the system clock every minute to see if any tasks match the current time and executes them if they do.

Cron jobs are highly flexible, allowing you to schedule tasks as frequently as every minute or as specifically as "on the first Monday of every month at 3:00 PM." In some advanced implementations, cron uses a sleep-and-wakeup mechanism for efficiency, but the basic principle is the same: automate repetitive tasks without manual intervention.

The candidate’s while loop, though crude, wasn’t far from this idea. He was simulating the behavior of a scheduler: checking the current time and executing a task when conditions were met. While his method would have wasted CPU resources and lacked the precision of a cron job, the underlying problem-solving approach was valid.

Reflecting on this story, I’m reminded of another interview I had with a UCLA graduate. This interviewer seemed more interested in demonstrating his cleverness than actually evaluating my skills.

He asked, “How would you estimate the number of windows in this building?”

I answered, “I’d count the windows on one floor, then multiply by the number of floors.”

He pressed on, “What if you didn’t know the number of floors or the number of windows per floor?”

I said, “Then I’d mark it as a variable and wait until I had that data to calculate the final number.”

He smiled smugly. “Yeah, that’s one solution. But wouldn’t it be better to call the company that installed the windows?”

“Oh, that’s clever,” I said, humoring him. I got the job.

Looking back, it’s clear that some interviewers are more interested in how clever the answers sound than how practical or grounded they are.

The first candidate showed genuine problem-solving skills. He may not have known about cron jobs, but that’s a single Google search away. What he did demonstrate was an ability to adapt and create a solution on the fly. In many ways, that’s more valuable than simply regurgitating the "correct" answer.

Not every great developer knows everything. What sets them apart is their ability to solve problems creatively, learn quickly, and adapt when necessary. Unfortunately, interviews often focus on getting the "expected" answer rather than evaluating the candidate’s potential to grow.

So yes, we didn’t hire him. But I’m sure he went on to find something better, somewhere his resourcefulness was appreciated. The real issue isn’t a candidate’s lack of specific knowledge. It’s our failure to see potential beyond the expected answers.

---