• What is polymorphism?
• What’s the difference between a List and a Set? When would you use one over the other?
• When might you see deadlock?
• What is the difference between strong typing and weak typing?

These are mostly fair game. I dislike the polymorphism one, simply because it is so closely tied to most OO languages and inheritance that most people–when overriding or overloading a method, for instance–use it without ever thinking “oh! this is polymorphism in action!” Instead I might ask “what is inheritance and where do you use it,” which generally has a keyword or pattern in OO languages. But this is a personal preference and I can see the argument.

The strong and weak typing one was a bit unusual, because he was actually referring to type checking rather than type strength and got a little confused when I described C as weak-static, Java as strong-static, and Python as strong-dynamic (I think JavaScript is weak-dynamic, but I didn’t mention it).

What came next, however, were nano-questions:

• What package is List in?
• What package is File in?
• What keyword do you use to inherit with?

(We also got the “standard interview questions” such as “where do you see yourself in 5 years,” etc.)

Russ Olsen mentions two consequences of asking nano-questions:

Aside from telling you not much at all, the tiny question has two real costs: first it takes up the time that you could be spending getting to know this person, finding out if they are smart enough, if they have the right background, if they will fit into your group. The second cost of this kind of question is that it tends to tick off those smart, well rounded people that you really do want to hire.

I got the nano questions listed here right, but let me throw on a third consequence: Asking nano-questions can lead to false negatives by weeding out otherwise great fits.

A good engineer thinks abstractly in terms of designing and building systems, they think in terms of algorithms, components, and engineering design. They do not necessarily know all of the details of syntax of a given language, especially if they are used to a good IDE which does it for them (I use Eclipse: I type List and then control-space to load java.util.List). It is more important that I recognize which package I want than that I be able to name it off the top of my head.

Similarly, it is more important that I be able to tell you when and where I should use inheritance, and when and where I should use polymorphism, than to be able to spit off the definition.

Basically: Any question that takes 5 seconds to answer with Google is not a good question. My favorite phone interview question? “What’s your favorite language?” followed by “What are it’s weaknesses?”

Yet a lot of interviews and a lot of exams basically test you to see how well you would substitute for a compiler. Even the Java Certification Exams tend to focus on questions of syntax and compilation as opposed to either how well you can actually program or how well you can design a system.

I am a good engineer, I am not a good compiler. I cannot look at a block of code and necessarily tell you that the problem with it is that it won’t catch the ClassNotFoundException, and a modern compiler will tell me that this is a problem. If not immediately, than at least when I attempt to compile. IDE dependency? Perhaps, but that isn’t necessarily a bad thing since that is representative of the tools they will be using in the office.

In Short: Finding a good fit for your team is far too important to risk it with a game of Trivial Pursuit: Geek Edition.

Reading the comments, it reminded me of something my Russian mathematical modeling professor used to say back in school:

time + computation + thinking = constant

One solution, in C#, took 56 seconds. After some review and evaluation, he got it down to 126 ms. Another one in Java took “about a minute.” Several of the solutions, however, even written in Python without use of Psyco took the barest fraction of that time. My solution took 64 ms in Python, and another person’s took less than a 6th the time that mine did on the same hardware.

What made such a radical difference? Thinking about the problem a little differently leading to a different algorithm, memoization, precomputing , and things along those lines. There was no magic involved: some people spent more time considering the algorithm and implementation, other people just wrote the easiest code possible and let the computer do the work.

In a Numerical Methods class we did projects on numeric solutions to PDEs. My group did an elliptic PDE and we approached it using three different methods: two numerical approaches to the problem, one analytic for comparison. I did the analytic solution, and the final solution took around 10 pages of typeset equations to illustrate every step. The solution, however, was very robust, accurate, and extremely fast once implemented in software. It was easy to test, vary the edge conditions or the problem domain, and took only a few seconds to execute even for relatively complex problems. There were a few limitations, but most of those were not crippling and only effected accuracy in edge cases.

The purely numeric solutions, on the other hand, were extremely difficult to work with. The simplest solution had a variety of restrictions on the structure of the problem and took over two orders of magnitude of time longer. On the other hand, the numeric solutions were (for the most part) easier to describe and to implement. It seemed that the more complex the numeric solution and the more thinking and work it took before implementing, the faster it ran once finally implemented.

At a previous job a coworker implemented a solution where algorithm he came up with ran in $\Theta(n^3)$ time. Given the nature of the application, this was entirely too slow and so we put it up on the whiteboard to examine it. With some thinking, we got it down to $\Theta(n)$, which for a couple of thousand items is hugely significant.

This is a fundamental concept in Software Engineering, because frequently in optimization the first thing to check are the algorithms. Small efficiencies–which are generally relatively easy–rarely help significantly and can hurt long-run maintenance. A change to the algorithm–or apply techniques such as caching–can improve the execution time by several orders of magnitude and help later code maintenance.

• Create a 57×57 pixel PNG, name it “Icon.png”. In must be exactly 57×57 pixels and it must also be a PNG.
• Add the file to your project’s resources.
• Go into the Info.plist file and fill in the Value for “Icon file” to Icon.png, making sure that it matches the spelling and capitalization exactly.

Build and launch your app normally, the icon should be added and visible on your application.

The game of Go involves a ranking system to allow people at different levels of strength to play fair games. The system is widely employed in both in-person and online games, and some variation of it is used by every major Go server and organization.

The ranks go from 30k to 1k, and then 1d to 9d. 1d is 1 rank (or “stone”) from 1k, and 5k is 4 stones from 9k. There are some problems with this system (e.g., in reality the ratings are neither linear nor transitive), but they provide a good way of estimating someone’s strength before you play them for the first time.

In this essay we are going to examine the KGS rating data from 16 March 2008 for confident ranks. One of the key skills in data analysis is an understanding that data is data, and so it is a useful exercise to examine arbitrary data sets to see what you can discover. With this in mind, let’s examine the data and see what falls out.

The values here are rounded interval data: The zero point is arbitrary and while differences are useful (a 5k is 3 ranks away from a 2k), summation isn’t (a 3k + a 2k has no meaning). 4 stones is a bit of an interesting number, because the majority of games take place within a 4 stone handicap.

Before we can leap in and perform our analysis, however, it pays to look at the histogram to see the distribution of the data. We should see a few different things:

• A negative skew (-0.69, for the curious).
• A positive kurtosis (0.53).

What this means is that our distribution isn’t really normal, so we should be very careful about using the arithmetic mean, since the skew will bias our result. We could legitimately calculate it with this data, but it would be tempting to make errant conclusions, so we will stick to using quantiles.

I’ve marked on here the 10%, 25%, 50%, 75%, and 90% quantiles representing how many people fall below each value. The values for these are:

• 10%: 12k
• 25%: 8k
• 50%: 4k (Median)
• 75%: 1k
• 90%: 2d

This feels very compressed: over 25% of the players are between 4k and 1k. It also means that only 10% of KGS is below 12k in strength, and over 50% of the players are between 8k and 1k. Someone who is around 4k is within 4 stones of the majority of the server.

There are a couple of different reasons that this could be, and we’ll explore the reasons more when we look at the data for the American Go Association.

A graph of Bush’s approval rating over the last 8 years. The line represents a 5-day rolling median for his rating, which ranged between 90 and 23.

1. Go under the Executables directory of your project in XCode.
2. “Get Info” on your application.
3. Click on the “Arguments” tab
4. Under Environment variables set MallocStackLogging and NSZombieEnabled to YES. The former allows for malloc_history to be used, the latter logs deallocated memory, which can help find the memory address.
5. Run the app using the debugger (Command-Option-Y)
6. Check the console or probe around with the debugger to find the memory address you want to check.
7. Go to top of the Debugger Console and look for a line that looks like this:

launchd(28861) malloc: stack logs being written into /tmp/stack-logs.28861.launchd.7lhXSV

1. Taking the pid from that statement (28861) in this case and the memory address you picked up earlier (from, for example, a debug output line that looks something like this: -[NGTableViewDelegate tableView:didSelectRowAtIndexPath:]: message sent to deallocated instance 0x104f650 or from otherwise looking around with the debugger).
2. Type malloc_history the command line or shell malloc_history from inside of GDB.

This can help track down tricky problems with delegate objects.

There is a fallacy I like to refer to as the “clifford fallacy” that the news media seems particularly prone to making: “If this dog keeps growing at its present rate, in five years it will be the size of Clifford!”

With the introduction of autoboxing in Java 1.5, moving between these types would largely be handled by the compiler, but there is still a distinction.

Just as with null types, Objective-C also requires that you wrap raw types before inserting them into objects or using them in variable argument lists where the type id is expected. To help us with this, cocoa provides NSNumber.

There is a great deal of confusion among newcomers on the Apple developer forums and other developer-driven communities because of typedefs such as NSInteger and NSUInteger. They expect that these would work like Integer or Long and function as wrapper objects.

In actuality these are just ways of following the rule “avoid raw C types.” You can find their definition in NSObjCRuntime.h:

1
2
3
4
5
6
7
8

 
#if __LP64__ || (TARGET_OS_EMBEDDED && !TARGET_OS_IPHONE) || TARGET_OS_WIN32 || NS_BUILD_32_LIKE_64
typedef long NSInteger;
typedef unsigned long NSUInteger;
#else
typedef int NSInteger;
typedef unsigned int NSUInteger;
#endif

These are there for convenience, especially when combined with NSIntegerMax, NSIntegerMin, etc.

When we want to create a collection of NSIntegers (or doubles, longs, etc), we have three main options options:

Options

1. Create a “raw” C/C++ array
2. Use the Standard Template Library
3. Wrap the value with NSNumber and use a Cocoa collection

Raw C Arrays

Many times all that the developer needs is an array of numbers that can be processed quickly. In these cases it can be best just to use a straight C/C++ array. For example, this code creates an array of NSInteger and then stores the square of the index:

1
2
3
4
5
6
7
8
9
10

 
size_t size = 10;
 
NSInteger *array = (NSInteger *)calloc(size, sizeof(NSInteger));
 
for(NSInteger i = 0; i < size; i++) {
	array[i] = i*i;
}
 
free(array);

Standard Template Library

After setting up to use the STL the STL can be used the same way it would be in C++, just using NSInteger in the template:

1
2
3
4
5

std::vector<NSInteger> instance;
 
instance.push_back(1);
instance.push_back(2);
instance.push_back(3);

This approach is significantly more robust than using straight arrays and has the advantage of that everything does not need to be wrapped. On the other hand, it does not provide the convenience of working with Objective-C types and still needs to be converted to interact with Cocoa libraries.

Using NSNumber as a Wrapper

The final option, and the most robust, is to use Cocoa’s built-in libraries and wrap the NSInteger values in a NSNumber:

[NSNumber numberWithInteger:myInt];

NSNumber is a subclass of NSValue and it can store any of the basic numeric types. It should also be noted that NSDecimalNumber is a subclass of NSNumber.

NSNumber contains a variety of useful functions, but it does not actually contain the facilities for basic mathematical operations. To work with the numbers you will need to “unwrap” them once they get to their destination.

Further Reading

• NSNumber Class Reference
• NSNumber and NSInteger

Using the STL in Objective-C requires that you switch the file to use Objective-C++ by changing the file ending to .mm. After that you can import the various STL libraries normally: #import .

See Also:

• Standard Template Library Programmer’s Guide
• The Objective-C 2.0 Programming Language: Using C++ With Objective-C