Thursday, April 13, 2017

Interview Insider: Coding fluency

"Interview is an artificial reality designed by companies to keep people out" - Manager Tools
Many companies won't offer helpful feedback on your interview performance. I think that feedback is a fair game, and the interview process should be transparent.

Coding fluency

Coding fluency is how quickly you translate your solution into code. Though I measure the time (with a stopwatch), coding fluency is not as important to me as other criteria [1]. Lots of good companies, however, have their bar set very high on coding fluency.

I saw weak candidates rapidly producing a lot of code, and very strong candidates who needed help getting going. In the end, a person who quickly wrote the initial implementation may spend a lot of time getting it right, and a candidate who took extra 10 minutes to think it through may come up with an elegant solution.
People are nervous during the interview. Many experience a blank page syndrome, or a writer's block when staring at that whiteboard. Candidates who deal with more than one language or discipline may feel rusty due to the context switching. I just recently experienced a block, panicked and then wrote messy code. I attribute it (or I hope so) to 6 months of doing web front-end development.

Nevertheless, companies like Google and Facebook have bunch of candidates knocking on their doors, and they can afford missing out good candidates in the effort to hire "the very best". You may need to heavily invest in the preparation for several months before you even do a phone screening with those companies.
So, while coding fluency correlates with the overall coding experience, I believe it has more to do with the preparation.
The only way to prepare for the coding interview is to practice solving algorithmic problems. Preferably, on a whiteboard or piece of paper. LeetCode is my most favorite destinations for algorithmic problems; it currently has 557 problems with test cases, and most of them are free.

Also, I think that these two behaviors are particularly important to be perceived as code-fluent:
  • Do not jump into the code until the solution is crystal clear in your head. Remember, the timer starts when you begin writing code. Developers often think with their hands, but it can do you harm during the interview. Especially if you use a whiteboard, where refactoring is very labor intensive.
  • "Trust and focus". Some logic could be tricky or difficult to get right, and it will only slow you down during the interview. Assume you get correct results from a function that you will implement later ("trust"), and get the overall algorithm right first ("focus"). In my experience, your interviewer will often be satisfied with this approach, and move on to a next task.

Also, this article has some helpful tips on this subject (see Get unstuck and Get your thoughts down sections).

External links

  1. Interviewing podcasts on Manager Tools
  2. Coding Interview Tips on Interview Cake


Such as problem solving, communication and computer science fundamentals.

1 comment: