Micro Focus is now part of OpenText. Learn more >

You are here

Home/App Dev & Testing/App Dev

You are here

Home/App Dev & Testing/App Dev
Whiteboard challenge

How to pass a coding interview as an automation developer

public://pictures/tj_profile.jpg
T.J. Maher Software Test Engineer, Verily Life Sciences
 

Are you an automation developer looking for a new position? Let's simulate the experience of a coding interview:

  1. Open up a browser and Google the keyword "stopwatch."
  2. Take out a blank piece of paper and a pen.
  3. Press the "Start Button" on the stopwatch web app, then attempt to answer the following question:

"Using your favorite programming language: Write a method that checks to see if a given word is a palindrome. Example palindromes: 'noon' and 'racecar'."

Ready? ... GO!

Yes. Seriously. Attempt to answer the question. I'll wait.

Try this exercise for at least a good 60 seconds, even if you think you can't do it. Don't give up!

... Time's up! How well did you do?

If you had trouble with this question, if your paper is mostly or completely blank, if your forehead is covered in flop sweat, or if your first thought was, "Why are you forcing me to do this? I'm an automation developer, not a coder!" this article is for you.

What is an automation developer?

With "Switching careers in QA: From manual testing to automation development" and "First days as an automation developer? Take my advice on balancing dev, QA," I covered a bit about automation, but let's recap: 

A software quality assurance engineer is an end-user advocate, crafting the software testing process so it ensures quality—meeting and exceeding the wants and needs of the stakeholders on the project.

One of a QA engineer's responsibilities is software testing, validating whether the new features added to a web or mobile application meet the designated requirements and design specifications.

Types of testing performed include:

  • Manual testing: Exploring the product using the same tools the customers will use: a keyboard, a mouse, or fingers on a touch screen. (The fun stuff.) 
  • Regression testing: After adding the new features, painstakingly checking that the entire application is still working as expected from the end user's perspective. Testing a web app? What is the end-user experience in Chrome, Firefox, Internet Explorer 11, IE10, IE9, IE8, Microsoft Edge, and Safari on the Mac? (The not-so-fun-stuff.)
  • Automated testing: Writing code that checks to see if the expected behavior matches the actual behavior of the application. Essentially you want to automate the regression test suite. (And back to the fun stuff!) 

Automating the testing process means that in a continuous integration/continuous delivery (CI/CD) environment, such as with Jenkins,  tests can be run:

  • Just before a release to production
  • As part of an hourly run regression test suite
  • Just before new code has been merged into the main codebase

Automated testing isn't a new concept in the software industry. Giving automated testing tools away for free in order to make the world's software better isn't a new concept. What is new is that Selenium WebDriver—incubated by ThoughtWorks and fostered by Google—has made open-source solutions palatable even to the no-risk companies working solely with certified, off-the-shelf software tools. 

Selenium WebDriver, coupled with CI/CD, created such a tidal wave of demand for coders that the phrase "manual testing" has been pretty much swept away from job requirements. In its place? Automation development. 

An automation developer writes the automated tests and assembles an automated test framework to support execution and analysis of the tests, attempting to answer the following questions:

  • What types of tests do we run? Do we focus on automating our browser regression test suite with Selenium WebDriver? Or do we automate the new functionality too?
  • If we use Selenium WebDriver to automate browser tests, do we pair it with Java, Python, C#, JavaScript, or Ruby? Which Selenium bindings should we use?
  • Can we go one level deeper on Mike Cohn's Testing Pyramid and test the web services that provide the underlying functionality to the browser application, supplementing the developer's unit and component tests?
  • What testing solutions are perfectly paired to the programming language of the app, such as Protractor with AngularJS apps?

Because there is such high demand for automation developers, interviews for QA roles look slightly different than they did two years ago.

What automated development interviews look like today

When I found myself in my first interview after a two-year break, everything seemed to be going well ... right up until I was asked to approach the whiteboard.

"Using your favorite programming language: Write a method that checks to see if a given word is a palindrome."

... Er, what?

I thought I would be reviewing automated test code I had already written, not coding in real time. 

Eh? Nothing about using Firefox, Firebug, and Firepath to find the elements on a page? Or writing code in IntelliJ IDEA or Eclipse to spin up a browser, go to a login page, entering a username and password into a textbox, and clicking on a login button? 

Oh dear. Oh, I was not ready for this. Not even close. 

I might have been able to figure it out had it been a take-home test. But when it was just me, the whiteboard, a dry-erase marker, and two stone-faced software developers observing and judging me, my mind was turning into a complete and utter blank. 

After getting through only half of the assigned problem, I joked with the interviewers:

  • If only I had a laptop in front of me, loaded with IntelliJ! 
  • If only I was coding an automated test, I would be doing a lot better. 

Their response: All employees are expected to meet a certain minimum standard of coding knowledge, even for quality assurance positions.

And that, my friends, is how I started my new job search.

Coding interviews: Not just for software engineers anymore

When I was interviewing two years ago, only once did I come across a coding interview. This time around? Eight out of nine positions I for which I interviewed included it.

The coding interview strikes fear into the heart of even the most senior software developers, and much has been written about how to prepare for them and pass them:

A lot of folks in the industry also think we should do away with them:

Why are automation developers being screened as candidates in the same way as developers? The answer was a strange concept for me to grasp: 

Because automation developers are now software developers.

The automation role has moved over the past few years from testers who can code to coders who can test, leaving manual testers in the lurch. 

The new philosophy is that the code for automated tests should have quality standards that match the standards for production code. If they don't stick to the best practices of object-oriented programming, companies might end up with a testing framework that is hard to read, hard to understand, and hard to maintain. Techniques of encapsulation, inheritance, abstraction, and polymorphism will be harder to teach if automation developers don't have basic fluency in a programming language.

With software developers now a major part of the interview process, they are screening automation developer candidates to make sure they have at least a basic understanding of the fundamentals of the language in which they will be coding.

And whiteboard coding tests are the best solution they can come up with.

Software developers don't consider the questions they are asking automation developers to be difficult. They aren't asking candidates to solve the Tower of Hanoi, John Conway's The Game of Life, or a tic-tac-toe simulation or to shuffle a deck of cards or do any of the other projects they did as computer science majors. And they aren't asking the really hard stuff, such as the math equations from CLRS' Introduction to Algorithms or the Gang of Four's Design Patterns: Elements of Reusable Object-Oriented Software. 

No, most of the coding examples they are asking for are very basic programming questions dealing with loops, some basic math, and some string and character manipulation.

Why are coding interviews so difficult?

1.  Whiteboard question topics may be outside your wheelhouse

  • Although I work daily with the Java programming language, it's rare when I have to use a data structure more intense than a hashmap, and even that is rare. 
  • The code I write revolves around Selenium WebDriver: I open a browser, go to a page, enter data into text boxes, select radio buttons, and pull text from the screen. 
  • I do string comparison all the time, checking if the alert text on the screen is the same as what is expected, but I only use a few of the string object's helper methods in my day-to-day job. 

2.  Whiteboards don't have IntelliSense

  • If I need to use any of the helper methods in the String, Character, or Integer object, all I need to do is type a period after the word, and methods are on display. I can just experiment with them to see what they do.

3.  Whiteboard tests don't allow you to use outside sources

4.  Whiteboard interviews can feel isolating

  • When I am starting to write a test regarding functionality I am not familiar with, I love bouncing ideas off my teammates to make sure I'm not barking up the wrong tree.  But during a job interview, I can't bounce ideas off the interviewers. Or can I?  I mistakenly assumed that I couldn't.

After that first whiteboard test, I came to a hard realization: After relying on all the tools and techniques I mentioned above, I didn't have the basic Java fluency that I thought I did.

It was as if I were interviewing for a job that required fluency in Spanish and made the claim that I knew the language because I studied it in high school and college. If I was asked to write a few grammatically correct paragraphs on a whiteboard about a random topic, such as that morning's breakfast, would I be able to do it without an English-to-Spanish dictionary or a phrasebook? 

Imagine coding as a foreign language:

  • As long as I limited the Java conversation to Selenium WebDriver, I'd be able to hold my own. 
  • Take away IntelliJ and StackOverflow, my own personal English-to-Java dictionary and phrasebook, and if you put me on the spot, I couldn't easily write the "paragraphs" of code my interviewers were looking for.  

The software developers think they are setting the bar quite low. They want automation developers who are fluent in the basic features of a programming language. 

Unfortunately, all of my on-the-job training had not prepared me to answer the questions they were asking. How in the heck would I ever be prepared? 

How to prepare for whiteboard exercises

To prepare for coding interviews, I've built up my fluency in Java using some of the tips below. You can take similar steps for any programming language:

1. Take refresher courses 

Check to see if your local library or your college alma mater offers subscriptions to free online programming classes. Members of the Boston Public Library can get a free subscription to Lynda.com, the online education company. The Thomas Crane Public Library in Quincy, Massachusetts, has free subscriptions, too. I love David Gassner's course on Lynda, Java Essential Training, which covers a good six hours of material. 

2. Follow learning trails

Completely new to the Java language? Has it been a while since college?

Take a look at Oracle's Java Tutorials: "The Java Tutorials are practical guides for programmers who want to use the Java programming language to create applications. They include hundreds of complete, working examples, and dozens of lessons. Groups of related lessons are organized into 'Learning trails'." 

  • Getting Started—"An introduction to Java technology and lessons on installing Java development software and using it to create a simple program."
  • Learning the Java Language—"Lessons describing the essential concepts and features of the Java Programming Language."
  • Essential Java Classes—"Lessons on exceptions, basic input/output, concurrency, regular expressions, and the platform environment."

3. Study the API documentation

To become truly fluent in a foreign language, you must build up your vocabulary. Likewise, to become fluent in a programming language, you need to study the vocabulary listed in the Java API documentation.

If your main programming language is Java, take a look at https://docs.oracle.com/javase/8/docs/api/java, especially methods for the classes Integer, String, and Character. Here are samples:

String  

Need to find the first character in a string? Use charAt(0). If a character or word is in the string? Use contains. Need a suffix? Try endsWith. Check if two strings are the same with equals and equalsIgnoreCase. You can see if a string isEmpty(), or use length() to see how many characters are in the string. You can convert the string toCharArray(), toUpperCase(), toLowerCase(), or even trim() the whitespace in the beginning and the end of the string. Remember that double quotes should wrap a string. 

Character

The boolean methods isLetter, isLetterOrDigit, isLowerCase, isUpperCase, isLowerCase, and isWhitespace help investigate the nature of characters. Example: Character.isLetter('A') would be true. When declaring new characters, wrap them in single quotes, such as char newCharacter = 'a'. 

Integer

Want to convert an integer? Input the integer into Integer.toBinaryString(int i), Integer.toHexString(int i), or Integer.toOctalString(int i) to convert it to the format you are looking for. 

If you were trying out a new vocabulary word, you would try it out in a sentence. When using a new method in one of the Helper objects, try it out in a block of code. 

4. Ditch the IDE: Practice on paper

There is one weird trick to learning a programming language: Practice writing solutions down on paper. 

Read the documentation and lessons. Make up simple homework examples and solve them on paper. For example, you could ask yourself how to use a for loop to print out: 

  • All integers from 1 to 100 (start with something easy)
  • All even numbers ( i % 2 == 0) within that range of 1 to 100 {1 ... 100} (hard if you don't know the mod operator)
  • All odd numbers. ( i %2 != 0) (build on what you just practiced)
  • All numbers divisible by three ( i % 3 == 0) (once more unto the breach, dear friends!)
  • All numbers divisible by three and five ( i % 3 == 0 && i % 5 == 0 ) (and one more time to cement it in your brain!)

Congratulations! You are on your way to programming better than what The Coding Horror observed in the 2007 blog post "Why Can't Programmers ... Program?"

How about some string manipulation? 

  • Write a public method that takes in a string s and returns the length as an integer s.length. 
  • Write a public method that takes in string s and returns the first character s.charAt(0). 
  • Write a public method that takes in string s and returns the last character s.charAt(s.length - 1). 

How did you do? If you solved those problems, you are closer than I was the first time around trying to solve the palindrome problem! 

Remember:

  • Practice making your handwriting legible.
  • Make sure to use matching open and close curly braces and parentheses. 
  • Try to come up with tests for your code. What happens if you feed different strings into your method that find the first character or last character if it is an empty string? Does it work if there is one character in the string? Twenty characters? Fifty? 

Most important, watch out for off-by-one errors:

  • When counting through characters in a string or the first index of an array, if there are n numbers, it goes from 0 to n - 1. This means the very first letter is ( 0 ), and the last one is (length - 1).
  • The for loop (for i = 0; i < 5; i++) will count 0, 1, 2, 3, and 4, but will not go to 5. That "5" is where the loop will terminate. If you were outputting this to the screen, you would see 0, 1, 2, 3, and 4. Make it i <= 5 to print the '5' too. 

Before we walk through a solution to a coding problem, you might wonder...

What is the code interviewer looking for anyway?

Here's what I hadn't realized when I went on that first coding interview. The two stone-faced developers observing me having a brain freeze and getting flustered in front of the whiteboard weren't just silently watching. They were waiting. 

"Using your favorite programming language: Write a method that checks to see if a given word is a palindrome. Example palindromes: 'noon' and 'racecar'."

When they instructed me to write a method to find if a given string is a palindrome, they were waiting for me to:

1.  Define the problem: 

  • Ask: "What do you mean by the word 'palindrome'?"
  • Do candidates immediately jump into the code, possibly not realizing that the specs are unclear, or do they take a step back, examine the problem and gather the requirements? 

"We are looking for a string and its reverse to match exactly, character by character." 

"Your solution should be case sensitive. An uppercase 'R' should not match a lowercase 'r'. "

2.  Start with initial test cases:

  • Ask: "The words 'racecar' and 'noon' are considered palindromes in this exercise. How about, 'A man, a plan, a canal: Panama' or 'Madam, I'm Adam'? How about a blank string? Or a string with one letter?"
  • Do candidates come up with enough edge cases to test their code? How thorough are they? 

"Blank strings and strings consisting of one letter (and one character) are all palindromes. 'Madam, I'm Adam', for the sake of this exercise, is not."

Make sure to ask what is and is not a palindrome! 

Note: If your interviewers come up with different requirements, your test cases and code should reflect them.

3.  Walk the interviewer through an  algorithm before you code

Does the candidate sketch out the problem, talking out loud so the interviewer can get a sense of the candidate's thoughts on solving the problem? 

How do you find if a string is a palindrome?

Take, for example, the string s = "noon".

We can use the helper method in Java's String object, charAt(int i). Enter the index of the string into the method, and it outputs the character at that index:

s.charAt(0) == 'n'
s.charAt(1) == 'o'
s.charAt(2) == 'o'
s.charAt(3) == 'n'

To find the length of the string, we can use the method length().

s.length == 4

To find the last character, we could use:

int len = s.length
s.charAt(len - 1)

We started the count at "0", so the last character would be the length minus 1. 

Let's call the first character the "head" and the last character the "tail." 

  • If the first character s.charAt(head) is not equal to s.charAt(tail) then it is not a palindrome. Return FALSE.
  • If the first character s.charAt(head) is equal to s.charAt(tail) we start evaluating the next set of characters, moving the "head" up by one, and the "tail" down by one. 

Let's go through this evaluation process, looping through characters while the "head" is smaller than the "tail."

Everything fine? In the end, return TRUE.

4.  After reviewing your algorithm with the interviewer, now you can code 

public boolean isPalindrome(String s) {
    int head = 0;
    int tail = s.length() - 1;
    while (head < tail) {
        if (s.charAt(head) != s.charAt(tail)) {
            return false;
        }
        head++;
        tail--;
    }
    return true;
}

5.  Debug and test your code

  • Take your initial test cases and try to imagine what would happen if you ran them. Personally, I like rewriting the tests in a JUnit format—as Assert statements—but this is not required. 
  • Interviewers are checking to see how thorough you are when debugging. (Can candidates spot errors in your their own code without the interviewer giving many hints?)
  • And yes, interviewers will give hints, if the candidate has done well so far. (If we give the candidates hints, will they pick up on them? Can they listen to other people's opinions that may be different from theirs? Can they work with people who may be more senior than them? )

@Test
    Assert.assertTrue("noon");
    Assert.assertTrue("racecar");
    Assert.assertTrue("");
    Assert.assertTrue("i");
    Assert.assertTrue("4004");
    Assert.assertTrue("$noon$");
    Assert.assertFalse("Noon");
    Assert.assertFalse("word");
    Assert.assertFalse("alpha");

6.  Extra points: Gather feedback and revise your code

When I showed my palindrome solution to my friend Joon, who is a senior developer, he grimaced: "Why are you using English words like, 'head' or 'tail'? And a 'while' loop? Isn't a 'for' loop enough? Rewrite the code to do away with that."

public boolean isPalindrome(String s) {
    int len = s.length;
    for (int i = 0; i < len / 2; i++) {
        if ( s.charAt(i) != s.charAt(len - 1 - i)) {
            return false;
        }
    }
    return true;
}

Joon smiled: "See! You just did the same thing as your first example, but there is less code. That is a good solution".

Where to go from here

Gaining basic fluency in a programming language and being able to demonstrate it will not happen overnight, but it can happen. Here's how to proceed:

  • Find basic coding problems on the web.
  • Attempt to solve them with a pen and paper. 
  • If you can't solve them, look at the official documentation of the programming language and see which built-in language methods will help you out. 
  • Come up with your own solution first before seeking out a better solution elsewhere. If you do your own research and investigation, chances are the information will stick in your mind permanently. 
  • Don't do cram sessions. That merely storse the information in your short-term memory.
  • Practice a little bit at a time—maybe 15 minutes a day. You want this information to move to long-term memory, so you can recall information even during extreme interview stress. 
  • Don't go through all this effort just to pass a whiteboard test. Aim higher! Make your goal to be a better programmer. 

Getting practice

Finally there are many sites out there where you can practice taking coding tests, including these two:

Feel free to share your favorite coding question sites —and the crazy interview questions you've fielded— in the comments below. 

Good luck, and happy coding.

Keep learning

Read more articles about: App Dev & Testing, App Dev
Twitter Twitter Facebook Watsapp Email share