February 23, 2016
General, work
No Comments
A post by Amanda McPherson about her best interviewing tip over on LinkedIn got me thinking about an interview technique I was taught while on the GNOME board many years ago:
Focus on behavior. In jobs related to product management, business development, sales, marketing or communications, you have people who are verbally skilled. Ask them anything and you will likely get a good verbal response, but that doesn’t mean it’s true. Focusing on behavior — how they follow up, how and when they respond to your emails and questions, how they treat you vs others on the team for instance — yields more accurate data of how they will be on a daily basis.
She quotes the story of a Charles Schwab executive who would take candidates to breakfast interviews, and ask the restaurant to mix up the order deliberately – just to see how they would react to the stressful event.
The technique, which was taught to the GNOME board by Jonathan Blandford, goes one step further. The principle of targeted selection is that the best predictor of future behaviour is past behaviour. So if you are hiring someone to manage a team, ask about a time they were a manager in the past. If you need someone who can learn quickly in a new and fast moving domain, ask them about a time they were in a similar situation. Then dig deep for details – what did they do, how did they interact with others, how effective was the outcome of the situation?
As an example: if you want to know how someone reacts under pressure, ask about a time that they were working on a project that ran late. Ask them to describe the moment when they realised that they were not going to make the release date on time, on quality, as planned. Then ask how they reacted – did they reduce scope, fight for a schedule extension, add people, get everyone working weekends? Was there a post mortem after the project shipped? Who took the lead on that? How were the lessons applied in the next project? You can use a line of questioning like this to identify the people who will power through obstacles, regardless of the cost; people who are more consensual, but may lack decisiveness; people who seek help versus taking on too much burden. This type of insight is gold-dust when you are evaluating a candidate.
Some other ideas for questions:
- If you want someone who can ramp up quickly in a new area, ask about the last technology they discovered and became expert on. Then ask about the early days – was their instinct to read blogs, books, tutorials? To follow practical labs? To pay for training? Did they seek out people to ask questions and share knowledge? How did they evaluate where they were in the learning process? Have they stayed active and learning, or did they stop once they had enough knowledge to do the job? There is no right answer, but the approach they took will give you an idea of how they would attack a similar challenge in the future.
- If inter-personal relationships are key to success in the job, dig into a time they had a significant disagreement (with a boss, with a subordinate, with a colleague, with someone in a community project) – something meaningful and important to them. How did they go about arguing their case? Was winning more important than getting a good solution? How important was the relationship to them?
- If organisational skills are key: ask for an example of a time when they had to clean up after someone else. How did they go about draining the swamp? What do they say about the former organiser? How did they balance organising the existing system with allowing people to interact with the system and continue doing their jobs?
It isn’t just prospective employers who can use this technique to have better interviews. For candidates, this method can be awesome to allow you to prepare and take ownership of an interview. Look at the job requirements and required experience. When were you in a situation when you got to show the skills required? What were your actions, and what were the results?You can tell a story about your experience that hits all of the job requirements, even if your interviewer is not asking questions about it.
Go one step further: interview your interviewer! Think about the situations in the past where you have been successful and unsuccessful, and come up with your requirements – take that knowledge into the interview, and ask questions to check whether the position is a good match for you. Interviews are a two-way street, and you are interviewing the company as much as they are interviewing you. Ask interviewers when they were confronted with certain situations, and dig into their experiences as employees of the company. Is this a company that expects you to work weekends to meet unrealistic deadlines? Are you thrown a life buoy and expected to sink or swim? Is there a strict hierarchical structure, or are everyone’s perspectives heard and respected? Is there mobility within the company, or do people hit a developmental ceiling?
The great thing about this line of questioning is that it is not accessing the hypothetical side of the brain – you are not getting the idealised “I would…” answer where infinite time and resources, and everyone’s buy-in can be assumed. You are accessing memory banks, and the more details you get, the closer you get to the truth of how the person reacts. Especially great for providing insights are trade-offs, where there is no right answer – when two people want different things and you are there to adjudicate or be the intermediary, when you have to choose between two top priorities, when you only have enough time to do one of the three things that are important. In situations like that, you can really get insight into the approach and mentality of candidates, and also help candidates judge the culture and priorities of a company.
November 24, 2015
General
No Comments
We extended the deadline for the SDN/NFV DevRoom at FOSDEM to Wednesday, November 25th recently – and we now have the makings of a great line-up!
To date, I have received proposals about open source VNFs, dataplane acceleration and accelerated virtual switching, an overview of routing on the internet that looks fascinating, open switch design and operating systems, traffic generation and testing, and network overlays.
I am still interested in having a few more NFV focussed presentations, and one or two additional SDN controller projects – and any other topics you might think would tickle our fancy! Just over 24 hours until the deadline.
April 17, 2014
General
No Comments
I realised recently that most of my writing has been of the 140 character format recently…. I plan to rectify this, starting today.
February 11, 2014
General
1 Comment
There are times in a long career when you have to turn your back on what’s gone before. In work, this is easy. People stop giving you a paycheck, you stop turning up to work. And yet, some of my best friends are people I worked with 10 years ago.
In open source, it’s harder. You build relationships, you grow emotional attachments to projects you work on.
When life moves you on from a project, you stay subscribed to mailing lists, you add mail filters to move them to a folder you read less and less frequently.
When you hit a threshold where you no longer consider yourself a developer or contributor, you keep watching from afar, and when the project takes a direction you disagree with, that you know you would have argued against, you feel a little sadness.
After a while, this build-up of guilt weighs you down. But letting go is hard to do.
I’m learning. Trying to get better at letting go. The next generation needs to find their own way. It’s liberating and saddening in equal measure. Old friends: we will stay friends, but I need to trust you to make your own way.
June 8, 2013
freesoftware, General, openstack, red hat, work
1 Comment
Over at community.redhat.com, the Red Hat community blog, I have posted an article detailing some of the value I see to customers of companies who support and build on free software. The article is basically notes from a presentation I will be giving next Wednesday at the Red Hat Summit, “Community Catalysts: The Value of Open Source Community Development”. The problem statement?
It’s not always obvious, however, what the value of that is to our customers. The four freedoms of the free software definition which personify open source software – the freedom to use, study, modify and share modified copies of the software – at first glance appear to benefit only participants in open source communities. If you are a customer of a company like Red Hat, does it really matter that you have access to the source code, or that you can share the software with others? Aren’t customers, in some sense, paying us to “just take care of all of that stuff?”
This line of thought is not original, but it’s one I’ve had for a long time – and others such as Simon Phipps have given voice to similar insights in the past. Hopefully I can give it a fresh treatment for Red Hat Summit attendees next week!
April 26, 2013
General
No Comments
1991
You: “I’d like to install a file server for the LAN – can I have the root password for the server, please”
Admin: “You’re kidding, right? Submit a ticket, we’ll install it when we get around to it”
crickets
1996
You: “I installed a Samba file server for the LAN on my own Linux machine”
Admin: “Gah! You messed up my workgroup. What happens when you turn it off? Bloody amateurs…”
2000
You: “I’d like to install a bug tracker for the dev team”
Admin: “The existing servers are overloaded – you’ll need a hardware req. Lodge a ticket, and get management approval first.”
2005
You: “I’d like to install a bug tracker for the dev team”
Admin: “I’ll create a VM for you to use. Lodge a ticket”
2013
You: “I’d like to install a bug tracker for the dev team”
Admin: “You have a self-service account on OpenStack, don’t you? What are you talking to me for?”
January 18, 2013
General
1 Comment
For anyone who saw the recent launch of the new oVirt website a while back and was wondering how we could make such an attractive theme and lay-out for a MediaWiki wiki, wonder no more. In fact, you don’t even have to be jealous! Because the theme, called Strapping, so called because it’s based on the Bootstrap web framework, has just been published by my colleague Garrett on GitHub.
Kudos to Garrett, who did amazing work on this theme to make it as beautiful and reusable as possible, and I’m looking forward to using it for other websites in the near future. And so can you!
November 27, 2012
General, marketing
4 Comments
Via Simon Phipps, I discovered PlayTerm this morning. You can record and play back terminal sessions, which allow you to show commands and their expected output, played at typed speed. This may be the greatest invention since screencasts.
September 14, 2012
community, freesoftware, General
13 Comments
Speed bump ahead!
This week I was reminded that the first step in an Open Source project is often the hardest. We’ve been using MediaWiki for a project at work, with the “ConfirmAccount” extension to deal with spammers – a very nice extension indeed! It adds account creation requests to a queue where they can be handled by members of the bureaucrat group.
We had one wishlist item. We wanted to have a notification email sent out to every member of the group when a new request was received. There is an existing feature to send a notification email to a configurable email address, but not to the whole bureaucrat group.
So I said to myself, how hard can that be? And I rolled up my sleeves and set aside an afternoon to make the change, and submit it upstream. After a few false-starts which were nothing to do with MediaWiki, I got down to it.
First task: Upgrade to the latest version of MediaWiki – the version on Fedora 17 is MediaWiki 1.16.5, and the latest stable version is 1.19.2. So I download the latest version, and follow the upgrade instructions to over-write the system MediaWiki install in /usr/share/mediawiki with the upstream version. Unfortunately, the way that $IP (the Install Path) is set changed in version 1.17, in a way that took a little time to work around.
Once that was done, I downloaded the HEAD of the trunk branch from SVN which was linked from the old version of the extension home page, and got the extension working. That needed a few additional modules, and some configuration to get the email notifications working locally, but eventually, I was good to go.
I got to work making my change. It took a while, but once I figured out how to turn on debugging and the general idiom for database queries, it was easy enough. After a couple of hours hacking and testing, I was happy with the result.
The first date
I headed back to the extension home page to figure out how to submit a patch. At the same time, out of habit, I joined the project IRC channel, #mediawiki on Freenode, reasoning that if I got lost I could ask for help there. No indication on the Extension page, but a web search showed me that MediaWiki uses Bugzilla. So I registered for Yet Another Bugzilla Account, and confirmed my email address a few minutes later. Then I created a bug on Bugzilla, and attached my patch to the report.
Simultaneously, on IRC, I was asking for help and was told by a very nice community guy called Dereckson that the preferred way to submit patches was through Gerrit. It turned out that the extension home page should have been pointing to the more recent Git repository all along, and I had been developing against the wrong version of MediaWiki. Dereckson updated the extension page with the right repository information as soon as he discovered it hadn’t been updated before. No big deal, I cloned the Git repository, and tried to apply the patch from svn to git. Unfortunately, it didn’t work – some other changes related to translatable strings had changed code in the same area, and I had to re-do the change, but that was pretty easy.
I did try to submit a patch by following the procedure in the git workflow document, but without an account on Gerrit it didn’t work, of course. Dereckson convinced me to apply to developer access. After some initial resistance, because I really didn’t want to be a MediaWiki developer just to submit a drive-by patch, I requested developer access with the comment “I just wanted to submit one patch to an extension I use, Extension:ConfirmAccount.” Half an hour later, jeremyb approved my request with the comment “That’s what you think now!” 🙂
Then I went to the documentation on getting access and followed the instructions there until I was directed to upload my ssh key to labs and found I did not have access to that resource. Thanks again to Dereckson (once more to the rescue!) on IRC, I found my way to getting set up for git and Gerrit, and got an SSH key set up for Gerrit. Then I went back to the instructions for submitting a patch and a quick “git review” later, I had submitted my first patch ever to Gerrit.
Jumping through hoops (CC by-sa, rwp-roger@flickr)
Pretty quickly, the first couple of reviews came in. First comment: “There’s some whitespace issues here.” Gee, thanks. Second comment, from Dereckson (again!) started with a “Thank you”, said the idea was a good one, and then gave me an example of the project norms for commit comments, and made one comment on the code suggesting I use an option.
As a first time user of Gerrit, I noticed a few issues with it for newbies. It’s not at all clear to me how to distinguish “important” commenters from trivial-to-change things like whitespace issues. It’s also not clear whether a -1 blocks a commit, or how to have a discussion with someone about the approach taken in a patch. Also, it was unclear what the suggested way to update a patch was and propose a new, improved version. My first try, I made some changes, committed them into a new revision on my local branch, and pushed the lot for review (normal git workflow, I daresay). Unfortunately, this was not correct. I ended up squashing the two commits with a “rebase -i”, and since then I have been using “commit –amend”.
After a few more rounds of comments (another whitespace comment, and a suggestion to avoid hard-coding the group name), I am currently on the 5th patchset, which I think does what it says it should, and will pass review muster, when someone gets around to reviewing it. I’ve been told that the review time for a small patch like this can be up to 5 or 10 days, and I don’t know exactly how I know that the process is over and it’s good to commit.
Sunk costs
The end result is that for a small change to a fairly simple MediaWiki extension, I spent about 2 hours coding, and about 4 or 5 hours (a full afternoon) going through the various hoops involved in submitting the change for review upstream.
I’m aware that this is a one-off cost – that now that I have a Bugzilla account, and a git and Gerrit account, it will be easier next time. Now that I have spent the time reading the MediaWiki coding conventions, git workflow, and have spent time understanding how to use Gerrit, I won’t have these issues again. The next patch will only take a few minutes to submit, and I won’t be wondering if I did something wrong if I don’t get a review in the first 10 minutes.
But along with some installation and firewall issues, I ended up spending slightly more than a full day on this. In hindsight, I’m saying to myself “was it really worth a full day of work to avoid maintaining this 20 line patch over time?”
I think it’s important that projects make newcomers jump through some hoops when joining your project – the tools you use and the community processes you follow are an important part of your culture. Sometimes, however, the initial investment that you have to put into the first-time use of a tool – the investment that regular contributors never see any more – is big.
If you’ve never used Bugzilla, git, Gerrit, or SSH, how long would it take you to submit a first patch to a project? How many hurdles does someone have to jump through to submit a patch for your project? Is there a way to ease people into it? I could imagine something like an email based process for newcomers, and only after they’ve made a few contributions, insist that all of the community’s preferred tools and processes be used. Or having true single sign-on, where you have only one account-creation process for all of your interactions with the project, so that you don’t end up creating a wiki account, a Bugzilla account, a Labs account and configuring a Gerrit account.
I want to make clear – I am not picking on MediaWiki here. I rate the project well above average in the speed and friendliness with which I was helped at every turn. But they, like every project, have adopted tools to make it easier for regular contributors, and to help ensure that no patches get dropped on the floor because of poor processes. Here’s the $64,000 question: are the tools and processes which make it easier for regular contributors making it harder for first-time contributors?
