Category: Team

Interview questions should be presenting your domain!

You need someone, and you had spent enough time on the job spec, to identify the details of the practices/skillset you need. Either those skillset matches what you are doing right doing, or what you want to achieve. In this blog, I will go a bit deep inside to show a more deep insight to the both sides’ feelings.

Matching is a word I use for the technology knowledge and practice knowledge matching.

Knowing X,Y technologies/languages/platforms does not necessarily that person can fit into a set of software development practices, vice versa works true also.
A. If you are a market leader/first implementer technology company
If you want a .NET developer, implementing TDD; and all the interview went theoritical concept of talking, probably you have missed a couple of things during the way

You might chance of getting the right person that could fit in, but you were not aware of it…

Let’s say you are asking the candidate to write a piece of code to calculate 5! and s/he writes it. So was that all about? Writing a recursive function to calculate 5 factorial. This is the first homework/example that an undergraduate/high school level person can answer. And believe it does not tell anything about the candidate [unless the candidate takes it seriously and writes a framework for it.]

It should not be set of questions because some people are selling them, writing books, or Scott Hanselmann listed, actually not someone else’s question, it should presenting your domain, your own challenges!

Please do not ask/expect for output caching as a response to “if a page is getting lots of hits…” Ask types of caching and when to use which …

You have adversited the skillsets your team has, and the practices those you are following [either with best practices/or not].

Markhneedham argues that if you are implementing pair programming, why not you have pair-programmed interview?

I will keep the same argument, and continue:

– If you are/want implementing TDD, why not ask the developer candidate to write TDD tests beforehand the code. If you are insisting on 5! Give three pages of blank papers, and see the talent there!

– If you want to see how experienced the developer is, like how he/she can cover the code,

Ask to write some unit tests, if not all, ask her/him to list the tests s/he would do.

B. If you have one client on a specific industry or you are the enterprise company dealing with only one industry:

If you want to see how experienced on that domain/industry, ask an existing project and see how he/she would think about it. Do not ask 5!, unless you are doing lots of recursive functions, functional programming. Let’s say you are in retail, ask about how a checkout can work, how the delivery address can work best with sessions objects, or product page can benefit from new technologies like silverlight/flash, does s/he has any experience on those domains, and what does s/he thinks…

– For more senior positions, ask about the architecture for your latest project. Which patterns could be used to start a nice discussion to see the depth.

You may not need depth, the people asking questions may not be interested in details and whys, but after a fixed keyword to hear, who will stop listening after they catch that.

And HR can have hours of competency tests similar to GRE/GMAT/Belbin questions on top of that, so without seeing you, they will judge you with you test results…

I tried to tell the points where you should stay away…

Agree to Agree

Thanks to LondonGeekNightsat Thoughtworks yesterday evening, I had the chance to enjoy Pat Kua and Liv Wild, talking about the “conflicts” happening during the projects, and how to solidify, materialise these soft issues.
They have done a fantastic presentation, and obviously good preparation.
The bits I found quite useful are :
– use a structure before starting conversation:
ORID [1.Objective, 2.Reflective, 3.Interpretive, 4.Decisional]
– Importance of how you give/receive feedback and preparation for this.
– Rituals [having something every week where you can talk anything but work, teas, lunches]
– Doing proper/regular Agile Retrorespectives
[technical and personal agile retrorespectives] and a book suggestion
-Using six thinking hats while doing retrorespectives
-Team disruption, changing members
-Being explicit when you are playing the devil’s advocate.
On my side,
The conflict starts when both side feel sentimental about the subject and can’t put emotions beside. Let’s give example of Andy and Betty working in the same team. Any decision required can instantiate a talk between them. The ultimate goal should be sharing their experiences and enlarging their understanding on the subject.
However, human psychology starts with starting the things “they know”, “they believe”, totally living in their comfort zones. It is quite common that people are coming from different backgrounds; and maybe people like playing “devil’s advocate.”
“Crucial Conversations Tools for talking when stakes are high” was a useful book in this subject. Leaving emotions aside, being able to communicate, and having an agreement while you are keeping the relationship longer…I have realised that I have blogged about this book before, so I reckon it is the time:

Start with your Hearth:
– State what you really want
– State what you don’t want
– Find alternatives and creative solutions

Analyze your stories:
-Question your feelings and stories
– Don’t confuse stories with facts

Get Back to Facts:
-Separate fact from story by focusing on behaviour
-Spot the story by watching for “hot” words

Watch out for three clever stories:
– Victim [it is not my fault]
– Villian [it is all your fault]
–  Helpless [nothing else I can do]

Use a structure: [STATE]
-Share your facts
-Tell your story
-Ask for others paths
-Talk tentatively
-Encourage testing

In addition to these, obviously there are personality differences, Belbin roles, and colors of people during normal state and in conflict state, which are all subject to another blog, until then take care!

That’s all folks for today, hope you enjoyed!

Creating Business Impact

In Altnet conference, one of the discussions was around why we can’t tell business “this system is not working, we have pains with overtime and bad code”; “we should go agile” and “ship in small pieces”.
Proposing a new thing is hard for business to pick up and put into process. If they can’t see the benefit, they won’t believe us. Of course more importantly, we should believe in ourselves first.

If you are an idea person, it kills you more to have the same system/people not listening you…
If it is not working, you may listen to Fowler: “if you can’t change your organisation, change your organisation.”

However, this is my fifth company, and being confident about yourself gives the power to find a nice company in a few days/weeks; there are thousands of companies out there! Unfortunately, some of the companies did change after I have left. [Can’t they change when I was there? Should I be leaving to make a company change?]. I started to thinking that maybe I should be doing something more “effective, having more impact” for business so that they will listen, and take my offer into account. Eventually, I will feel happy and satisfied…

Just because of this reason, I was in training last week: Creating Business Impact.
It suggests a template:

1. Present Position:
[Don’t go straight into the problem. Do]
-Think about giving praise, thanks, and recognition, if appropriate
-Describe position now [e.g. sales, layout, staffing, system, equipment]

2. Problem
-Describe this so that the reader has a clear picture of what is happening, or could happen, if things don’t change.
-Stick to the facts, rather than your opinions which could differ from your reader’s.
-Don’t be too emotive -sound rational and reasonable.

3. Possibilities
– Set out different ways you could address the problem
-Number of ways. Give main advantages and disadvantages of each.
-Don’t confuse your reader with too many ideas, but you need to show you have thought beyond one solution, or one favourite brand.
-If you have a lot of facts and figures to present, put these in an appendix, and in a format that makes it easy for your reader to compare like with like.

4. Proposal
-State which possibility [or combination of possibilities] you recommend, and say why [without repeating all the advantages listed within the previous section]
-Anticipate likely objections, and address these.
-If possible, say how long it will take to get any return on expenditure.
-Say what happens next [i.e. Ask for finance, meeting].

That’s all…
Let’s see, if I can change my company this time [without leaving it]…