Ted’s Rants and Raves by Ted M. Young

After I wrote yesterday’s blog, I knew I’d forgotten something, but forgot what it was that I actually forgot (I believe that’s first-order forgetting). Now I remembered (actually I remembered during this morning’s run): questions. Not my questions (as the interviewer), but your questions (as the candidate). Maybe it’s inexperience, but since we (Guidewire Software; we’re hiring! — plug, plug) have mainly been hiring senior (as in experienced and skilled, not older) people, I’m amazed that I don’t get asked in-depth questions about our development process, or even about the day-in-the-life of an employee at my company. After all, you should be interviewing the company just as much as they’re interviewing you. After all, you can’t just assume that it’s a great place to work, right? I’ve made that assumption in the past, and I’m too old to put up with certain practices, such as lengthy code reviews before checking code in (I’d prefer to pair program).

So, what are some good questions to ask? I’ll supply some of the questions I used to ask when interviewing (as a candidate) and those I would like to hear in a future blog entry, but I’d rather you give some thought to the kinds of questions you should come in with. Think about what you’d want your day to be like as an employee of the company, then ask questions relative to that ideal. Obviously you’ll never find an ideal workplace, but it’s up to you to find out on which axes the company is not ideal and whether you can live with that for the next 3-5 years.

The Best Question I’ve Never Heard

OK, I’ll give you one great question that I have yet to be asked (and this is after doing 12+ years of interviewing!): how many people have you referred to the company and how many of those have been hired? My answer would be 5. That will tell you a lot about how me, the interviewer, likes the company, more than a typical question I get, i.e., how long have you worked at Guidewire. There’s a world of difference between me working somewhere for a period of time and being willing to ask people I know and respect to work at the same place.

I’ve been meaning to write this post for a while, but after some frustrating interviews, I was motivated to finally put it down into words.

We’ve been interviewing a lot lately at my company (Guidewire Software, in case you’re interested) and I’d like to offer some tips on how to do your best. Note that I’m not going to tell you "how to succeed" or "how to get the job", because that will depend on your talent and skills. What I can tell you are the things that will allow you to make the most out of those talents and skills.

1. Communicate. In fact, over-communicate. If I’m interviewing you, tell me why you’re doing what you’re doing. Don’t make me guess. Don’t make me ask.

You may be the best darn programmer around, but if you’re thinking quietly and writing on the whiteboard in total silence, and then you make a mistake (and you will!), I won’t be able to help you. Just like in school where the motto "show your work" helps you get at least partial credit, if you just showed the answer it becomes either Pass or Fail — not where you want to be. So, if you tell me what you’re going to do and why and lead me through your thinking, then I’ll be much more willing to give you some hints or help and I’m definitely going to get a better sense of how you solve problems than if you keep your thoughts inside. As an "Introvert" (on the Myers-Briggs scale), I know that this can be hard, but if you can’t do it in an interview, then how do I know you can do it on the job?

1A. Verify assumptions.

This is the "be a good listener" part of communication. Repeat back what you think you’ve heard from me and make sure that agrees with what I said. For example, saying "so some other code will instantiate my object and I don’t have to worry about that, right?" is a good thing to do, because that may be completely wrong, but at least you found out before you started.

2. Admit when you don’t know something.

It’s much better for you to say "Y’know, I’m not really familiar with X" or "I don’t know Y" than to try and fake it or muddle through. If you admit you don’t know something, it’s unlikely I’ll hold it against you (unless you say "I don’t know Java" when the position clearly requires Java and you have Java on your resume). But if you push on through when it’s clear that you don’t really know it, I’ll be concerned that you’ll do the same thing on the job and not ask for help and therefore make serious mistakes.

3. Admit when you’ve gone in the wrong direction.

Similar to #2 above, but I’ve seen interviewees bomb when they keep pressing forward with a solution that’s not working or won’t work and they know it. If you’ve followed #1, I probably wouldn’t have let you go down that road so far.

4. Check your work.

I’m amazed (or dismayed) at the number of folks who write a bunch of code on a whiteboard and don’t read through it to see if they missed anything. Take a few minutes to read through your code and make sure there’s at least not anything obviously wrong. Pretend you’re the computer and execute your code.

5. Know how to write tests.

Seriously. In Java, main() methods with System.out.println()s are not tests (this isn’t 1996, y’know). One test for your code is not enough. 3 tests for 4 different classes is not enough. Naming a test "testValidation1" and "testValidation2" is going to make me wonder about how you name things (whiteboarding is a bit different, which I’ll talk about in a bit). In an interview I won’t push you to do TDD, but you have to know how you would test your code, since that’s as much part of the job as writing the code in the first place.

6. Know how to whiteboard.

Don’t write out every single little thing on a whiteboard. It’s perfectly fine to say "and then I just do more of the same here" or "normally I’d give this a name such as testWhenUserLoginFailsAnAuditLogEntryIsCreated, but I’ll just write testLoginFails". Time is of the essence in an interview and you don’t have time to write compilable code. As long as you’re following tip #1 and communicate well, you can take a lot of shortcuts on the whiteboard.

There are other things, but if you follow these tips, especially #1, the rest is up to your ability to actually program.

I’ve been reading lots about Kanban ever since David Anderson talked about his experience at the Nov 3rd (2008) BayAPLN meeting. On the Kanban developer email list, a new book on the topic was announced, "Scrumban", so I immediately went over to Lulu.com and purchased it. I’ll probably start reading it next week as it’ll be pretty quiet in the office.

In the meantime, if you’re at all interested in (or practicing) Agile, I highly recommend also reading about how Kanban is being applied to software development. The email list is a good place to start, as is David Anderson’s blog and articles.

This morning at Code Camp, Shaun Abram (http://www.shaunabram.com/) asked me about my "Building Better Tests in Java" presentation where I talked about using Test Data Builders instead of Factory classes (what we at Guidewire call DataGen classes). He said that he liked Builders, but wasn’t sure what the compelling benefits were. I’m glad he asked because besides giving me an idea for a blog entry, it’ll make me go back and make it more clear.

If you were at the presentation, here’s the reasons that I had hoped to get across:

• Prevent the combinatorial explosion of variations on methods to create an entity. In one example, we had 12 different variations to create a Policy. Yikes.
• Tests become much more readable. For example, would you rather read:

Activity myActivity = DataGen.activity( true, true, false, true, true, Status.NEW, Priority.MEDIUM, false );


or, with a test data builder:


Activity myActivity = new ActivityBuilder()

        .autoGenerated()

        .notEscalated()

        .ownedExternally()

        .mandatory()

        .recurring()

        .statusNew()

        .priorityMedium()

        .shared()

        .create();

If you said the first one, you’re far too familiar with our Activity entity and probably work at Guidewire.

Shaun also mentioned a problem where someone comes along and changes one of the defaults (i.e., the value of a property that wasn’t specified) in a factory method to fit the test they’re writing, only to break a bunch of other tests that relied on different defaults. They probably did that because they didn’t want to create yet another factory method that took the property as a parameter so they could choose a different value.

Also, Jeff Brown (http://blog.bits-in-motion.com/) at the BBQ last night mentioned that he was surprised I didn’t use the phrase "fluent interface" and he’s right! OMG! There goes my credibility. Seems like a need to rework my Builders presentation, but I think I knew that.

If you’re looking for slides and other information from my Silicon Valley Code Camp 2008 talks (either Easing Into Agile or Building Better Tests in Java), stay tuned! I’ll be uploading them very soon!

Thanks for coming!

I was just reading Per Olesen’s blog entry about Adobe Flex and the fact that it’s closed source and proprietary, and it hit me that the reason I haven’t tried Flex is because the source isn’t available. I remember years ago at eBay when we were using C#/ASP.NET 1.1 for internal web app development and it was so frustrating because when an exception was thrown inside the framework, you’d hit the “no source wall”: the place where the stack trace leads you to code that you can’t look at. At least in the Java framework I can trace through the code and even set breakpoints in framework code so I could figure out if it was my code’s fault or a bug in the framework. Usually it was my code, but whereas in Java I could figure out what I was doing wrong by looking at the Java framework code, in ASP.NET I often just gave up and tried a completely different way of solving the problem (usually by tossing out the use of ADO.NET). Sometimes I even went to the Mono source to see what they’re doing and it did help when I was creating ASP widgets, but it’s not the same thing as having all of the source available with the ability to step into it in a debugger.

I haven’t followed .NET development much since I left eBay, but I’ve noticed that Microsoft has opened up some of the .NET framework source, which is definitely a move in the right direction.

So, I guess subconsciously I’ve been staying away from otherwise appealing frameworks if I can’t access the source code. And it doesn’t have to be “open source”, as in GPL, LGPL, etc., but I at least want the option of seeing it if I need to. I don’t mind proprietary, but without the source, I’m going to choose another framework, my time is too valuable to hit my head against the wall otherwise.

I use a piece of software that’s currently going through a beta period for it’s next release. It used to be that there was a new beta release every couple of weeks, but then that was reduced to every month. This was fine with me because I often didn’t have time to install every new beta. However, the second beta had some serious problems and so I had to return to using the first beta. One month after the second beta, there’s still no sign of the third beta and the natives (users in the support forums) are getting restless.

The reason for the delay? The developer decided to switch to the latest version of the IDE/Language/Framework and some of the third-party components being used aren’t compatible. So now the developer’s in a bind and has to either fall back to the previous version of the framework, or try to get the problems with the third-party component resolved. This means another several weeks or more will go by before things are stabilized enough to put out another beta.

The moral of this story is that while you’re in the beta cycle, you should minimize the changes to your tools (IDEs, frameworks, components, libraries, operating system, etc.) so that you can focus on getting your product out the door. Doing otherwise is like trying to add a turbo-charger to your car’s engine while you’re driving.

On the other hand, sometimes you need to upgrade one of your tools because of a bug fix or a new feature that you really, really need (this is more like pulling over to the side of the road to change a flat tire). In that case, change only one thing at a time — don’t try to change other tools just because you’re already on the side of the road: that’s no place to be doing major overhauls. Wait until the next release when you’re safely in the garage and have the time and tools to ensure that you can do a quality job.

Test-Driven Development or Test-First Programming, or whatever you call it, is a way of programming where you create the test code before the production code. There’s a new push for doing this here at Guidewire, and I’m looking forward to doing more of it and talking about it here. In the meantime, I’m reading the early access of "Test Driven" by Lasse Koskela (you can pre-order it at Amazon). I’m hoping to see more of a focus on the "customer acceptance" part of test driven development, so we’ll see how that works out.