Interview questions from a local web startup.

What is your ideal next career opportunity? Why?

I’m ready to get back into a product company! I did time on internal products and built one medical device before moving onto contracting. I thought I would like switching customers every few months, but it didn’t work out. So, I’m trying to get back into a product company, preferably, where I’ll get more web experience. I’ve got a lot of ideas about continuous integration/deploy and I work on several related open source projects. I’m excited to learn and apply new techniques and websites are much easier to deploy than medical software!

What is your career ambition?

My ambition is to become a real technical leader. I love learning, experimenting, and turning around and teaching people. I want to teach teams what I know about making software simple, quickly, and with happiness! I’m always inspired by what the guys like Dan North, James Shore, and Arlo Belshee are doing.

What do you hope to learn over the next year? Over the next 5 years? Why?

I want to practice continuous deployment in an agile environment and I believe that I can learn that by deploying websites. I’m convinced that continuous deployment is the next big step towards zero friction software development and will help drive down the risk of delivering software.

In the next five years, I’d like to teach and apply all of my hard-learned practices (TDD, SOLID principles, build scripting, deploy automation, etc) to new teams interested in experiencing an agile transformation. I think the Windows development market, especially in Pittsburgh, needs this!

Please describe your ideal relationship with a supervisor. If possible, give an example of a successful supervisor relationship from your prior career.

An ideal supervisor is invested in the people under her supervision. Of course, they care about the company and are passionate about the industry, but they know that happy people will work to delight the customer and make the best product/experience possible. A good supervisor will cultivate true leaders. You hired us for our experience and temperament, so empower us to lead!

What are your 2-3 greatest accomplishments? Why?

You could argue that my greatest accomplishments were at the medical device company, rescuing the device control project in just under 4 months (after 3 years of failure). But, while that seems like important work, I don’t think it was my best. Those accomplishments got stuck in regulatory process and helped no one for over a year (see more in the next question).

My greatest accomplishments have been my work in open source and community events. I was extremely proud to deliver a CQRS/Event-Sourcing talk to the .NET communities in Pittsburgh, Philadelphia, and Roanoke. I taught people a better way to build systems! I took over maintenance of an open-source library, Albacore, fixed bugs, accepted pull requests, and released new versions. This library is used by thousands of people in their build system every day, think about the effect that it’s had!

What is your greatest disappointment? Why?

My greatest disappointment was the inability to ship the medical device that we rescued. We executed technically well, in fact, at a level we never experienced before. The team was hand-selected and told to do whatever it took to get the product done. It was an exciting time. Until it came to actual ship the thing.

We had a very poor understanding of the regulatory environment and had to stop and return to the beginning to document, test, and “prove” all of the work and theory that went into the operation of the system. It was over a year of slow, arduous work to get the thing approved.

It was on this project that I got into continuous deployment and I wasn’t able to practice it completely because we couldn’t ship one!

What 3 books have had the greatest impact on your life? Please explain.

Oh, it’s so hard to pick just three! Luckily, I keep a reading list with a summary of what was exciting, awesome, or terrible about each book. So, here goes…

The Design of Everyday Things. This was the first book that I read in an effort to enhance my professional skills. At the time, I wrote, “My first design book and there’s not a single sentence about software. Norman really breaks down frustrating design. And what’s more frustrating than unusable software?” I’ll never look at doors the same way again!

The Cognitive Style of PowerPoint. This one changed the way I thought about information design and still affects the way I present information. I wrote, “My earliest foray into presentation zen. Tufte shows that PowerPoint reduces the analytical quality of presentations, corrupts statistical reasoning, and weakens verbal thinking.”

The Art of Agile Development. There’s not much to say here, Shore has influenced everything I do when it comes to creating software… “We refer to this book at work as “the XP book”. Yeah, there are others, but this is the one we read. The explanation of engineering principles are wonderful. I haven’t seen a section like “contraindications” in any other text. It’s advice for when you’re doing it wrong, because often we are.”

Describe one experience where you (individually or with your team) developed, delivered and supported a software product. Give specific examples of challenges that you personally experienced.

I’m going to pick on the medical device rescue project again and, while I mention not shipping for over a year, we did ship to alpha/beta sites, so I’m counting that as support. We had no end of challenges in this project (most of which, we overcame!) and even some advantages that became challenges later.

For example, the team was founded with the directive to just get it done, no matter what. We were exempted from the most frustrating scrum activities that the organization had built up over time. While that let us move quickly, experiment, and learn what worked best for us, we were resented, and even challenged, by the other teams for getting out of it.

We worked with the hardware and manufacturing folks in our NJ office, replacing their internal software team, with whom they had personal and professional relationships. The company said they failed and, as our software uncovered hardware defects, the relationship got worse. We worked very hard to gain the trust of that team and to prove that we were there to help us all succeed and not to make them look bad.

The regulatory process was an after-thought, tacked on at the “end” of development. We went through several heads of the regulatory department and, therefore, several tools, processes, and expectations. We were told to do “x” and don’t ask questions. We didn’t understand the reason and didn’t share a value system with the regulatory group. It was hard, as a technical and analytical group, not to have these answers. It took a long time to get in sync and to understand what was law, what was suggested guidance, and what was someone’s experience (often referred to as “mythology”).

I realize that I haven’t talked about any of the technical challenges, but I think it’s because they weren’t hard (we finished the majority of the features in 4 months). The technical problems are always surmountable, the people problems are much more nuanced and interesting!

In your opinion, what makes a software engineer great?

I think the best way to describe it is with the term “T-shaped.” I believe that you have to be deep in some areas (do you know your framework inside and out? are you a TDD fanatic? do you love studying XP practices?) and broad in many others (are you interested in the psychology of design? do you study other platforms for best practices? do you attend other communities group events?).

I think the engineering team has it very hard. They have to be technically savvy to create new software every day, as the technology, platforms, and standards change. They have to be well educated and love studying and practicing to stay on top trends. And they have to interface with most of the people in and outside of the organization (marketing, design, customers, support).

In your opinion, what makes a software engineering team great?

Trust is at the core of any great team. I’m a Patrick Lencioni fan (of The Five Dysfunctions of a Team and Three Signs of a Miserable Job). You must trust one another to be honest, to be aligned toward the same goal, and to avoid poisonous attitudes, behavior, and competition. Trust leads to authentic relationships inside and outside of work and professional interests, and that’s huge. I’m still very close friends with my best and most trusted teammates from previous positions.

What does your ideal development process look like?

This is a trick question, right? There isn’t one correct, objective process. The people, marketplace, and risks are different everywhere. The ideal “process” is a “meta” process of choosing the right process for right now (whoaaa… inception!). The goal is to become competent at shipping software. Or, as the agile leaders say: Work tiny. Prove it. Get done. Learn constantly. Work together. Tech first.

How does a software company ensure that users have the most satisfying possible experience with their product?

Another tough (trick) question, which I’ll answer with more indirection! I don’t think you (the company, director, or supervisor) should be actively managing “satisfaction”. There must be hundreds of identifiable experiences in your product (daily vs. one-time interactions, in and out-of-app (email) experiences) across many kinds of users (low-tech vs. power users). If you start managing/measuring one metric, you’ll get people gaming it (not out of spite, but out of human-laziness).

Optimize for the passion and happiness of your whole team. Let them get excited about user experience in their own way. Let your designers redesign the signup page until conversion is awesome! Let your engineers built a frictionless deployment system. Let your support team build the monitoring system that anticipates customer problems before they even call in.

The “company,” or more accurately, the business people, can measure the appropriate business aspects: signups, in-app purchases, value to the customer. But, they shouldn’t be micromanaging nitty-gritty technical measurements.

Building Internet-focused (“client”) software is different than developing traditional enterprise desktop or server software. Describe how.

I don’t accept the premise that it’s so different, except for the most trivial applications. The presentation patterns are similar, I’ve done some flavor of MVC/P/VM on mobile devices, desktops, and touch-screen kiosks. The pattern is the same, the details of the framework are different. WPF databinding brings a flavor of HTML templating to the desktop. The lifecycle of a web application view/controller interaction are only technically different than the lifecycle of an enterprise desktop application communicating with a remote service, but the principles are the same.

I see differences in the development process, particularly in release and branch management. Most websites only have one publicly released version (you can release features to slices of users, but usually through feature-toggles, not separate versions). You can more easily commit just to master and branch only long-running features. With a traditional enterprise application, you may maintain a long-lived branch per public release for regulatory or hotfix management.

I think websites get an easy break with continuous deployment, for these reasons! You’re pushing code/configuration to servers that you control and that your users only temporarily connect to. Try doing continuous deployment to desktop systems inside a firewall, inside a hospital, or to occasionally connected devices!

Describe any experience you have using the agile software engineering methodology.

At the medical device company, I was part of several multidisciplinary scrum teams operating within a regulated environment. We practiced a wide range of XP practices, vanilla-scrum activities, and experimented with some lean tools, like Kanban boards.

I can’t possibly do this question justice in text, please ask for more!

Describe how you handle dealing with conflicting priorities or objectives.

I like this question, because I know that “priority” is actually singular, there can be only one! And, luckily, humans are single-task creatures. I can time-slice, bringing up the dreaded context-switching costs and breaking flow.

I may not know which of the many priorities is actually the priority, but there are many interesting ways to find out. We can have a release or sprint planning game. We can lay things out into the “four quadrants” of activity management (important/not-important by urgent/not-urgent). Or I can just use my judgement.

In a different way, I believe that each team should be able to produce software competently, and by this, I mean, quickly and with low risk! We should be able to try all the conflicting priorities in as much time as a “normal” team could produce one.

Describe how you keep your skills and experience “up-to-date”.

(deep breath)… reading blogs, staying on top of trends by using twitter, listening to relevant podcasts, reading books on topics ranging from design to psychology to computation, participating in diverse user groups and professional events like conferences, hackathons, and code retreats, asking and, more importantly, answering questions on stackoverflow, reading and contributing to open source software, teaching and learning from coworkers, keeping in touch with professional colleagues in diverse positions, mentorship w/previous supervisors and/or colleagues.

What do you do when you are “stuck” when solving a problem?

Creating new software every single day in an environment that’s rapidly changing is really hard. Most of the metaphors that compare software to construction are wrong. The writing of the software is entirely a design activity. The computer does the constructing (compilers, hello?). The problems are non-linear! Sometimes you just have to disengage the problem solving part of your brain, turn away from the screen, take a walk, sleep on it, or just take a shower!

As well as do any of the things in the previous question… you never know where that bit of inspiration will come from!