admin

Interview Questions You Should Ask

by

On the whole, I’ve been fairly successful (or lucky) with interviews in my career. But I must admit that even though I’ve tended to be able to correctly answer most if not all of the interviewer’s questions, I don’t always ask them enough of the right questions. Asking the right questions is especially important if it’s your first developer position after finishing College/University, because the first few years could shape your career for the next ten. I mentioned the importance of this in a previous post, Software Development Must Haves.

The questions you forget to ask when you are interviewing for a job, but wish you had asked after taking the job by Bruce Eckel. It’s worth reading the range of extra questions that were posted in the comments section.

Top 10 Questions to Ask in an Interview, by Robin Ryan: This is a more general guide than just IT. I liked this quote: “An HR Director for Microsoft added: ‘Frequently the candidate, ill-prepared, searches his mind for just anything to ask. That person appears dumb, or uninterested, causing me to question what kind of employee they’d be.’”

Microsoft used to be big on lateral thinking / puzzle type interview questions as described in the book “How would you move Mount Fuji” by William Poundstone. Many of these are example of the “back of the envelope” technique (estimating from imprecise or missing information) which seems to be less frequently taught and practiced, such as “How many Piano Tuners are there in the U.S”. I’m not sure that these types of questions have ever been particularly relevant as interview questions (since the answers can be rote learned) but they can be amusing and good one-off, lateral thinking exercises: http://www.softwareinterview.com/

The Guerrilla Guide to Interviewing (version 3.0) by Joel Spolsky. Joel admits that he is fairly hard nosed about the interviewing process, “It’s because it is much, much better to reject a good candidate than to accept a bad candidate.” Joel suggests that only 2 things matter in a candidate: “In principle, it’s simple. You’re looking for people who are (1) Smart, and (2) Get things done.” I like Joel’s reference to the ‘hard part’ where he asks questions about recursion and pointers: “Sadly, despite the fact that I think that all good programmers should be able to handle recursion and pointers, and that this is an excellent way to tell if someone is a good programmer, the truth is that these days, programming languages have almost completely made that specific art unnecessary.” Whilst tutoring first year University students, I remember this was the ‘plateau’ that they had to get over in order to progress to the next level.

Scott Hanselman (and his clone army, ahem!) originally posted this list of questions aimed at ASP.NET developers. After a barrage of comments, he followed up with What Great .NET Developers Ought to Know, which resulted in a wide spectrum of responses ranging from people saying it was just a list of trivia, to those who basically thought “Ya, those are good. I’d probably have to look a few up.” If you can answer every single question correctly without looking anything up then you’re doing OK! Scott makes the point that he isn’t trying to reduce an interview to a set of trivia questions, and Joel Spolsky doen’t like these type of questions at all: “Remember, smart does not mean ‘knows the answer to trivia questions.’”

Interviewing Web Developers – 20 Good Questions to Ask: one of two of these questions are probably more useful than others.

To end this post, here is a little light programmer relief (or how to gather requirements): Stupid Interview Questions.

And how could I forget the Daily WTF (you have to read these!): Tales from the Interview, Security by Insanity (this is my all time favorite), Tales From The Interview: A Perfect Ten, The Abstract Candidate

Proudly Serving My Corporate Masters (Book Review)

by

I’ve just finished reading “Proudly Serving my Corporate Masters: What I learned in Ten Years as a Microsoft programmer” by Adam Barr. I saw this book mentioned on Joel Spolsky’s site (at least I think that’s where I saw it), and being an avid Microsoft watcher I just had to read it. It’s essentially a historical recount of the early to middle era of personal computing and the rise of the PC, interwoven with Adam’s ten years at Microsoft (1990 – 2000). It gives a fascinating insight into the work culture at Microsoft; some of Adam’s interviewer stories are excellent.
I found some parts of the book extremely interesting, others not so, possibly because they explain things obvious to a developer. If you read this along side other accounts (such as “Microsoft Secrets” by Cusumano and Selby), there seems to be something missing, something I couldn’t quite put my finger on. The prose does not always flow smoothly, but despite this it is was worth reading, especially if you’re forty-something and still remember 4.77MHz CPUs, the Z80, Amigas, CP/M and those rather large floppies… One thing this book does well, is to put into perspective how easy and pervasive internet access has become compared to the pre-internet, BBS days.
As an aside, Adam rejoined Micosoft in 2003, and as far as I know he is still there. You can read his blog here.

.NET Framework Design Guidelines (Book Review)

by

I believe that good technical books fall roughly into 3 categories:

  1. Required reading now but throwaway later: these books go out of date quickly (for instance, that thick copy of plain ASP 3.0, which is now almost completely useless!)
  2. Essential, technology agnostic, lifespan of more than 10 years: containing advice which applies across the board regardless of technology, language or version. These are often process related books. Examples of books in this category are “Code Complete”, and the excellent, recently released “Head First OO A & D” (review to follow shortly).
  3. Essential, technology specific, lifespan hard to measure due to possibility of rapid technology shifts: vital books targeted at some specific technology or language.

The Framework Design Guidelines by Brad Abrams and Krzysztof Cwalina falls mainly into the last category, but also overlaps somewhat with the second.


Who should read this book?

Architects, API and Framework designers, lead developers, junior developers who want to be senior developers(!). Basically, anyone who is designing frameworks or writing code targeting the .NET framework.

The book is divided into 9 chapters and 3 appendices. The guidelines are presented in 4 major forms: Do, Consider, Avoid and Do Not. The authors choose a single language for the examples (which are in C#), which rather being a snub to VB.NET developers is rather more of a complement, as they mention they wanted the book to appeal to the widest audience. A DVD is also included containing several hours of video presentations.

This book represents the condensed wisdom and best practices of literally hundreds of developers, and a number of well known and respected, industry heavyweights have annotated the book, providing discussion and reasoning behind the guidelines.

1. Introduction
This chapter is a brief introduction and discusses the qualities of a well designed framework and the philosophy behind the design. In summary, frameworks are: simple, expensive, full of trade-offs, borrow from previous designs, are designed to evolve, are integrated and last but not least, are consistent.

2. Framework Design Fundamentals
Offers principles and guidelines central to framework design. Talks about scenario-driven design (very similar to TDD), having a low barrier to entry, self documenting wherever possible, the principle of layered architecture, API usability studies.

3. Naming Guidelines
Consistent and accurate naming is an essential principle of designing and writing all code. Krzysztof writes: “The team that develops the .NET Framework Base Class Library spends an enormous amount of time on naming, and considers it to be a crucial part of framework development.” As a consultant, poor method naming is something I see often. As Steven Clarke notes, methods should be named according to what they do, not according to some implementation detail.

4. Type Design Guidelines
This chapter provides general guidelines for the design of types and covers some of the associated subtleties and tradeoffs. This is a heavily annotated chapter, brimming with excellent advice.

5. Member Design
This is one of the slightly longer chapters (57 pages), and follows on from chapter 4, covering basic guidelines that should be followed when designing members of any type. It covers the design of properties, constructors, events, fields, operator overloads, and parameters. I seem to learn something new each time I re-read this and the preceding chapter.

6. Designing for Extensibility
How do you ensure that your framework will be extensible and stand the test of time? This chapter covers unsealed classes, protected members, events and callbacks, virtual members and abstractions. The annotations in this chapter contain several gems of advice, including determining the trade off of extensibility versus performance and some of the subtleties of creating types with virtual members.

7. Exceptions
This chapter is surely the definitive reference for exception handling. It covers the reasoning and benefits behind using exceptions and the best practices in creating and using them within frameworks. Required reading for all developers. [David M Kean posted excellent advice on which exceptions to raise here.]

8. Usage Guidelines
This chapter covers guidelines for the use of common types in publicly accessible APIs, implementing common interfaces and extending common base classes.

9. Common Design Patterns
Chapter 9 does not cover the subject of design patterns in general; rather it discusses a limited set of patterns that are frequently used in the .NET framework.

Conclusion
There is little doubt that a few paragraphs can adequately capture what is contained in the Framework Design Guidelines, or the amount of cumulative effort that has gone into producing this distilled wisdom. If you are a serious .NET developer then you should definitely have access to a copy of this must-read book.

My favourite quotes from the book:
“I have always felt that a key characteristic of a framework must be consistency”, Anders Hejlsberg in the foreword.

“Frameworks must be designed starting from a set of usage scenarios and code samples implementing these scenarios.”

Be Your Own Client

by

Don Box posted that Chris Sells has long been an advocate of ‘Be your own client’.

This approach is not just suited for API design, but for just about any design task, especially user interaction.

Great CSS Techniques

by

I recently purchased “The Zen of CSS Design” by Dave Shea and Molly Holzschlag and I would highly recommend it to any web designers or graphic artists working in the area of web design. You can visit the accompanying site CSS Zen Garden which is “A demonstration of what can be accomplished visually through CSS-based design”, and tries to address “the need for CSS to be taken sereiously by graphic artists.”

I also came across this link to a collection of excellent CSS techniques to solve common design tasks. Well worth book-marking: 53 CSS-Techniques You Couldn’t Live Without

If you are interested in this topic you should check out the recently released CSS Control Adaptor Toolkit from Microsoft, which basically enables ASP.NET 2.0 controls, which normally render as HTML markup, to be emitted as pure CSS based output. Scott Guthrie has a quick introduction to what they are and how they work here.

UPDATED: I also came across the CSS Handbook site. Also, check out this CSS cheat sheet.

For discussion on the pros and cons of Table versus CSS layout see Bill Merikallio and Adam Pratt’s Why tables for layout is stupid. There’s a more balanced look at the two approaches at Tables vs. CSS: PROS and CONS. (saw this via Scott Mitchell over at 4GuysFromRolla)