Ask HN: How should I hire mobile developers?

5 points by shikharja 5 years ago | 4 comments

Curious about how you (especially hiring managers and interviewers) hire mobile developers? What are the interview rounds? Do you ask your candidates to build an app or ask simple coding questions? What topics are the most important to assess? Any tool or product you use like HackerRank/Codility/Codepad?

gcheong 5 years ago |

As a candidate I can say I've faced the gamut of everything from online automated assessments to phone interviews that seemed little more than running through a list of "how do you do X" to high pressure white-boarding sessions involving solving algorithmic/architecture problems on the fly but the kind of assessment that seemed most reasonable to me above everything else was one where I had a small take-home coding challenge with a discussion of the submitted solution afterward, the latter part being key and here is why:

1. You can see how well I explain my solution, how I approached it, and my reasoning for any trade-offs or choices I made and how well I respond to any questioning or criticisms of my solutions.

2. It shows respect for my time, because there is always more that goes into doing these things than just the code that comes out of it, and gives me an idea what it would be like working for your company and/or the people I would be working with.

muzani 5 years ago |

I've done a few as a candidate and interviewer. My favorite for Android might be...

Round 1:

Quick call, 30 min max. Filter that they can speak the language, not come late, aren't intolerable assholes. Ask a question, let them talk, maybe 2-3 questions, doesn't have to be technical. This is to show respect for the next stage. It can also be a few chats via email, or a coffee. Usually HR does this.

Round 2:

Technical filter. This is to filter them out before they get to your expensive engineers. This can be your HackerRank/Codility. 0.5-4 hours is ideal there.

Alternatively, it can be a technical project, up to a weekend. A simple one like downloading files or accessing a network. Keep in mind that apps take a long time to build from scratch... it might take 2 hours to write a page, but it'll take a whole day to set up a project, architecture, network, testing suite, and so on. You'll want to assess that they can write code.

Round 3:

Personal interview, done by the engineering manager and/or colleagues. Dig into their resume, see if they're hiding something (good or bad). Don't hammer them with small questions. Don't be shy here, bring up all the yellow flags. Let them talk, then ask probing questions based on this answer, go with your gut. Many devs are introverts, and most of us can't clearly remember the details some engineering challenge from a job 3 years ago. Watch what makes them animated, watch what they zone out on.

Good questions are how they'd implement/update caches, hardware related questions if you do that. How would they implement a beauty filter on the camera? How would they make a SDK? How would they handle live data? What's their opinion on Jetpack Compose?

Bad questions are vague ones like "What drives you?" or "Tell me your biggest challenge." I've freelanced for years; I have a 22 page portfolio documenting challenges. Asking me which one was hardest is just going to activate my death march PTSD. Be specific.

Round 4:

Technical fit interview. Anyone here should have about a 50% chance of getting the job. Adjust previous filters if there's too many.

This should be about 1-3 full days, depending on seniority. Offer to pay for their time. Fly them into the HQ, give them a comfy hotel. This should hurt the employer too, especially the longer the interview is. This is also where you show respect so they pick you over other offers; any skilled person would still be evaluating 3 other options at this point. This is also where they get cold feet.

Again, building an app from scratch costs about half a day. Whether the question is trivial or difficult, it'll cost them. Online demos are popular during this pandemic, but many devs don't use an emulator, and they're terribly glitchy. A compiled file, or git branch could work better for demos.

So the ideal is to have a bit of code written up, based on your existing architecture. It's technical fit, let them figure out your code. Ask them to hack something into it.

The hard things to implement are architecture/Jetpack, testing, hardware (camera/file/permissions) related, database. Give them things that need to be in muscle memory and are already part of your workflow.

codingclaws 5 years ago | |

4 rounds? 2 is too much.

muzani 5 years ago | | |

It's a lot less than what I normally go through. But it depends on the goals. Do you want a "fair" trial to pick the best among your 300 applicants, or do you have just 3 applicants and just want to make sure your favorite is competent? Remove layers as needed.

A method used in the film industry is to just take the first person who can play the role. This is probably more luck based, but is 4 days of interviews fairer? But when they allow everyone to audition, they usually end up picking the one that fits a stereotype for the role, rather than someone who brings something special.