Interview Struggles of a Mobile Engineer
Most mobile engineering roles are screened on criterias and in an environment that are not reflective of their core competencies. It is prudent for a mobile engineer to tackle this reality as soon as the search begins. Otherwise a large portion of your leads will be cut short prematurely.
As a mobile engineer currently on a search. A significant majority of technical screens happen on HackerRank, CoderPad or CodeSignal. I made it a point early on to get up to speed on those sites and I owe a great deal to CodeSignal. Here is my review of them, but first some frustrations:
- Heavily skewed to Algorithms. Esoteric algorithms are perhaps 1% of a mobile engineer’s responsibility. The usefulness of this ability is so rare, that using this as a screening mechanism, will just limit the pool of capable mobile engineers. Those that pass the filter are not necessarily better. I can say for certain that I rarely use dynamic programming, backtracking or palindrome detection in any of the apps I worked on for the past 8 years. Algorithms should fill out a candidate's bar in the "T" not as the first indicator of the pillar.
- The Code Editor is not what we use exclusively. XCode and Android Studio are the exclusive editors for iOS and Android development respectively. Using Visual Studio Code, VIM or Notepad is counter productive. XCode and Android Studio are optimized to focus on creating delightful, stable and functional interfaces. The additional friction, risks a higher false negative due to the added stress of compensating the editor while solving an esoteric problem.
- Skips interface building skills. The mobile device is the most interacted with device that a person owns. The screening sites do not accommodate for the demonstration of constructing interfaces and so using a screening site as the first or only stage would leave a very big gap to chance.
- No debugging abilities. The only debug option is logging and it is expensive. The compile run cycles on these sites are very slow and each cycle eats into the allotted time. This become even more critical if a candidate needs to "figure it out" without ever encountering the algorithm before. When the allotted time is exhausted it becomes a subjective call on whether a candidate can finish or not, given the proper tools and time.
CoderPad - https://coderpad.io
- No interview preparation section.
- Timed demo only, candidates can’t practice for long before registration gate.
- Pretty useless after registration. There is nothing to do.
- Very spartan interface. No community or discussion boards
- No objective measure of a solution.
HackerRank - https://www.hackerrank.com
- Solid interview preparation section, very comprehensive list of practice questions. You practice in the same editor as the actual assessment.
- Pretty solid community and discussion board
- Clunky interface littered with parameter parsing code
- Unusually slow test runs and submissions
CodeSignal - https://codesignal.com
- Solid gamified interview preparation section.
- Indicates which FAMG asked the question.
- Solid community and discussion boards
- Fast test runner and submissions. Very broad objective measure of the solution.
- Very clean and elegant coding interface. Practice on the same editor as the assessment
Takeaways
As a mobile engineer, the most efficient path to master a first round tech screen. Is to spend the majority of your time on CodeSignal. Then get familiar with HackerRank and CoderPad.
As a hiring manager I preferred a take home over using a screening site as it gave me a very complete picture of a candidate in an environment and on criterias that are relevant to the role. If it is established early that a candidate knows the difference between UITableView and UICollectionView. Or why two Fragments is better than two Activities, it makes the subjective interview stages easier to evaluate.
Couldn’t agree more. I’d rather work with someone that understands the intricacies of mobile development like retain cycles, using core data, handling multithreaded environments, etc, than someone that can write a balanced binary search tree or some other not commonly used data structure. I think a developer that is balanced in that they know the importance of WHEN to use a data structure / algorithm (and google it) is better than someone that can write one from scratch but not know why it would be used in the real world. In my opinion a lot of companies interview like they are google, but they don’t actually produce anything nearly as complex as google.