Category: Communication

Internal Interview? Piece of cake?

If you have the chance to work for a rapidly growing/blue chip company, and every other year/bi-year, new opportunities appear, you know what the internal interview is. If you have not done so, this article is a still good one to read for normal interviews!

It looks so easy at first to have an internal interview. And if you were in a position where the role was being offered to you, [but of course thay have to see the other candidates..], it looks really like a piece of cake…

Too easy? Anything seems to easy can become a challange, and lots of things can go wrong…Here is the list for the challenges and some tips to make the best out of you.

Challenge1:
Unlike normal interviews, there won’t be an agent, talking to you about the company, the interview, and what to expect from the interview.
Tip:
This does not mean that you should contact the HR department and get more details about the format of the interview, what type of questions to expect.

Challenge2:
* They have an idea about you before you go to the interview.
Tip:
Contact influential people:
Make sure they have a good idea about you. The people who know your performance, successful projects, and talent, may not be the influential people over interviewers. Worse than that, the interviewers may have connections with the people who does not technical backgrounds, does not understand the values you’ve added to the projects, and your talent. So, make sure, you have talked to these influential people before the interview, and get some advice after telling your inspirations and reasons why you are a good match for the position.

Challenge3:
You are applying for the same you work for. So, they will not ask the basic questions like “Do you know our company?”, which would be a great advantage on external interviews if you have a clear and complete answer.
Tip:
The advantage is that you will become from your most relevant tasks, i.e. this company. Show them how confident about your company, your knowledge about organisational functions, as well as projects.

Challenge4:
The building/room for interview will not a place you have never seen, people looking at you from the glass windows can be familiar faces.
Tip:
Before the interview go somewhere else, take a 10 minute. And enter the building as if you were interviewing for the first time.  This can cause some anxiety, but will help you to show you are excited, and you can look them from a different perspective.

Challenge5:
Characteristics questions will be harder
Tip:
Be prepared, if you had the chance to be a candidate, other [external] candidates will have probably more technical skills [doubling your years sometimes].
However, do underline that you know the environment, so there is no need for training, learning about company and the culture.
Make sure, you have prepared the answers for the characteristics questions, which will grant them you are the right candidate. Selecting 3 strong&weak characteristic relevant to the job, you need handy examples from your company as well as old ones.

It may not go well, other candidates [as they are selected from hundreds of CVs probably] can be stronger, and better fit for the position. This is not the end of the world, make sure you have a nice half an hour review about your application and why you have failed. Feedbacks will be always useful for yourself, your next application, and understanding their expectations. Do tell them, your motivation will not be less the existing motivation you have, and you value the company and your existing role.  You may never know, what is waiting for you around the corner….

Comments from my First Talk at ldnUG about F#

First of all, thanks all who had their valuable time spent on my talk about F# at EMC Conchango.
Thanks to Michelle for beers, to Zi for finding an HDMI cable at the last minute, to Liam for lovely chocolate cakes, to Argos for support, and to everyone for coming…

It was my first talk in England, and as it was a public talk, I was not sure about the content, examples. Even if I am coming from a trainer background, and I know that different level of people had attended my .NET Courses, it was quite hard to decide the depth of the subject, and to deliver the message I want to deliver. Every decision has a drawback, going simple can bore people, whereas going into complicated scenarios can leave some people out.
Rather than taking the challenging option :
– I decided to name the talk as “Intro”, so I thought meeting the expectations would be easier.
– Rather than going theoritical and covering more aspects of F#, I wanted to go over a simple demo, and share the feeling of writing in F# with VS2010.

Thanks God, it was not a disaster, and I got comments to work on, and improve, which is always good.

1. A complete sample:
My presentation was missing a complete sample, as my demos were quite small sized examples. When the seminar finishes, the audience would have felt more satisfied, if I had started and finished an F# project.
I had thought about this beforehand, but was not sure if I could have a project which is “simple” enough so that the audience can follow, “clean” enough so that I do not have to hacks during demo, and “complex” enough so that the audience would take home and work at home. I admit it is hard, but not achivable.

2. The balance of the slides/demo
Interestingly I got a feedback telling that I was better when I was coding during the presentation, and this was quite unusual for user group events; and I got feedbacks telling that I was disconnected from the audience while I was coding, so my mood/excitement was negatively affecting my touch to keyboard, and I was seen more confident while I was doing the talk and answering the questions.
Making everyone happy is impossible of course, but I can take both feedbacks as sensible.  After seeing 50 people in the room, [full room, with people sitting on the edge of the window], my confidence has jumped out of the window, instead of myself. I reckon, the less perfection I am, the more communicator I will be.
I love coding, so coding during the whole session would be my pleasure, but there is the other feedback comes into the screen:

3. How well you know your keyboard/touchpad/mouse?
The audience does nothing but sits and watch your coding experience. Little tweaks, multiple corrections to your mistakes does make your audience confused and breaks their focus. Bringing a keyboard/mouse that you daily use is the suggestion and I will try to take this one. Working more on my new laptop is the other option, and is a good alternative obviously, but it would never replace my keyboard used 8-10 hours a day.
What happens is that they may either start to interest into something different or start to sleeping. Worse than that, they may start talking to each other. Talking more about what you do and doing less changes at a time, does keep everyone back on board.

4. Communicating contact details
As the questions can be tricky during the session, you may need to give the answers later. But if you have not included your contact details at the end of the presentation, there is a high probability that, you will forget to tell “I will post the answers to my blog as soon as possible” as I forgot.
If you have anything you want to add, please do!

Twisting Job Search Process

When the time tells you need to change your job, you start to look around. The first action can be

a. going to a job board, like monster or totatljob, which will help you to understand the market needs and rates.
b. ask friends if they have a job at their companies.

Andy Lester on his book Land The Tech Job You Love was referring a stastical data which tells that percentage of people getting jobs from job boards was %11. The rest of %89 people are finding jobs through communication.

Whatever the way you prefer, you need to analyse yourself, and to decide what will make you happy is the main goal of this article.

A. Before the Interview

a. Updating your cv

Reread your CV, would you find it clear, and easy to read if your were a hiring manager?
Make sure you describe the roles and responsibilities you have been involved in, what value you have added to your previous jobs The technologies you have worked with is not going to add points towards you if they are standing alone without explanation. Make sure the use of those technologies were solutions to certain problems. It does verify you know what you are doing, and you face a similar problem in future, you know how to take action.

b. List what makes you happy
I find three important things about a job: the people you work with, the projects you are involved in, and your role. Tell yourself what kind of people you like to work with. The culture of the companies decide the communication between the employees. So it can be formal or informal communication going on. Decide on which end you feel more comfortable.
The projects can be short or long, client based projects or internal projects. Depending on your experience, you can identify where you are comfortable.

c.  List the items why you need a change, i.e. the things you do not want to do at your next job.
Write down all technologies, projects, problems. Being aware of them will help you during the interview process.

B. During the Interview

Aaron Erickson on his book Nomadic Developer got detailed explanation about the his experience through consultancy companies he has been involved in for years, and he categorizes the firms into seven, talking about positive and negative side effects, namely seven deadly firms. He has nice tips about the interview questions.  Here I will list the ones that I see as important,

a.  Human-based factors

– How do they learn new technologies [Do they attend/create any seminars, trainings, events internal?]
– Are they motivated to take certifications/go to external events/seminars [Devweek, QCon, Techdays]?
– How do they share what they have learnt about the business, projects, experiences internally [Do you have any wiki, sharepoint, internal site/structure to share/store documentation]
– How do they communicate/are motivated? [team events, afternoon teas/beer nights, teambuilding events]
– What would they want change if they were given a chance to improve one thing?

b. System-based factors:

– Do they a competitor product/company doing similar projects in the market [If yes what kind of analytics they use?]
– How do they improve your products/processes, any regular feedback session with clients/team members?
– What would their clients [internal or external] suggest as the best improvement for the project,
– Are they implementing any process like Scrum or kanban? As version controlling system, what are you using? How regularly code deployments happen?
– Do they have a mature process for project lifecycles?
– Do they have a roadmap for the technologies they will use and projects they want to start/finish?

So, you can have the idea of the company, where you can feel you can add value and be happy together. As Andy Lester says,

It is a relationship, being open and honest will make the relationship long lasting.

Started F#

Where to start is the question, and here is a short intro from the best sources I could find:

1. Don Syme’s weblog

He is the creator of F#, and emphasizes the succint and expressiveness of the language.

F# makes three primary contributions to parallel, asynchronous and reactive programming in the context of a VM-based platform such as .NET:

(a) functional programming greatly reduces the amount of explicit mutation used by the programmer for many programming tasks
(b) F# includes a powerful “async” construct for compositional reactive and parallel computations, including both parallel I/O and CPU computations, and
(c) “async” enables the definition and execution of lightweight agents without an adjusted threading model on the virtual machine.

2. Chris Smith’s Programming F# book in 20 minutes Part I and Part II

Notes from the book:

* F# supports functional programming, tells what to do, not how to do.
* F# supports imperative programming

Example:

let functionalSum numbers =
  numbers
  |> Seq.map square
  |> Seq.sum

let imperativeSum numbers=
   let mutable total=0
   for i in numbers do
     let x= square i
     total <- total + x
   total

* F# supports OO programming, you can abstract the code into classes and objects.
* F# is a .NET language with all libraries, Garbage Collector, and CLI.
* Everything is immutable by default, so you can experience side-effect free development.
* F# is statically typed, at compile time you have the type-safe code.
* Take care of:
–  the order of the files of your project in your solution explorer, they will be compiled from top to bottom.
– indentations, as there are no curly brackets, the indentation will define the scope.
– also F# is white-space significant, and case-sensitive.

3. An introduction to F# at Channel 9 by Luca Bolognese. Notes from the presentation:

You went to counter, and told that you want a cappucino, and start to tell “Now you grind the coffee, and get the water, warm it. At the same time, prepare the milk, but I want those things go in parallel.”

Three key things he emphasizes:

1. let keyword bind a value to a symbol

let sqr x = x * x

2. Arrow “->”, similar to “=” in C# for assigning value; but it is more specific: it means you are pushing something inside the location in memory, not working with symbols any more.

let addBalance x=
    let balance =0.0
    balance <- balance + x 

3. fun: Function/lambda expression as in c#

(fun x->x+3) 7;;

which takes 7 as parameter and returns 10 or

List.map (fun i->i*2) [1..4]

which return [2,4,6,8]

4.Don Campbell’s blog about why he loves F#

5. The F# community, HubsFs

6. F# at Microsoft Research

7. Phil Trelford’s session at EdgeUG talk, with nice F# samples.

Anything I have missed?

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!