Deirdre Saoirse Moen

I’m going to go out on what seems to be a wildly unpopular limb here and say this: asking a developer to write an implementation of a sort algorithm is almost certainly a bad job interview question.

Why? Because you’re likely not hiring someone to write implementations of sort algorithms. Even if you were, they probably would not be writing optimized code in a job interview situation, so what’s it really testing?

Problem solving skills aren’t universal, nor does the ability/inability or inclination/disinclination to solve one kind of problem necessarily reflect one’s overall skills. Or lack thereof.

Remember that the person being interviewed is also interviewing you and deciding whether they want to work with you or not. If you ask a coding question that’s more directly relevant to the job at hand, then they will have a better sense of what it is you do every day—and whether that’s something they want to do, too. You’re engaging them in your problem space, not asking something they may or may not warm to even if they’d love the job you’re interviewing for.

For example, in an interview I went on once upon a time, the interviewer said, “We have this problem, and I’d like to see how you approach it.” So it was a supportive, shared, coding question. I had questions about some aspects of the requirements, which the interviewer then answered. That was a great interview approach.

I’ve come to dread the sort interview questions. Frankly, it’s not a part of programming I enjoy. I like the fact that other people think about sort implementations. Yay, diversity.

I remember once, I think it was 2005, having re-reviewed all the common sort algorithms, then flown to a job interview. The question: “How would you write a shuffle algorithm?”

I remember that instant of total frustration far more than anything else from the interview.

My answer was something like: create a hash of something like a random seed from the current time plus some aspect of the information you had about the song (since it was about shuffling songs) like the title, and then sort the hashes. I have no idea if that’s a good answer, but it’s what I came up with at the time.

Meanwhile, I’d much rather focus on whether we need this column or not, whether that schema is better suited for the project than this other one (and why), can we produce the desired page with less HTML/CSS markup? And how much can/should we shunt off to JavaScript? How much jQuery do we need? Does this page degrade gracefully without JavaScript? What pieces of this should go in the controller vs. the model or the view (and why)?

Using a different field, asking someone who’s applying for a general application programmer to write a sort implementation is like interviewing for a job as a Cosmo article writer and being asked to produce a sonnet in the job interview. (With the added bonus of live critique questioning your choices.)

Now that’s not to say that knowing how to write sonnets isn’t a cool skill. It is.

But let’s look at what an article writer needs skill at that a sonnet writer doesn’t:

• Ability to write whole sentences
• On time
• Correct length (sonnets have a lines/syllable count, but what an article writer needs is correct amount of space on the page, which is an entirely different form of length requirement)
• On correct subject
• Supports advertisers
• Current and relevant
• Literal language

What skills a sonnet writer needs that an article writer doesn’t:

• A feel for syllables
• Exhaustive vocabulary (because poetry readers will look up words but Cosmo readers almost certainly won’t)
• How to write something timeless
• The ability to fiddle until it’s “just so”
• Metaphorical language

99.9% of all people making their living as writers aren’t writing poetry. 99.9% of the rest write greeting cards for money. The other two are poetry professors. Random aside: did you know Cupertino has a poet laureate?

99.9% of all software engineers making a living as such aren’t writing implementations of sort algorithms or developing new sort algorithms as their job.

Ask more relevant questions.

Originally published at deirdre.net. You can comment here or there.

I started programming for a living before there were a lot of formal methods in widespread use, though they were coming along. Then I got on some projects where it seemed to be "design all the time and could we please frakkin' write something already?"

One time, I broke. I was in a meeting, mocked up a prototype while everyone else was hashing things out -- because I was bored. Spent a week writing it (in C). Three weeks later, it was in production. It solved too many problems. :) Created a couple small ones in remote locations (as it was, unfortunately, a bit less efficient on a high-latency network, but that was a function of what was possible). No one else was even really ready to discuss what the parameters were, they would have taken months.

Flow charts -- well, I could stand making a page of them. Secretly, I hated them, but it was so impossible to admit that in front of other people because they were so "standard."

Then I had a boss who recognized that I loved doing and wasn't so big on the big picture organizing because it would make me chew through the straps. I had an innate sense of organization, but spending a lot of time in meetings and so forth, well, it really wasn't me, let's leave it at that. Said manager introduced me to a book. It is, to me, the most useful book about organizing information I've ever read. It's Tom DeMarcon's Structured Analysis and System Specification.

Sounds dry as hell, right? Well, it's not going to win any thriller bestsellers, that's for sure (though it is more interesting than 99% of what I've read about software), but it said two things that had me perk right up:

1) The most important thing to plan is how information transforms and flows through the system from a bottom-up perspective.
2) A flow-chart is inherently top down.

In other words, the method I instinctively already disliked was wrong. (Edited to add: flow charts can be useful, actually, just not at this particular phase. One way they can be useful to a writer is comparing two different interpretations of a scene: what structural changes would need to follow if this happened vs. that happened?)

The following year, after changing jobs, I was working as a database administrator for a large Japanese manufacturer. They had a complex software system they'd paid millions for. It was broken in some critical ways, but the contracting firm didn't see it that way. I went and wrote down how every piece of information flowed through the multi-machine, multi-database, multi-OS system -- and found where there were disconnects. These were easy things to resolve -- if you saw them. After one pointed meeting where I laid it all out (amusing the Japanese execs to no end), the contractor saw the light and it got fixed. And lo, the system worked. There would never have been so much unhappiness on that project if they'd looked first at how the data flowed through the system. Instead, it was a bunch of disconnected parts that worked fine on their own but didn't work together.

Now, consider a story. A scene has information -- characters, settings, things people are doing, events. A scene has movement. Things change. This is all information. Further, all the scenes do need to work together, and there's got to be some kind of flow -- even if it is unconventional -- through the work.

Thus, it dawned on me that my organizational problem of how to manage my larger work, e.g., a novel, was the same as how to handle a larger software project: look at the points of transformation. Work from there.

Now, I'm a pantser. I am a serious pantser. I don't do any of this until I have a first draft.

I developed a few conventions. For example, if there were multiple viewpoints, then the bubble for the scene's actions would get the viewpoint character's color. If it's a single viewpoint character (like first person), then the background color would be based on who the scene was mostly about.

I haven't found an example I felt like posting yet, but I may go find one.