Interview Questions – One of my Favourites

Being a part of an interview can be a daunting task. For some people it’s a painful experience, for others it’s a thrill. I remember being in interviews that I didn’t want to end, and in others where I felt like banging my head against the desk. Assuming the interview is going well, there’s this one question that I always like to bring up.

If I’m being interviewed I like to ask:

If I do everything right by you, and I am a top performer, where can I be in two years’ time?

I need to know what the strategic plan is for the company. I want to know what the growth opportunities are. Depending on the passion and the clarity of the response I can also draw other conclusions or come up with follow up questions.

The reverse is also true. When I conduct interviews (and I’ve done hundreds in my career so far) I like to ask:

If we do everything right by you, and we support your growth, where do you see yourself in two years’ time?

I have heard some amazing answers, ranging from: “I’ve left the country“, “I’m running my own company“, “I’m the best mobile developer in New Zealand“, all the way to “I have taken your job“.

If you decide to start asking this question in your interviews (whichever side of the table you’ll find yourself), I encourage you to follow up during your first and second performance reviews…

So why don’t you take a moment and ask yourself: if you are honest with yourself, where do you want to be in two years’ time? If you’re feeling brave, tweet me your response.

p.s. this is a good opportunity for me to recommend this book: The Manager’s Book of Questions by John Kador. It’s a fairly old book, but because it doesn’t focus on one particular technology, it asks various categories of questions (from icebreakers to competency), and it doesn’t seek provide the answers, I still find it very relevant.

Clean Code – Mandatory Reading for Developers

All developers should need to read Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin.

If time prevents you from reading an entire book, then at least read this chapter: “17. Smells and Heuristics”.

One of my favourite bits of advice (that actually comes up a lot in discussions with the developers around me) is captured in this paragraph:

There is hardly anything more abominable than a dangling false argument at the end of a function call. What does it mean? What would it change if it were true? Not only is the purpose of a selector argument difficult to remember, each selector argument combines many functions into one. Selector arguments are just a lazy way to avoid splitting a large function into several smaller functions.

The book is filled with code examples, describes concepts rather than programming language idiosyncrasies, and is useful even for seasoned programmers.

Whatever language you code in (today), this book is likely to become a fixture on your desk for a very long time after you’ve finished reading it. Get the paperback version, and fill it with colourful post it notes.

Cocoaheads Wellington – Kick Off

I’m proud to announce the formation of Cocoaheads Wellington. For those who are not aware, Cocoaheads is an international Club for Cocoa (iOS & Mac) developers and designers.

The gatherings happen every 2nd Thursday of the month, from 7pm to 9pm. They are usually followed by a trip to a nearby restaurant or pub.

The first meeting will take place on the 12th of February at the Trade Me offices in Wellington. If you’re a Cocoa Dev / Designer then you should confirm your attendance here.

I intend to outsource the location. I’m currently hoping to convince one of the local Universities to host, but maybe another Wellington based organisation would be keen to put their hand up? If you know of any potential venues then please reach me via Twitter.

In terms of structure, I will propose when we gather that we break up the agenda in 3 parts:

  1. Follow up on the previous session
  2. Presentations (five to ten minutes each) on pre-agreed topics
  3. Q&A, tips or tricks, current issues or problems to ask the audience about

If you’re passionate about iOS or the Mac, you are keen to share your knowledge or learn from others, you live and breathe development or design, then I hope to see you there!

 

Wellington Android Meetup – The first edition

It’s true. The Android developer community in Wellington is strong and mature, if tonight’s first Android Meetup is anything to go by.

The setup

Android Meetup Wellington

Android Meetup Attendees

Just over 30 people took part in the first (of hopefully many more to come) Meetup that I was proud to facilitate and host together with the rest of the Trade Me Mobile team at our Market Lane office. We will try to make sure this becomes a regular event, especially now that the GDG Wellington was created.

The turn out was fantastic (we had to supplement the available slots at the last-minute). The show of hands confirmed that the majority of attendees were developers but we also had designers, testers and business folk. This diversity definitely helped during the Q&A sessions…

The talks

The theme of the evening was Material Design and the agenda was simple. I gave a quick intro, then we kicked off properly with a presentation by Matthew Shearer (our Lead Android developer) about the challenges that we face at Trade Me when tacking Material Design in our app, followed by an interesting Q&A, then the spotlight was given to Glenn Parker (Xero) who showed off a few ideas/early mocks for their product. Other people in the room mentioned that Material Design was high up on their TODO list but they just haven’t gotten around to it.

The evening continued with food and drinks followed by an open discussion around the future of this group.

Where to from here?

We are very keen for this event to not be owned by one organisation. Instead, we’ll aim to put in place a roster so that other teams around town can host it and offer more diversity not just in terms of venues but also in terms of hours. We even floated the idea of doing it over lunch sometime to cater for those with young kids or who have engagements in the evenings…

Happiness Survey

Happiness Survey

As expected, the attendees behaved really well and communicated freely. There was no awkward job/hiring talk, nor any immature comments of any kind.

Toward the end of the event we brainstormed a few ideas for future sessions. We’ll vote on the group and we will decide what we will talk about next time (late January or early February). As this picture shows, people found the event valuable for the time they invested (2 hours) so I will call it a success!

Team vs Group – Some differences

A bunch of people that push each other forward and work together for a common goal form a team. A number of people who work for the same organisation but have individual goals belong to a group. One of the biggest differences between a team and a group is that a team’s achievements always outweighs the sum of all the individuals’ accomplishments.

To better explain my point of view, I will break down my definition of a successful team into the categories below and close with what I believe the manager’s role should be.

Motivation: Purpose, Accountability, and Goals

People in a group are very likely to be sold a goal. Depending on their professionalism, they will push themselves to achieve great outcomes and they will strive to be honest. Any failures or imperfections are forgettable and are perceived to be short-term. Accountability applies at personal level. In this context, the motivation for an individual is most often extrinsic.

In a team, the goals are set together through discussions, planning, and by sharing a common definition of success. The team has personality. Since the goal is shared, they push each other forward and hold each other accountable. Due to the fact that they collaborate closely they often end up raising the bar of expectations for each other in order to deliver better results at both personal and team level. Team players are intrinsically motivated.

Collaboration and Roles

Group

In a group, individuals are less likely to contribute to other skills

In a work group, people share information, they are respectful with one another, and sometimes even behave in a formal way. Meetings sometimes turn into status reporting. Peoples’ ideas don’t always get challenged or augmented. There’s hardly ever any work done outside one’s area of expertise. The skills overlap is kept to a minimum, almost as a sign of  respect. Personal development is determined by one’s own desire to better themselves rather than as a need to fill a gap. A designer is always a designer and a tester is always a tester. The Gantt1 chart for how a project runs is clear-cut. Task B always follows task A and never comes after task C.

Team

In a team, individuals tend to push their peers forward

In a team, the collaboration is not just close, but from the outside it may even look chaotic. There is energy and people often venture beyond the limit of their skill. Developers and testers may end up sketching design approaches. Designers may roll up their sleeves and help with testing. Product owners will join the designers in user testing. Personal development is often done in a way that completes the collective knowledge. A tester may learn to use prototyping tools, while a designer may learn how to work with development tools. Each person may wear the hat of any of the other team mates and may jump in when their help is required. In a Team, tasks A,B, and C may take place at the same time and make a project manager’s life a living hell.

The Manager’s role

In a work group, the manager is almost a dictator (sets the goals, measures progress, and is the only one who can push a member’s limits). In a team, the manager is merely a guide and a facilitator.

All teams start off as a group. It’s a manager’s job to create an environment where people:

  • feel safe
  • speak freely
  • are comfortable with themselves and can be genuine

so that they can discover each other’s strengths, accept the weaknesses, and, over time, build trust.

1 Disclosure: I really don’t believe in Gantt charts.

Sharing Information – My basic principles

As a team leader, I sometimes find myself in a situation where I have to communicate a decision to my team. Here are some key principles that I a guide myself by when I do this.

Do it as early as it makes sense

Timing is one of the most important things to me. If my team find out about the “news” from somewhere else, their trust in me is likely to be shaken. I am there to look after them and to be their voice in the conversations that have an impact on them. The sooner I can do that, the more I can help them.

Give a quick rundown of what will be covered

At the beginning of the discussion I try to clarify what I will talk about. This provides not just structure, but it may prevent questions that would be answered anyway. At the same time, it enables everyone to write down any questions that I may have overlooked in my FAQ.

Ideally, the agenda should be sent with the meeting invite, but sometimes this is just not possible.

Provide context

The reality is that not everyone reads their emails. If these emails contain business speak, are too lengthy, or come from a source that is too far away in the organisation, then it’s possible that people will just skim the message and not retain too much information.

The first part of the discussion should definitely include a quick recap of what has been going on, to bring everyone up to speed.

Stay honest, genuine, natural

I have seen so many people try to become somebody they are not during a presentation. Their pitch or tone would change. Their body language would be awkward. Their hand gestures would be unnatural. I try my hardest not to be one of these people.

Be yourself. Everyone else is taken.

I feel like being genuine helps reassure people that I am being honest. Even if the point of the meeting is to “sell” to the team something that they might not be too happy about, it’s still important that my tone is affiliative.

Give just the right amount of information

One very important aspect is finding the right balance between getting lost in the details (overwhelming the team with too much information) and being too vague about what the decision really entails.

Go through a FAQ

I try to think ahead of the questions that the team might have. Putting myself in their shoes is good for several reasons:

  • helps me prepare for the meeting
  • contributes to the decision of how much should be communicated
  • keeps me honest
  • prevents the piling up of answers such as “I don’t know”, and “I’ll get back to you”

Take questions

I am a strong believer in the power of an honest “I don’t know”. Realistically, if the truth is that I don’t know, then anything else I would say is BS. I respect my team too much to reply with a political, or vague answer. It’s also very likely that the answer will be important to me too.

Thank and close

When closing, it’s important to remind people that the communication channel is still open. Some people are introverts, or simply not comfortable asking questions in front of their peers. Others prefer to communicate in writing. Their voices are equally important therefore they need to know that they can follow-up with me.