I periodically have to interview people and I find that I struggle to come up with ways to adequately determine a candidate’s technical knowledge. While they can present their resume and what they’ve done in the past, it is hard to tell how they really think. I don’t ask questions that I couldn’t answer myself as I don’t think that is fair. Many people ask basic computer science questions that I’d probably get wrong as I don’t have a computer science background; so I tend to ask questions to see how a candidate would handle a situation.
So far I’ve had mixed results in weeding out the good from the bad. One skill that I think is of utmost important for a developer is debugging. You might be saying that all developers do that, but some are far better at it than others. Debugging is one of my best skills and I’ve had a ton of experience at it inheriting other people’s projects. With that in mind, I came up with one technical test that could actually tell me if a candidate could debug and that skill goes a long way in development.
Now you ask, what is the question? The other day as I was poking through crash logs, a few stood out at me. Take a look at the following logs and see if you can spot why the apps crashed:
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libsystem_kernel.dylib 0x35cab054 semaphore_wait_trap + 8
1 libdispatch.dylib 0x342961c0 _dispatch_semaphore_wait_slow + 184
2 libdispatch.dylib 0x342961f4 dispatch_semaphore_wait$VARIANT$mp + 32
3 libxpc.dylib 0x3200e89a xpc_connection_send_message_with_reply_sync + 206
4 SystemConfiguration 0x374f5be6 _reach_server_target_status + 938
5 SystemConfiguration 0x374f6d56 __SCNetworkReachabilityServer_targetStatus + 14
6 SystemConfiguration 0x374dfaee __SCNetworkReachabilityGetFlags + 198
7 SystemConfiguration 0x374e0f7a SCNetworkReachabilityGetFlags + 190
8 MSNBC 0x000cb9ec 0x1000 + 829932
9 MSNBC 0x0006f998 0x1000 + 453016
10 MSNBC 0x0006abfa 0x1000 + 433146
11 MSNBC 0x00014d54 0x1000 + 81236
12 MSNBC 0x0006ab6e 0x1000 + 433006
Last Exception Backtrace:
0 CoreFoundation 0x3567188f __exceptionPreprocess + 163
1 libobjc.A.dylib 0x37a18259 objc_exception_throw + 33
2 CoreFoundation 0x356713b3 __NSFastEnumerationMutationHandler + 163
3 EmSea 0x001f9c2b 0xe2000 + 1145899
4 EmSea 0x00199bed 0xe2000 + 752621
5 EmSea 0x00223453 0xe2000 + 1315923
6 EmSea 0x002239c9 0xe2000 + 1317321
7 Foundation 0x351b6c29 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 17
8 Foundation 0x3510e6d9 -[NSURLConnectionInternalConnection invokeForDelegate:] + 29
9 Foundation 0x3510e6a3 -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 199
10 Foundation 0x3510e5c5 -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 61
On the first one, the hint is that the app failed to launch in time. I’m going to use these crash logs as a test to see if a candidate can tell me what went wrong. Neither app is mine and while I can’t see the code, I can immediately spot the problems.
In the first crash log, the app calls SCNetworkReachabilityGetFlags on the main thread. This call is a blocking call which means it won’t return until it is done; this call can take a significant amount of time to return and should never be called on the main thread, especially at app startup.
In the second crash log, it isn’t as obvious. What the developer has done is something like:
for (NSString *string in someMutableArray)
{
if ([string isEqualToString:@"Yuck"])
{
[someMutableArray removeObject:string];
}
}
The array is getting modified while it is being enumerated. The fix is pretty simple.
NSMutableArray *deleteArray = [NSMutableArray array];
for (NSString *string in someMutableArray)
{
if ([string isEqualToString:@"Yuck"])
{
[deleteArray addObject:string];
}
}
[someMutableArray removeObjectsInArray:deleteArray];
Are you good at reading crash logs?