The interview process began with a phone call that lasted an hour. This was followed a few days later by an all-day onsite interview.

The onsite portion consisted of a series of one-on-one discussions with six or seven different individuals. Lunch with the hiring lead took place in the middle of the day. I don't believe I ever spoke with more than one person at a time.

The team was composed of SDETs with a wide range of experience. Everyone was clearly talented and seemed to be doers.

They were looking for someone to put together an automation framework to run on test units operating Android. The role specifically involved integrating smaller pieces that had already been completed.

I really liked the team I spoke with and was impressed with their goals and operations.

I don't remember exactly, but the question was about my understanding of processor cache architecture versus RAM, for example, memory locality and its associated performance.

Best I recall, the gist of it was to code up a function in C/C++ on the whiteboard to determine if a string contained any numeric digits.

Explain the nuances of methods in Java versus C++ and key differences. The desired answer was that C++ requires the virtual keyword, but Java is different.

I was asked about my experience and knowledge of implementing and driving testing with Selenium, as well as ways to perform unit testing with Android and Java.

In Perl, how to match strings from two data sources—one a large text file and the other a smaller text file—and code a complete example on the whiteboard (some pseudocode is acceptable), including reading both files. The output would be a report summarizing a subset of the large file. The key thing was that the string to be matched was coming from a variable. So, it needed to handle something in this way:

perl

$searchme from the big file, $matchme from the small file

if($searchme =~ m/$matchme/) {

emit the valid output as specified

}