July 11, 2014
June 2, 2014
A good coding interview question is not just the surface. A lot of programmers who have been interviewees but not interviewers complain about the questions. There are a large number of complaints of course but the one that I'm interested in recently is "how can my answer to this one question tell you much about my programming ability"?
A good coding interview question has several different possible approaches and does not rely on any moments of significant insight. While it's nice to find someone who can intuit the rabbit and turtle solution to list loop detection the ability to do that or not in any particular hour is not particularly indicative of programming skill. And of course with all such insight problems if someone has seen the trick before you learn very little.
A good coding interview question also has a couple of standard traps. Again, I don't mean traps you need supreme insight to get out of, but traps where the naive approach should run into them and think "huh, I need to do something more fancy". In my experience that ability is a very good indicator of a good future coworker - someone who sees the trap and rebuilds around it is much better than those who don't see the trap or those who see it and attempt to bull through it. Falling into a trap is not a red flag for me, especially for junior developers. Failing to see it once you're in it is trouble, and failing to see it once it is explained to you is a disaster.
Finally a good coding interview question is one with experience. If you can keep your question from being splattered all over the web long enough to use it on a series of applicants, you can now measure them against each other. You can learn what sort of speed to expect, which traps everyone always falls into and which ones it takes a special amount of inattention to fall into, and so on.
None of this is really apparent until you've been the interviewer a large number of times, so it's unsurprising that programmers who have only been interviewees doubt how much can be learned from a simple coding question. But like any skill in programming, you can't expect to understand it deeply without getting down and working with it.
May 28, 2014
An interesting metaphor with a little more example than is really necessary I think, but maybe that's because when he described his programming approach I instantly thought yes, that's true:
...my experience has led me to conclude that the most efficient way to program is to approach your code as if you were a dictionary compressor. Like, literally, pretend you were a really great version of PKZip, running continuously on your code, looking for ways to make it (semantically) smaller.
May 27, 2014
As I'm working with a lot of code written by a lot of people in a lot of circumstances, I find more and more I appreciate code that was written simply to solve the problem at the time. Generally I'm going into a piece of code to add some totally new idea and itis a forgone conclusion that I am going to rewrite portions of it. Sometimes I'm going in to find and fix a bug in code that is new to me. When what it does is all that it does rewriting or debugging is as hard or as easy as the code itself.
When the code is a nest of extensible handlers and strategy objects it is extremely rare that they can do the new thing I want to do. It may even be difficult to tell what any piece does as it delegates and injects. The writers thought they knew the future, but the future is rarely so obliging. The rare cases where the extensible code can handle what I want are usually which has already gone through several rounds of well thought out extension and refactoring in response to real needs.
January 3, 2014
But what were they thinking exposing the ordinal function, which returns an integer which is based on the order the enum values were in the file? You can change behavior by reformatting!
The claim in source is to have exposed it for use in EnumMap and EnumSet, two basically pointless data structures. They're so efficient! But their key is an enumeration so if to get big enough that efficiency matters means you will have enumerations with many thousands of members so efficiency is not your first problem. Or you are making millions of these maps in which case maybe you would like to express them as something even more efficient.
Clearly it seemed like a good idea at the time, but in the real world it just invites goofy mistakes for no real benefits.