As an automation engineer, I've had my fair share of stupid programming interview questions. I'm sure you have, too. "Find all the prime numbers from 1 to 1,000." Really? Is that important for this job? "Create a linked list and make sure to keep track of the head." What? You know there's a data structure built into the language for that, right?
These questions feel ridiculous. The problem is, as an employer, I don't know a better way to assess abilities quickly and quantifiably.
When I was an employee looking for software jobs, I felt what it was like to program a stupid question on a whiteboard. Talk about stressful. To top off the nerves and adrenaline, interviewers try to make you feel at ease by saying things such as, "We just want to see how you think." I don't know about you, but interviewers getting analytical about how I think while I work through a difficult puzzle is not going to set me at ease.
But as uncomfortable as these experiences were, I would never change them. I learned valuable lessons from them, and I'm a better automation engineer today because of them. Here are a few stupid questions I've been asked and what I learned from them.
'Find the first non-repeating character in a string'
Before I interviewed for one well-known company, I was asked to brush up on Big-O notation, which is a way of characterizing the expected performance of an algorithm. While the exercise of finding the first non-repeating character in a string may seem straightforward, the preparation I did before the interview upgraded my wetware.
What I learned was that we need platforms for communicating about things. If a language or notation exists, use it. But if you don't know how to communicate in terms of performance of algorithms, conversations become difficult.
Another great lesson for me here was that data structures can help with performance. Control structures (loops and conditionals) are not the only tools for solving these types of problems.
Many of my clients come to me because they want to do something about their long-running test automation. I've seen suites of 500 tests that took 16 hours to run shrunk by a factor of two, just by tweaking one algorithm.
As an employer, I don't care if people know Big-O notation. But I care that they're able to talk through and solve problems together. I care that the more my consultants are able to do, the more we have to offer our clients. And if our clients want to talk about things such as Big-O notation, we can hold the conversation.
The logic puzzle about three light switches
You have a room at the end of the hall with three light bulbs in it. The door is closed so that you cannot see into the room. You have in front of you three switches. You must identify which switch activates which light bulb. You can enter the room only once.
This one is a logic puzzle. Programming is based on logic. You can't get around that. If you're not logical, programming is going to be difficult for you. And if you're going to be a good automation engineer, you'll need to be good at programming.
As an employer who wants to hire good programmers, it helps me to know if a candidate can work through a puzzle that requires logic.
As an employee looking for a job, logic puzzles used to annoy me. I never did solve this one earlier in my career. I didn't understand what this question was getting at or why I needed to answer logic questions for a company. Today, 20 years later, I do.
As an employee, I failed at many of these. So I practiced solving riddles. As a result, I learned different ways of approaching problems. Just as important, I learned the types of mistakes people make with riddles. Hearing a riddle and knowing what part of it to not knock your head against can be almost as valuable as knowing where to look for the answer.
It's important to learn to approach problems from different angles. Learning to think in different ways has helped me identify with how others may be thinking. It's helped me help others and communicate better myself.
I also learned some methods to get myself unstuck and strengthened my never-give-up attitude.
So many folks complain about these puzzles. I wonder how many are not willing to put in the time to learn how to do them? Stupid programming puzzles are a part of the job. Why not learn to hack them? Practice is key.
FizzBuzz, another puzzle
Case in point: A few years ago, a developer at a client site mentioned this puzzle to me. They were using it to filter applicants. I couldn't believe they were using such a simple puzzle to weed out real-life programmers for real-life jobs.
This is the puzzle: From 1 to 100, print out every integer in order, except that when a number is divisible by 3, print out "Fizz." When it is divisible by 5, print "Buzz." And when the number is divisible by both 3 and 5, print "FizzBuzz."
What did I learn from this? I learned to trust myself. One of the tenets of these puzzles is, "If it seems simple, it's probably not." That was my only hesitation in answering right away—that I couldn't possibly know the answer so quickly. But I also knew that this was the kind of question that had a catch, and I saw the catch immediately.
I also learned from this puzzle that some problems aren't solved front to back. Sometimes order matters.
Building confidence
It can be a huge hit to the ego to sit in front of someone who asks you to remove specified characters from a string and you realize that not only can you not think of the best performance for this, but you can't even solve the problem.
I remember trying to do an algorithm like this on a whiteboard and realizing that I couldn't solve it. I thought things such as, "I'm not good enough," "I don't have what it takes," and "I'm not smart enough."
I realized eventually that confidence comes when a person moves forward regardless of the outcome's certainty. Confidence isn't something you get from not failing. Confidence is something you decide to have—whether you fail or not.
I have failed at a lot of things. But I'm more confident today because, having failed, I learned from the failures.
An employer's perspective
When I began hiring people at Beaufort Fairmont, the risk was overwhelming. As employees, we're shielded from this. Companies are just non-humans with giant bank accounts and overlordship, right? Actually, they're not. Most are made up of well-meaning, normal people with very similar desires to yours.
As an employer, I have duties to many people. I have a duty to the people I hire to put them in a position where they can be successful. I have duties to existing employees to not screw things up by hiring a knucklehead. I have a duty to my clients to deliver on what I promised them.
As an employer, I have to know that the people I hire can program and that they can think through and solve problems. There aren't a lot of good ways to do that. But these stupid questions are some of the best we have.
Sure, you may never need to create a linked list or reverse the words in a string for your job. But these questions helped me become better. And I believe that, for most people, if they work hard enough so that they are able to solve these problems, they will get better at automation.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
