Ted’s Rants and Raves by Ted M. Young

November 22, 2009

How To Do Your Best in a Technical Interview, Part II: Questions

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.

November 21, 2009

How To Do Your Best in a Technical Interview

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.

November 2, 2009

PragProWriMo: Day 1

Filed under: General Rant

If you’ve followed my tweets, you already know that I’m participating in the November PragProWriMo, or the Pragmatic Programmers Writing Month. It’s not a contest or anything, but it is an opportunity to start writing what might become a book, or just a series of blog posts.

Note that these are not really blog posts, or even self-contained tidbits, but just what I’ve happened to write on that day. So, while you can feel free to comment, I’ll not really be paying attention to the comments and certainly expect things to not be well-written, let alone make sense without additional context. This is simply a way to allow people to see my writings as soon as they’re written and nag me if I miss a day of writing.

Day 1

Fluent Testing

ATDD, or Acceptance Test-Driven Development is one of the more recent techniques in developing software. The idea is to use code-based acceptance tests instead of English-based specifications or requirements. While it seems that English accetpance tests would be easier to write, in fact, they are more difficult to write well. It’s quite hard to be precise in a natural language where words are often ambiguous. For example, in this English-based acceptance "test"

* Filter searches on the Account number and the Policy number

The context here is a text field for a "filter" that limits the records that are shown. This simple statement can be interpreted in different ways. Before reading my interpretations, think about how many ways you could interpret it.

1. Text entered in the filter text field is used to search in the account number field, the policy number field or both.
2. The text is searched for in both the account number and policy number fields and must be found in both in order for the record to appear.
3. The filter text is used to search in the account number field, and if no records are found, then search in the policy number field.

You might be thinking that this is obvious and should have been stated more precisely when this requirement was discussed. However, it’s very difficult to always express the intent of requirements with enough precision on a consistent basis without missing something, or contradicting some other requirement. Even if you do end up with sufficient precision, you’ll likely end up with a 300 page requirements document that, I guarantee you, will end up being interpreted differently than from how it was intended. Since the whole point of agile development using story cards is to discuss these details (as in a "token for conversation") on an as-needed basis, how do you make sure that the developers don’t forget the details as they’re developing the code? The answer is executable acceptance tests.
The problem I’ve seen in coming up with a good form for executable acceptance tests (no, I won’t call them EATs) is that in trying to formalize the English, you end up with something that is close enough to English that people understand the intent, but not quite enough like English so that people find it hard to write. The solution here is a fluent testing API. Something that is not only precise, but can be executed against production code once the code has been written and, going with the ATDD technique, use by developers _while_ they’re writing the code. For example (using JUnit in Java):

  public void sortByInvoiceDatesIsVisibleOnlyWhenGroupingByInvoiceAndByItem() {
    openCreateDirectBillPaymentPage(account)
      .groupByInvoice()
      .aggregateByItem()
      .assertSortByInvoiceDatesIsVisible("Sorting by invoice should be visible for Group By Invoice Aggregate By Item");
  }

 

It’s true, this test only checks that the "Sort By" selection element is visible, depending on various combinations of other selections ("Group By" and "Aggregation"), but it’s also very explicit under what conditions it should be visible and, most importantly, is not that much less readable than if it were written in English. It’s hopefully clear that after opening the "Create Direct Bill Payment Page", we "group by invoice", then "aggregate by [invoice] item", and finally, the check (assert) that the "Sort By" element is indeed visible. The string passed to the assert is the failure message, and helps describe _why_ the assertion should be true.
There’s an additional feature that puts this over the top, and that’s an IDE’s ability to provide a list of choices of methods that are available on each object, aka, code completion. This allows the executable acceptance test author to be guided by the code completion of methods that are available at each point. This turns out to make test writing much easier than if it were an /external DSL/, because the choices are constrained by the objects that you’re working with, i.e., on the DirectBillPaymentPage, the IDE will "tell you" that you can do "groupByInvoice" and "aggregateByItem" by showing those methods as auto-complete options.

 

February 1, 2009

Book Review: “The Art of Lean Software Development”, 1st Edition

Filed under: General Rant, Books

The Art of Lean Software Development, 1st Edition
by Curt Hibbs; Steve Jewett; Mike Sullivan

From O’Reilly Media, Inc.
Published February 2, 2009
ISBN-13: 978-0-596-51731-1
Pages: 144

 
 
I’ve already read James Shore and Shane Warden’s "The Art of Agile Development", and whether you liked it or not (I thought it was good enough to purchase half-a-dozen copies for people in my company), I don’t think you can argue that it’s not comprehensive. "The Art of Agile Development" is definitely from the "here’s what we did in the real world with real businesses" school of books.
 
With that book as a reference point, "The Art of Lean Software Development" sounded very appealing and I had high expectations of learning about using Lean ideas in real-world software development. The books is on the short side, only 144 pages, though this can be a good thing since then there shouldn’t be any filler material (unlike the sell-by-the-pound books). Alas, I was sorely disappointed.
 
The book starts out with the seemingly standard "here’s why software projects fail, here’s how waterfall doesn’t work, and here’s the Agile Manifesto and the typical Agile processes." Maybe I’m jaded, but it’s a somewhat old story by now, no? A bright spot is that they point out how Winston Royce’s paper on Waterfall was misunderstood, misinterpreted, or never really read (since Royce actually rails against the down-flowing waterfall process).
 
Next, the book summarizes the Lean Principles: Value, Value Stream, Flow, Pull, and Perfection. And I do mean summarize: the authors spend about a sentence or two per principle. I would’ve liked some more background here, especially the more about "Value" and the "Value Stream", but they promise the next chapter will apply these to software development.
 
Chapter 2 starts by referencing the Poppendiecks’ books on Lean and Software Development ("Lean Software Development" from 2003 and "Implementing Lean Software Development" from 2006) and summarizes their seven principles, diving deepest into the "Eliminate Waste" principle by mapping the manufacturing lean terms to software development terms, e.g., Overproduction -> Extra Features and Transportation -> Handoffs. The authors then go on for only a few more pages on relating the other principles to the process of software development. The chapter ends with a short comparison of Lean vs. Agile, which the authors feel is mainly due to "the mindset" of Lean, i.e., "the elimination of waste in the context of what the customer values."
 
With the introductory material out of the way, I expected to find out more about how to apply the Lean mindset to software development and was eager to learn some new tools. Here’s where I felt really let down. The next six chapters talk about the Lean Practices (starting at the Zeroth), but honestly, there is nothing new about these practices. The Zeroth Practice is "Source Code Management and Scripted Builds". Does anyone doing commercial software development not use source code management? And scripted builds are nothing new. Practice 1 is "Automated Testing". I don’t think there’s any question that this is a must — mainly the arguments are around do I write the tests first or have I gotten 90% code-coverage, etc. Practice 2 discusses "Continuous Integration", but again, this is nothing new and certainly isn’t exclusively a Lean Practice. Practice 3 is "Less Code", i.e., write less code and you’ll have fewer bugs and the system will be easier to maintain. Yup. I totally agree, been doing things that way for decades.
 
Practice 4 is "Short Iterations", which goes back much further than the "translation" of Lean Manufacturing ideas to Software Development. And here I take issue with the recommendation for iteration length: "the best starting point is in the middle of that range—four weeks": my experience is that shorter iterations, such as two weeks, are much better for teams that are starting in Agile because of the shorter feedback loops and more opportunities for inspecting and adapting the process to the needs of the project and the team. The last is Practice 5: "Customer Participation", which is eXtreme Programming’s On-Site Customer. Nothing new here.
 
At this point, the book hits Chapter 9: "What’s Next", which already sounds like the conclusion and I haven’t learned anything new! It does go on for a little bit about Kaizen and Value Stream Maps, but this should be the meat of the book: show me how it’s been applied to projects. Show me the elements that don’t translate to software development. Show me a real-world Kanban board and not just a pretty Visio picture of some columns with rectangles. How does the Kanban really work? How do I deal with wide variation in the tasks? How do I know when and where to put the buffer queues? This section ends with "Make It Visible". Um, Burn-Down Charts? I’ve been using those for years in Agile. And why do I only get a couple of pages on "Root Cause Analysis (Five Whys)"?
 
Chapter 9 ends with some references to "complementary approaches", and I’m very surprised when the authors state "There is currently a little bit of industry talk about applying ToC and CC to software development, but there are no serious efforts that we are aware of to actually do so." Have they even read David Anderson’s 2003 book "Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results"? It’s actually listed in the "Resources" section — unless the authors don’t consider that book (and the kanbandev and Real Options Yahoo Groups email lists) as a "serious effort".
 
All in all, a most disappointing book and definitely not recommended: it doesn’t provide any real-world project information; the authors don’t seem to have participated in any of the mail lists that discuss Lean and Software Development (a quick Google search doesn’t find anything they’ve written in this area); and ultimately it fails to truly show the difference between the various flavors of Agile and how it’s different from "the mindset" of Lean.
 
I suggest reading the books by the Poppendiecks, the Agile Management book by Anderson, the Scrumban book by Corey Ladas and skipping this one.

January 17, 2009

Follow me on Twitter

Filed under: Rave

Looks like I’ve been doing a lot more Twittering (see http://twitter.com/jitterted) than blogging the last couple of months. One thing I like about Twitter is it allows me to write down short (<=140 chars!) thoughts or ideas that don’t warrant a full blog posting. Now that I’ve "saved up" a bunch of thoughts, I can go and write more about them.

Note that my twitterings (tweets) are 95+% about software, development, agile, etc., and very little "ooh, I just saw a cute puppy" or "I’m hungry" — that’s just not the way I want to use Twitter.

 

December 20, 2008

Kanban Book

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.

 

November 12, 2008

Easing Into Agile - Slides from Silicon Valley Code Camp 2008

Filed under: General Rant

The presentation "slides" are here: http://www.tedmyoung.com/EasingIntoAgile.pdf.

Note that the content is licensed under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

Question, comments, criticism, etc., are always welcome.

November 10, 2008

Two IDEA 8.0 Features Worth the Price to Upgrade

Filed under: General Rant

I don’t know about you, but I’ve got code in my code base that still uses arrays and we need to move them to Lists. Sounds like fun, huh? Well, a new refactoring in IDEA 8.0, Type Migration, is going to help a lot in this task. The other feature that blew me away during the EAP was the Data Flow To This… command, which lets you see how the variable you’re looking at got its value all the way back through the method chains. This is really useful when you’re trying to figure out, say, why the value is null and where it got set that way.

Examples and screenshots on these coming soon. 

IntelliJ IDEA 8.0 Released!

Filed under: General Rant

Yeah, IDEA 8.0 has been out almost a week, but I’ve been so busy with the Code Camp preparations, I didn’t have time to focus on it.

I’ve been using 8.0 since the first Early Access builds, and it’s been a very solid product all the way through. There were some regressions in the way things were "painted" (causing background colors to not work properly in some cases) that I’m betting has to do with the fact that IDEA 8.0 ships with the 1.6u10 release of the Sun Java VM. Those bugs are fixed and I’m happily using 8.0 on its 30-day trial until I get my 7.0 license upgraded. I’m bummed that I didn’t win the JetBrains raffle at the Code Camp, but oh well.

I’ll be posting thoughts and information about the new 8.0 features over the next few weeks. 

Silicon Valley Code Camp 2008 - FEEDBACK

If you attended my "Easing Into Agile" or "Building Better Tests in Java" sessions at the Silicon Valley Code Camp 2008, I’d love to hear any feedback, compliments, constructive criticism, and any questions that you might have thought of. The code camp eval for the Agile session is here: http://tr.im/yqi and the eval for the Builders session is here: http://tr.im/yqm. I also encourage you to leave a comment here if that’s more convenient.

Get free blog up and running in minutes with Blogsome
Theme designed by Jay of onefinejay.com