Friday, 4 January 2008
Wii Stream
I'm a terrible geek when it comes to new things. When I first got my PSP, within a week I'd managed to get an emulator on there running megadrive games, custom web browers, SNES games and more. I cannot help myself!
And now that I'm back home and the holidays are done, I turn my attention to the Wii. It may not be the most powerful new kid on the block, but there is a fair bit of oomph in there.
My interest is in playing movies through it.
A friend at work pointed me toward http://www.tversity.com/. There is a media encoder which encodes videos to flash on the fly and streams them to a web browser. Since you can download Opera for the Wii (500 points I believe), it is possible to use this combo to pull movies, music, pictures, etc all through this package.
Best of all TVersity is free (they accept donations).
So guess what I'm doing this weekend in any spare time I can find...
Any advice appreciated from other Wii Streamers out there ;-)
Thursday, 1 November 2007
What they say and what they mean
Long Long Ago, I Made A Promise. I said that I'd get around to writing down what I thought interviewers said and what they actually mean.
Since that post, we've had a new baby. Getting ready for that took a lot of focus off the blog and consequently this post was not written...
... until now!
Now I know you can pick up a book and read lots of this stuff already, and I absolutely implore you to do that if you have time. For those of you who don't have time, here is my quick summary of what I think interviewers might be angling toward.
What are your strengths and weaknesses?
Recognise that if you are unprepared for this, then there is no limit to how much rope you have in hand to hang yourself with. Don't adlib this one.
The question seeks to find out how you see yourself, how you think others see you, how you handle critisism and also importantly what your goals are (if indeed you have any).
To prepare for this consider your goal. Why are you taking the interview? What is the role you want.
With this in mind, think about what you have to get you there and what holds you back. Then think about how you and your employer can close those gaps holding you back (training, mentoring, University, experience).
Explain how these then fit into the job description on offer and make sure to use some of the terms in their job ad. It will help it ring true in their minds.
Mostly, keep this concise and well polished. It shows a massive commitment toward the company and demonstrates you are willing to put some effort into the interview (which shows respect of the organisation).
When have you done more of you than is required?
There are two types of employees in most places. The 9-5 guys (go home, switch off, do something else), and the rest of them (toss problems in their head, etc).
The key point here is to demonstrate that you did something not expected by your employer. For example, did a degree on my own part-time, solved a problem at home on my own time, championed an initiative while preparing in my own time.
The employer isn't so interested that you give 50 hours and are paid for 35, they ARE interested in hearing you are passionate about your profession.
The girl who goes home and thinks about the problem in the back of their mind and comes to work with the answer will feature higher in the interviewers mental scorecard. Companies love to have energetic staff who motivate others around them.
So in short, the interviewer looks to hear that you are in it for more than just the money and want to hear you demonstrate it.
How would you handle poorly performing staff?
Only really applies to those in team lead or management positions.
Mostly this is a question of ettiquite and social skills. Are you able to talk to people in a non-confrontational way? Do you need daddy (management) to bail you out?
You might be given this question in a behavioural context. For example 'You have found a member of staff browsing the Internet for illegal music during work hours instead of working on their project. How do you approach this situation?'. It's the same question in different clothes.
How you answer this depends on the type of person you are. Remember that employers want staff to value their policies and respect them, they want you to help nip problems in the bud early, and they want you to be able to communicate and listen to others.
Do your research on the company. Find out a little about their culture. And don't be afraid to ask at the end of the interview for more detail on the company culture to learn what is expected of staff.
What is your worst experience and what did you learn from it?
Straight to the point question. The interviewer is asking two direct questions.
1. Have you experience and in what areas?
2. Do you identify and learn from your mistakes?
Cover those two angles to give them interviewers the details they need. You won't really be able to bluff this as the interviewer will often ask you to explain more detail on the experience.
Keep this answer short, a few minutes at most. The better you can tell this story, the more punch your answer will have.
What have been your most and least productive times?
The short answer is they want to know that you will get enjoyment from the role on offer.
Interviewers want to hear you describing the experiences you have had that fired your motivation and use this to determine if they think you will be equally or more fired up in their workplace. Was your motivation financial, challenge, technical, fear?
They are also interested to hear about the lower points. If you were less productive, what did you do about it? The interview should be able to accept and recognise that we don't always make the best career choices. It's OK to admit you tried something and hated it.
It is likely they want to understand that you are happy to be out of your comfort zone and try new things, and clearly want to know if things interest you so they can determine if you are a good fit into the organisation.
Most companies want a higher workforce skills mobility, staff who are multiskilled and can flex into roles as needed. If you happen to be one of these types of people, be sure to highlight it here.
How would others describe you?
Exactly as it says on the tin. How do others see you?
Keep your answer to this short and use simply words like 'honest', 'reliable', 'trustworthy', 'competent'.
Don't worry about embelishing the answer more than this, but do prepare examples for each point.
What skills do you bring to a team? / What skills do you think this role demands? / What will the challenges be in this role?
If you have read the role descriptions, the answers they want are all in there. They just want to know you have thought about the role.
Your only job is to highlight the tie between your CV and their job description.
I'd suggest a simple excercise here.
- Print your CV and the job description out.
- Sit them side by side and number the items across the two which support each other (e.g. the job asks for Oracle skills, circle this in both papers).
Just doing this will focus your mind on how good a match your CV is to their job description. This should be enough to get through the interview.
Try hard to avoid taking paper into the interview and reading from it. Have a few small bullet points, but don't read line by line.
Why do you want this role? / Why should you get this role?
There isn't a hidden question here, they want to hear your summary of what makes this a good fit.
They are interested in seeing if you listen and if you can summarise well.
If you were paying attention in the interview, you should try to put in a few comments about the things your learned at the interview today. This is clearly trickier, but shows you are an active listener.
What will you do if you don’t get this role?
Bit of a nasty question, but can be fairly asked.
I'd recommend you make clear that you will want to understand why you didn't get the role, therefore will look for feedback from the interview panel if possible.
I'd also mention that you will continue to look for a role similar to the one on offer as it appears to be a very good fit.
All of this said and done only really works if you are committed to the role.
Do your research, think about the role and your skills / experience match, and bring your experiences to the fore of your mind so you can tell them to others.
Monday, 29 October 2007
Are We Nearly There Yet?
I bought a book around 6 months ago called Software Estimation: The Black Art Demystified. It's one of those types of book along with Code Complete which should be on every developers reading list, and by reading list, I mean read it once per year, every just a refresher.
So the book was parked after around 80 pages shortly before Emily arrived (our new baby), and now she's here the book is gathering dust.
Two articles appeared on my aggregator recently. One from Joel Spolsky on Evidence Based Scheduling and one from Jeff Atwood on Planning Poker, partially responding to Joel's post.
Both posts are very well written and are worth a read. They rekindled my interest in this topic, sort of the point of them I suspect!
As the Black Art book explains, everyone thinks they can estimate. While influencing people's decisions can prove hard, actually changing their approach to estimating I find is even harder.
A few techniques I wonder about using:
- Planning Poker. I love the idea of this, it seems a smart and tidy approach to reach a good consensus. However the flaw here is you need a set of equally able and open minded people who actually listen, otherwise failure is on the cards. I feel a slightly diluted version of this will work well to turn the tide.
- Track estimate against actual. I think of all of the suggestions, this is the easiest to deliver and shows exactly how good your estimates are. The FogBuzz product from Joel's company uses this to good effect.
I've set myself a target to read this book cover to cover within the next 2 months and hope to reflect on it here.
What do you think? How do you approach estimating in your workplace?
Tuesday, 11 September 2007
Clarifying Requirements
As software developers, we have a job to push back on unclear requirements and to help achieve a clearer, and importantly a shared understanding of the system.
Most users will not be versed in creating contracts. As a result, ambiguous terms will creep in without the user realising. Phrases such as 'The interface must be intuitive' don't make our jobs any easier.
When I receive these types of requirements I used to spend time reading and marking the documents by hand. This can be quite a laborious process and is very dependent on the experience of the reviewer.
I've been using a technique to help me become more consistent at giving feedback on requirements and to help establish a shared vocabulary of ambiguous terms.
The idea is simple. Create a document with all of the terms you know of which lead to ambiguity, then create an index showing where each of these terms appear in the requirements document.
I'm afraid I'm a Microsoft Word man, so the technique will need to be adapted to your personal tool of choice.
Grab a copy of the text in this list of ambiguous terms. Pop it into a new word document and save the document somewhere.
Take a copy of the document to be reviewed (the target document). You will be altering this document and don't want to change the original.
Make ALL of the text lower case within the target document (explained in a moment)
Use the 'automark' feature to highlight the terms in your 'requirements' document. This feature asks you to select a source document for the automark entries. (In Office 2007 this is found under the references tab, 'insert index', then select the 'Automark' option.)
At this point, Word has marked each phrase in the target document where the phrase in the 'ambiguous terms' appears.
Now, to create an index showing the user where the terms are:
Insert an index using the index feature within Word. In Office 2007, this is in the 'references' tab under the index section.
Finally, review the usage of the terms in context and send appropriate comments back to the user.
The automark feature of Microsoft Word is not the greatest for this usage, but if you are prepared to follow these steps and develop your own version of the ambiguous terms document (and share it with others in your team), this will help contribute toward better quality requirements.
In particular, I dislike the requirement for the ambiguous terms document to need two columns, both containing the same text. I haven't looked to solve this, let me know if you do!
In itself, the process is not fantastic. But if you share a master copy of the ambiguous terms document, then the whole team can contribute their experienced view to improved requirements.
(The concept here was unabashedly taken from Code Complete by Steve McConnell. Grab a copy and read it, highly recommended).
Update: I've pushed the 'Acceptable Terms' doc into a published Google Doc here
http://docs.google.com/Doc?id=dgdfgwms_5cp9v8k
and have updated the URL's above
Monday, 3 September 2007
A few baby pictures / videos
End of notice!
I've put some more pictures up here.
I also took a moment to upload some videos. One where little happens, and another with hiccups.
Also, if you haven't seen it and can bare it enough to not cringe, here's a video of Euan on safari...
Sunday, 2 September 2007
Baby 3 - delivered safely...
http://picasaweb.google.com/aitken.mark/Baby3?authkey=Uj3rBUWVRzY
Too late at night to post much, suffice to say Allie and Baby are well.
7lbs10, little girl, no name yet.
My god, a little girl. How scary is that. How the hell do girls work? Need to find the Haynes manual....
:-)
Bed time for me.
Friday, 31 August 2007
What do I put in a CV
- Don't show collected skills, demonstrate usage of them. Many CV's try to throw in words but don't show how the skills were used. Remember that you need to actually use a skills to have it. Keep your core skills sharp.
- Show money savings as a result of your involvement. In the UK we often are involved in money making or saving organisations. Try to show your value add. If you don't know the real numbers, show percentages. e.g. I saved approximately 10% on build time by removing dependencies between libraries
- Step back and try to see your CV as grids and lines and think about design and layout. There is a good article on coding horror showing that more about general website design. I think the same layout rules apply to CV writing when you want to lead the reader down the page and into areas of focus. Naturally content is important, but so is the feel of the CV.
- Remember you have soft skills too. Think about your consultative angle (communication, leadership, negotiating). Use these words within your CV.
- Show passion. David Intersimone wrote a blog post a while back explaining that he'd pick a person with less skills but more passion for IT than a person with more skills but less passion. The passionate employee will usually go the extra mile and usually pull more rabbits from hats. If you are passionate about IT, drop a little bit of this spice into your CV and remember a little goes a long way.
- Walk away for a while. Leave your CV alone for a few days, print it, then sit down for a 1/2 hour and read it with renewed vigour and a fresh head. A good CV should read smoothly like a good book. Make sure that others will enjoy reading your CV.
Hope these tips are a little more off the wall than the typicals ones you see.
What do you think makes a good CV?