LinLog

Developer interviews

pageer@skepticats.com (Peter Geer)

At my current company, we've been trying to hire a new back-end PHP developer for some time. As the senior engineer on staff, and the only back-end person, it's my job to handle the technical portion of the screening process, including resume screening and technical interview. Unfortunately, I have lots of other work to do, so I never had time to come up with a really good procedure to test candidates. In addition, most of the interviews are over the phone with people in other cities, which makes it difficult to have them write code without some advanced preparation - which, again, I haven't had time to do.

So, as a compromise, I came up with a standard list of questions that I ask candidates. I originally wrote this list with the intention of using it for junior developers (1 to 3 years of experience), thinking that anyone with 5+ years of experience would breeze through it. However, I've found that a disturbingly large percentage of more experienced developers fumble more than one of the questions. Unfortunately, I'm not yet sure if that's just because we're getting poor quality applicants, or if it's because my standards are too high.

Therefore, in the interests of helping my fellow developers - both those looking for new opportunities and those who are interviewing the first group - as well as in the hopes of getting some good feedback, I present my list of interview questions. Note that I do not include answers. There are two reasons for this:
1) There is not always a single "right" answer - it is perfectly valid for the question to turn into a conversation.
2) If you're an interviewer and you don't already know the answer, you shouldn't be asking the question; if you're an interviewee and you don't know the answer, you should look it up and learn something new.
With each question I've included some notes on the question's intent. Some of these are conceptual, some are simply tests of knowledge, and some are spring-boards to further discussion.

Solve the FizzBuzz problem. How would you solve it in an object-oriented fashion? Using recursion?

Define "inheritance" and "polymorphism". Give an example of when you might use each.

What is the difference between an "abstract class" and an "interface"?

What is "SQL injection" and how might you protect against it? What about XSS/CSRF?

strip_tags(), htmlentities()

In JavaScript, what does it mean to say that functions are "first class" or "first order" objects?

What is the difference between NULL and the empty string in SQL?

NULL = ''

What is an "index" in a database and how would you decide what columns to index?

Given a sample HR database that contains the following tables:

Employees (employee_id INTEGER PRIMARY KEY, employee_name TEXT, ...) Departments (department_id INTEGER PRIMARY KEY, department_name TEXT, ...)
What would you have to add to the schema to associate employees with departments?

Describe a project you worked on that was particularly enjoyable or interesting. What did you like about it?

Personally, I consider this list to be inadequate at best. But as I said, I haven't had time to develop an adequate test and this is at least better than asking "So how well do you know X?", if for no other reason than it's harder to BS an acceptable answer. Any thoughts or opinions are welcome.

FeedDemon upgrade

pageer@skepticats.com (Peter Geer)

Yesterday I upgraded FeedDemon to version 4. In the process, I did something new - I paid for a license.

For the last year or two that I've been using it, FeedDemon has been ad supported. The full feature set was available for free, but there was a little ad in the lower left-hand corner. If you wanted to get rid of that, you could buy a license key, but frankly, I never really cared that much.

Now, however, the business model has changed. There's now a free "Lite" version with some missing features and a paid "Pro" version with all the features and no ads. One of the annoying parts of this was that the features in the "pro" version are not all new - the for-pay features include some things that were previously free.

This bothered me a little for a couple of minutes. Then I read the FeedDemon author's article about why he changed the business model. Apparently, FeedDemon is no longer run by NewsGator. It's still branded for them, but they let the author, Nick Bradbury, go and returned control of the program to him. Apparently he's now doing the independent developer thing and making his living selling FeedDemon.

Well, that pretty much sealed the deal. I've tried a number of RSS readers - Linux, Windows, and web - and FeedDemon is the only one I've ever really liked. This is a program I use every day, I want some of the "pro" features, and buying it would help out a fellow developer. And to top it all off, he's only asking a lousy $20 for it. That's a no-brainer. So I bought a license and I'd encourage any other FeedDemon users to do the same.

Incidentally, some of the comments on Nick's article were really depressing. With users like some of those, I don't envy him trying to make his living off FeedDemon. Supporting a one-man project is tough enough when you release it as open-source and you don't owe anything to anyone. It must be hard trying to do right by people who paid you money when they feel your work is lacking - even (especially?) if they're clearly being unreasonable. Working 9 to 5 (well, officially 8 to 5 in my case, but you get the idea) might not be sexy, but at least it's stable and they pay someone else to deal with unhappy customers.

One thing I did notice in the new version that I found a little disappointing was the change in some of the newspaper themes. FeedDemon basically displays feeds as an HTML document and has a number of themes that control the look of the feed list and allows you to set themes on a per-feed basis. Changing the theme is now a "pro" feature, and I really wanted this, as I have several feeds that I have set to use the Outland theme, which is a nice, clean theme that displays full entries rather than just summaries. However, this theme is gone in FeedDemon 4.

The up side is that, while the theme format may have changed in FD4, it hasn't changed much. The "styles" are still just that - CSS and XSLT. In fact, I still had the Outland.fdxsl2 theme file sitting in my "C:\Program Files (x86)\FeedDemon\Data\Styles" directory, so I just tried renaming it to Outland.fdxsl4, restarting FD, and guess what? It worked! The only real problem was that the border on the feed was a little off, so I commented out the border on the HTML element (line 24), and it was just fine.

Ron Jeffries rocks

pageer@skepticats.com (Peter Geer)

Last night I spent some time browsing Ron Jeffries web site. While I've seen a few of the items on Ron's site before, I never really stopped to look through - and boy was that a mistake! It turns out that Ron has a number of very interesting and entertaining articles on his site. I particularly recommend his classics section.

Included in the "classics" is an article entitled We Tried Baseball and It Didn't Work. Unless you're lucky enough to have only ever worked in high-quality organizations, which really, really had their act together, this article will probably ring true on some level. It also nicely sums up a number of Ron's other articles on the use and abuse of the term "Agile".

This kind of reminded me of when my current team first started to "do Scrum". For the first few months, the entire team agreed that it just wasn't working. Of course, we weren't exactly following the book in our application of Scrum: our "stand-up" meetings often lasted 30 to 60 minutes; we didn't always deliver "done-done" software at the end of a sprint; our sprints started at a month long, and when we failed to finish our tasks by then, we pushed the date. So "Scrum wasn't working" for us, if by Scrum you mean "some process that involves a daily meeting." But we had to do Scrum, or come up with some other "Agile" process, because if it's not Agile, then it's not good. I mean, how could all those industry pundits be wrong?

Fortunately, we've figured things out a bit better now. We're much closer to a real Agile process and it's working better for us. Of course, we're not really there yet, but we're making progress. And, really, that's what matters.

Sort of agile

pageer@skepticats.com (Peter Geer)

While catching up on Jason Gorman's blog today, I came across this entry, which linked to the Half-Arsed Agile Manifesto. In a word, it's awesome.

That manifesto made me think back to when I started my current job. I was reading through the process documentation for our parent company (whose processes the spin-off I work for inherited). The documents referred to themselves as describing the "agile" process the company employed. But as I read through them, with the descriptions of requirements documents and formal hand-off procedures, I just kept thinking, "This sounds a lot more like waterfall than any agile process I've ever heard of." It's always nice to know you're not alone in having experiences like that.

Sadly, while my team's current Scrum-like process is considerably more agile, we still have some vestiges of that. For instance, the stated expectation that our initial estimates will be 90% accurate based on what is (very) generously described as "80% definition" by product management. So we're only mostly sure what we're building, but we're almost positive how long it will take. I'm still not sure how the math is supposed to work out on that. Fortunately, we don't take that expectation too seriously.

The world's most accurate Twitter account

pageer@skepticats.com (Peter Geer)

Thanks to Carl and Richard from DNR for pointing out the best Twitter stream even. They mentioned it on show 379. You can find it at: http://twitter.com/thisispointless.

There are 3 things I like about this stream. First, it's actually kind of funny. Second, I think the username pretty well sums up everything about Twitter. And third, I just love the open mockery when there are people out there who are actually trying to communicate over Twitter. Because apparently nothing worth saying could possibly take more than 140 characters.

I'm sorry, that was a cheap shot. I was misrepresenting the true purpose of Twitter - to send pointless messages that people really shouldn't care about.

The truth about government

pageer@skepticats.com (Peter Geer)

Leon Bambrick had a really great blog post today. You know the "one laptop per child" program? Well, he thinks it's great that the IT industry is doing this and that other industries should have similar programs, such as "one handgun per child." My favorite, though, was the program for government:

Governments could offer "One soul-destroying job in a miasma of bureaucratic inconsequentiality Per Child"

If you're a regular reader of this blog, or a member of my family, then you probably know that my last job was as a Systems Analyst in the IT department of a local government, so that quote really spoke to me. I know you hear people say things like that about public sector jobs all the time, but based on 6 years of experience, I can say that it's all true. There's a general atmosphere of hopelessness, where most things don't make any sense, lots of them don't really work, and everything is more complicated than it needs to be, yet nobody seems to think this is a problem. The only way to keep your sanity in such an environment is to simply stop caring. After all, nobody else has.

Of course, the private sector is no panacea. But at least there's always the possibility that you can improve your organization or you lot within it. Or at least change something.

The one thing I will say for government work is that if gives you a different angle on conspiracy theories. After a job in public service, it's impossible to waste even a second seriously considering any of those grand, sweeping government conspiracy theories you see floating around the internet. I mean, most government offices can just barely manage the job they're supposed to be doing. How are they going to manage some sort of vast cover-up? That would require motivation and initiative, and those aren't allowed in public service.

ESRI class day 2 - boredom and web access

pageer@skepticats.com (Peter Geer)

More live-blogging today. Unfortunately, it turns out that's the only kind I'll be doing until the class is over. I'm staying at the Crowne Plaza hotel, and while they offer WiFi service, they charge $10/day for it! That's actually worse than the $4/2-hour block that they charge for the AT&T WiFi at the Barnes & Noble back home. At that price, I could get 5 hours of service, and there's no way I'm going to be online that long here. Fortunately, the PCs in the training room for the class have web access, so I can at least check my e-mail.

Yesterday afternoon and this morning we got more into the details of managing ArcGIS geodatabases. Things like connection methods, authentication, data loading, management tools, "gotchas", and so forth. Basically, the stuff I will probably never need to know.

I'm actually a little ambivalent about this class so far. On the one hand, it's absolutely mind-numbing at times. It's not that the class is bad, it's just that it's getting into details that have absolutely no relevance for me.

On the other hand, it's actually very interesting in an academic sense. After all, we're talking about a system that scales up to clustered, multi-terabyte databases. The ArcGIS server runs under Windows, UNIX, and Linux and supports pretty much all the major DBMSs - Oracle, SQL Server, DB2, Informix, and there was even some talk of people using Postgress and Sybase. So we're really getting a closer look at the architecture of a very complex, high-end system. Plus our instructor has been around long enough that he can talk about how things have evolved over the years and the direction the architecture has taken. We're not just getting the tedious technical details, but some insight into the layers of the system, the APIs involved, and how everything interacts on various levels.

So as a case study of a major major information system, this class is actually quite interesting. However, it's really a class on managing geodatabases, not a case study on ArcGIS. So while the concrete details are putting me to sleep, the high-level stuff was definitely worth hearing. As a programmer, you tend to look at and read about things on more of a code-level. It's good to see how the "big boys" handle complicated design issues.

At the ESRI class

pageer@skepticats.com (Peter Geer)

Well, here I am at Constitution Plaza in Hartford, Connecticut. I'm actually here on a business trip. My employer sent me to a training course with ESRI entitled Data Management in the Multiuser Geodatabase.

There are a few things to note about the very fact that I'm here. In the 6 years I've been with my current organization (which is far too long), this is the first time I've been on an out-of-state trip. In fact, it's the first time I've been on a trip that lasted longer than a day. It's also the first off-site paid training class I've been sent to. Kind of seems like a waste, given that if things things go well, I'll be able to get the hell out of here before I have a chance to put any of this to use.

As for the class itself, I have no real complaints so far. It's actually hosted by the City of Hartford IT Department, which has 2 people attending. The instructor, Jim, has been in the GIS business forever and has been working for ESRI for 14 years. He's really nice and seems pretty knowledgeable, so I'm actually enjoying the class so far. In particular, learning about the system architecture was kind of cool. Of course, I'll probably never put any of the stuff he's teaching us to use, but at least this gets me out of the office for a week.

One cool thing I've discovered is that Python is apparently one of the favored languages for automating ESRI's system. In fact, the lap machines we're using for the class actually have Python 2.4 interpreters installed on them. I don't know if we'll do any scripting in the class at all, but I just found that to be really cool.

Agile, shmagile

pageer@skepticats.com (Peter Geer)

There was an interesting article over on the Typical Programmer the other day. It consisted of a criticism of an anti-agile development paper entitled Agile Methods & Other Fairy Tales, by David Longstreet. While the criticism was interesting in its own right, I found it even more-so after reading the actual paper.

The main criticism the Typical Programmer leveled against the paper was that it was attacking a straw man. Specifically, he claims that many of the practices Longstreet describes are not actually agile, but simply broken. They just look agile because they don't involve much in the way of design, documentation, and so forth. Real agile methods, however, do not scorn those things when they are necessary.

I don't claim to be an expert on agile methods. However, I found Longstreet's paper to be good in some places. It certainly wasn't as intellectually bankrupt as the critique would lead us to believe.

Thinking about all this raised a few questions in my mind.
1) Couldn't the same complaint be leveled at the agile people? That is, might one not claim that they're not reacting against waterfall-style methods, but rather a caricature of them? After all, you can dress some broken methods up as waterfall just as easily as you can dress others up as agile.
2) Just what are real agile methods anyways? How do you differentiate it from "fake" agile? Viewed from the outside, it seems like agile methods could very easily be mistaken for cowboy coding. How do you decide where the line is?
3) Is it just my imagination, or do agile methods get less controversial every time I read about them? For instance, I remember when everyone was talking about the pair programming advocated by eXtreme Programming. Now, it seems like nobody cares about that anymore. (Actually,it almost seems like people have come to a silent agreement that it was kind of a silly idea.) These days, I read about the de-emphasis on documentation and other non-code artifacts. But then, when pressed, the agile people say they're only against the useless documentation.
4) Isn't "requires producing useless documentation" almost the definition of a broken development method? Yeah, sometimes it's demanded by the customer, but in other situations, does anyone ever think this is a good idea? It seems to me that if you're writing design documents that you never use, then you're missing the whole point of writing them in the first place.

Brain dump completed. Time to do some more reading on agile methods.

Yes Virginia, there IS software engineering

pageer@skepticats.com (Peter Geer)

We've all heard the phrase "software engineering." The question is, does such a thing actually exist? Many programmers say it doesn't. I disagree.

Steve McConnell recently wrote a couple of very interesting blog posts on this very topic. The second was in response to this post. Eric echoes many of the typical "software development isn't engineering, it's a craft/art/form of black magic" arguments. Steve provides what I think is a good rebuttal.

I have a few problems with the typical anti-software engineering arguments. For starters, the "building software isn't like building bridges" line really misses the point. The idea is that building bridges involves repeatable and predictable patterns that allow engineers to accurately estimate project progress, whereas in software, every project is different and hardly anyone ever knows for sure how long things are going to take.

There may be some truth to that, but there's no reason to assume it's due to any inherent difference between civil engineering and software development. Part of it is simply that most programmers don't develop a lot of very similar systems because they don't have to. When you need a new bridge, you have no choice but to build it, but with software, you can just copy and customize.

But really, the reason most software estimates are just wild guesses is not because of the nature of software development, but because most development organizations are miserably primitive and unorganized. To form reasonable estimates, you need historical data. That means you need to track how long each phase of a project takes. Then you can run the numbers for similar projects and come up with a reasonable estimate for a new project. It's not rocket science. It's just that many organizations simply don't bother to do it.

Of course, as Eric mentioned, there is the issue of varying user requirements to consider. The whole reason we have custom software is that users have differing requirements, and so every application is unique in some sense. But if we're going to be honest, that only goes so far. Every custom business application may be different, but there are still a lot of similarities. You have your database layer, your business rules, your user interface, your reporting, and so on. They may never be exactly the same from application to application, but they're usually not fundamentally different. Think steel bridge over a river compared to a concrete bridge over a ravine. They're not exactly the same, but they're still comparable on some level.

Bottom line, software engineering, like "regular" engineering, is about process, not product. Just because you're building something doesn't mean you're doing engineering. A rigorous software development process is the exception in our industry, not the norm. So it's not that software engineering doesn't exist, it's just that the vast majority of the people writing software are not doing it. If you want engineering, head to someplace like Praxis Critical Systems, not your run of the mill .NET contractor.