For the tl;dr crowd, my take is that interviews are extremely difficult, and so you (and I) should have some empathy.
A while ago, I did a bunch of interviews for a junior iOS developer. I gave them what is apparently a quite common exercise: in a simple iOS app, get some JSON data from a server and use it to populate a table, including, for each entry, a link to an image file to download separately.
I just made such a project, called Numbers, available here.
When you first run it, it shows a table filled with entries 1-20, where the brightly-colored number icons are each loaded separately.
A button to the right of the navigation bar is labeled “Wrong”, meaning you’re currently using the image loading implementation that’s incorrect.
If you scroll to the bottom of the table quickly, you’ll see that initially, the rows you uncover will be temporarily populated with incorrect icons:
That’s because, in the incorrect implementation, the async network calls insert the loaded images into the cells that originally requested them.
But, as Everyone Knows, cells in UITableView are reused when you scroll, which means by the time the network calls finish, the original cell might be in use for at a different row, and it shouldn’t display the original row’s contents.
Instead, the network call for an image should update the cell that currently represents the row.
If you tap the “Wrong” button, it will change to the text “Right”, and that’s how the application will behave when it reloads the table. Scrolling quickly to the bottom of the table won’t result in erroneously populated images anymore.
When I was interviewing, if the interviewee said they knew table views, I would give them this exercise, and would consider them not worth hiring if they made that rookie mistake.
Nowadays, it’s clear to me that this is a Gotcha! question like any other.
Instead of it being a question about how they think, how they solve problems, it requires a very specific piece of information you either have it your head at that moment, or you don’t.
In a recent interview where I was debugging a problematic table view implementation, I failed to recognize a similar incorrect image loading mechanism — until nudged to do so by the interviewer. I just didn’t see it. If that interviewer had been as quick to judge as I had been in the past, I wouldn’t have gotten the job.
As a final note of curiosity, you might notice that, in the Numbers project, I reset the NSURLSession each time before reloading the table view’s contents. That’s because NSURLSession has its own cache of network call results, and if I didn’t reset it, you would only be able to reproduce the “wrong” behavior the very first time you tried it. Every subsequent time (including across app relaunches), the images would “load” instantaneously from the cache.
While I would never recommend shipping the wrong implementation, even if you did, these days, Apple’s frameworks would mitigate its impact.
I did quite a bit of interviewing recently before I got my new job.
I’ve come to believe your success depends much more on the attitude of the interviewer than how much you prepare. Anyone can find a gotcha question you can’t answer. Anyone can twist your lack of instant recall of a topic into an irrecoverable failure. You simply can’t know everything off the top of your head.
And on the flip side, anyone could talk you through your nervousness or your sudden blanking on things-you-knew-an-hour-ago, if they really wanted to. Anyone could connect with you and get you to open up about what you understand.
Could, but often won’t.
So while you should definitely do the preparations that they advise you to do — many companies give you fairly detailed lists of things to study — you shouldn’t kick yourself when you get rejection emails.
And you will get them, and they’ll almost never give you very helpful feedback. That just seems to be the way it is, however frustrating.
I have one major piece of advice, if you’re interviewing for a developer job, or really if you’re interviewing for any job.
If you get the sense that the interviewer is dissatisfied with how you did, don’t hesitate to ask what they’re dissatisfied about.
For example: “It feels like I didn’t completely answer your question. Is there anything I could expand on for you?”
Or: “Did my solution to the exercise cover everything you wanted me to cover?”
If they just say yes, but they still seem dissatisfied, well, then there’s nothing you can do.
But I’ve often found that this will bring forward whatever reservations they have, and give you a second crack at them.