The Overly Technical Interview

Recently I started the interview process with a tech company that worked on some pretty cool software. That was their business, they recently went public, and were growing quickly. I applied as a Technical Lead (forget the actual title) and my background was a fit to get past the screening interview.

The Test

First step past the screening interview was a timed test at HackerRank. 75 minutes to answer 15 multiple choice and 3 programming problems. The multiple choice were a range of topics:

• What CSS style would be applied to this element?
• What is the correct SQL query for generating this table output?
• What would this code output on the console?
• Where is the programming mistake in this (pseudo) code?
• Which algorithm is more efficient?

A great range of questions and topics. The only bad thing about multiple choice is second guessing yourself, like knowing the answer in 5 seconds and then talking yourself out of it for two minutes : )

The programming problems were pretty cool, and the testing tool allowed you to write and run in a large variety of languages. It even unit tested for you! My first question I got to a valid place to test and passed 2 of 5 unit tests, but didn't get to see the inputs or expected outputs of the tests. So I rewrote it a different way, and this time got 3 of 5 of the unit tests. And by this point time was running out, so I moved on.

In the end I ran out of time before completing every question. I did not see immediate feedback on my test (from the tool or company's recruiter) and was not sure how this would be scored. Was I intended to finish? Was this some kind of stress test? Do they only take those who can finish?

The One-On-One

I guess my score was enough to move on and I had a one-on-one with another engineer. We talked about past projects of mine, and then did a coding exercise together, live on codeshare.io. The problem was to write Fibonacci in any language I wanted. I just started coding, though it did not feel natural because I haven't used the Fibonacci sequence since I learned about recursion in CS 101. I took a break from coding to explain where my head was at and explained a looping algorithm that would solve the problem by keeping track of an index and two variables. My interviewer showed a recursive sequence and asked it's pros and cons (algorithm complexity, stack size, etc) from the version I described. I asked about his views on the company and we were out of time.

The End

The next day I got the "thanks but no thanks" response from my recruiter, which of course bubbles up the feelings of not getting picked. Everyone was nice and professional, and we're off our separate ways, wishing each other the best.

Takeaways

This interview did not lead to an offer, which is the most telling thing that can come from an interview process. In my view, something did not go right because I thought an offer was possible. It is why I applied!

Two takeaways from this experience. One for me, one for them.

Takeaway One: Study

For those tech companies that are asking the algorithm questions, and I've heard about it from a lot of the big names, one needs to study. No matter if you think the questions are "too basic" or "just facts you can look up on-line", this is the screening process. If you want to stand a chance with these types of companies, study! Know the tricks. Eat Fibonacci for breakfast, B-Trees for lunch and some Big O notation for dinner. Practice at HackerRank or some other coding problem site.

Also, I would have used algorithm design comments more than actual code, especially when I was going to run out of time in the test, or during the coding interview where code would not run. Partial credit in those situations would hopefully have shown I knew what needed to be done ("solved the problem") and just needed time to code it correctly.

In the end, this is the company's interview process and if I want to compete in that space, I need to hit the books!

Takeaway Two: Interview for the Position

I mentioned this was for a Technical Lead position, yet feel that every multiple choice question and especially my one-on-one problem solving interview, could have been solved by looking up StackOverflow or Wikipedia. Not a single question about managing a project timeline, following a software process, thoughts on testing, system design, choosing a framework or component architecture. Maybe there would have been more of that past this "screening technical interview", but if I were a team lead, one would think those items would be important.

Same goes for the timed test and code-sharing, to a degree. Was that an accurate measure of my technical knowledge? No time for design, because the test clock was running and we had 9 minutes left on our interview when we hit codeshare.io. HackerRank is a cool tool, but is coding without (more than one) test inputs or expected outputs very common? Speed coding might be fitting at a hack-a-thon, but "just start typing" is not a typical way to get the best results at the office. The concern is while these tests/reviews might be good for screening, is it relevant to your actual work?

Other interviews I have participated in required a homework assignment with a relevant problem to what the position was for. Time was not stressed. Code was not forced/constrained by a tool. We could discuss the work result, and how I got there. To me, though it is more time invested, feels more relevant to the job at hand. Perhaps that is seen more with smaller companies, but the big ones that are hiring 2-20 people a month, let alone screening 5x-10x that, just don't have the bandwidth for more. Though I wonder if turnover has any correlation to the interview process chosen.

Interviewing is its own set of skills, and I'd better stay sharp : )