Separating the sheep from the goats during an interview (part 1 - Learnability)

I previously talked about the perfect CV and how an applicant can survive an interview. Although both posts are more oriented towards candidates, they are also useful for employers. When you receive a CV that is written as it should be and when a candidate can act normal without suffering too much from stress, you are already halfway in evaluating the candidate. In this post, I want to go deeper in what -in my opinion-  a company should look for in an ideal employee and how to test this during a one hour interview.

How can you actually evaluate a candidate in one hour?

During the interview, I always let the candidate elaborate on his latest job/function and only explain the content of the job at the end of the interview if he is actually a worthy candidate. Most of the times I already interrupt him during the first few minutes to steer the candidate towards the things I want to know that are important for the job and to look for the 3 major qualities I look for in the ideal candidate.

1. Learnability

2. Responsibility

3. Social

In this post I will elaborate on the first quality: learnability. In next posts, I'll go deeper into the other two qualities.

Learnability

Learnability is all about being smart and the willingness to learn. Being smart is not enough by itself. I rather check the learnability as a whole of the candidates. They should be smart to be able to actually understand things AND should also be willing to learn.

How do you test smartness? I always have a question in my sleeve that can easily be answered at first sight, but which will be used as a trigger for a lot of follow up questions. If they know the answers, good for them, they'll get the next question that builds upon the first question and the answer they gave. So far, we probably are testing their encyclopedic knowledge, things they know already anyway.

It really gets interesting when they do not know the answer immediately. This is where you go beyond encyclopedic knowledge and can see if they really understand what they are talking about. Just give them the answer yourself, explain it in detail and look if they can follow. You may explicitly ask them if they understood the answer. Then you can hit them with another question that builds upon your own answer. Look at their reaction. Have they really understood everything you said? Do they ask questions themselves to follow your reasoning? Can they reason with you? Can they actually answer the new question or do they blank out? Even if they can not answer again, do the same again, give the answer yourself, explain it in detail and hit them with the next question. See how far you can go. If you can see that they stick with you until the end and they don't get frustrated or completely blank out, you got a smart person in front of you.

Don't try to be too smart with your questions though, you could end up like Google expecting an answer which is in fact wrong on a question they ask during interviews:

http://www.thebigquestions.com/2010/12/21/are-you-smarter-than-google/

http://www.thebigquestions.com/2010/12/22/a-big-answer-2/

Just choose something quirky or not so obvious you encountered in your own experience.

Being smart does not mean they are actually willing to learn new things though. To test their willingness, I ask what they do at home to stay up to date, are they reading articles, blogs, sites, books, etc... in their free time? Even if they only do this during their daytime job, reading a blog or article does not take a lot of time and keeps them sufficiently informed of what is happening in their domain of expertise. If they do stay up to date, I always ask them to tell me something about the things they've read and what they like or don't like about it. What are the evolutions? What do they think what the future brings?

Learnability might be a knife that cuts on both sides. If you have a lot of people with high learnability, they might never get things done, because they are always looking for the next best thing and never finish their actual work. You might not always need people who want to learn all the time. Sometimes it is sufficient that they are smart enough to understand the task at hand and make sure there is a smooth continuation of existing tasks. More on this when I talk about responsibility.

I generally reserve 20-30 minutes for this part during a one hour interview, because I think this is really important.

In a next post I'll go deeper into responsibility. If you think you're learnability is high, you are already one step closer to working for us.

A foundation for writing guidelines

I've been several times in a situation where I had to write guidelines for one of our clients . Guidelines, instructions, procedures, protocols, ... some seem more strict than others, but they all suffer from the same problem: how to clearly indicate the do's and don'ts.

A few years ago, I got inspired by what is known as an RFC (Request for Comments) in the internet world. Very roughly speaking, RFCs describes how machines must communicate over the internet. One RFC in particular (RFC 2119), written by Scott Bradner from Harvard University, describes some key words to signify the requirements in a (RFC) document.

Although the RFC clearly states that "they must not be used to impose a particular method they must not be used to try to impose a particular method on implementors where the method is not required for interoperability" (roughly speaking for the internet again), I found them very useful for guidelines in general.

The key words are as follow (excerpt from the originial document):

1. MUST - This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
   
   
2. MUST NOT - This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
   
   
3. SHOULD - This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
   
   
4. SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.
   
   
5. MAY - This word, or the adjective "OPTIONAL", mean that an item is truly optional.  

Let's look at a simple example of how these key words can be used in practice. Although I don't have grass in my own garden, I found a simple article on "How to mow grass like a pro" with some straight forward instructions on - you guessed it - how to mow a grass like a pro to make it truly look slick. Here is the adapted version that uses the key words to emphasize certain points on what to do and what not to do:

1. The lawn MUST NOT be wet before mowing grass. Being wet only causes grass to clod up and create mounds of grass through out your lawn. When cutting grass when dry; the clippings spread out evenly, and fall into the lawn and disappears. Of course this depends on how high the grass is before cutting. If grass is exceptionally high, you SHOULD bag the grass and dispose of it.
   
   
2. You MUST NOT cut grass too short. Mowing grass too short allows you to possibly scalp the ground and leave dead spots. As a safe measure, you SHOULD cut grass at about 2 1/2 to 3 inches to be safe. Some even prefer 3 1/2 inches. Depending on how level the ground is; if there are unlevel mounds and drainage trenches, you SHOULD consider cutting as high as possible to avoid scalping.
   
4. You SHOULD mow grass before weed eating or trimming. 
5. This will enable you to make sure you will not have to go over the lawn twice. By weed eating after you mow; those corner spots will stick out like a sore thumb, and you will be able to do a more professional job and not miss anything.
6. 
   
7. A choice of weed killer can be a number of brands. When you choose a weed killer, you MUST be sure you mix it properly. You MUST read the instructions on the label for mixing it correctly. You MUST NOT spray if the wind is 10 mph or above. You MUST NOT spray around young shrubs and flowers, large trees will handle these weed killers, but take precautions anyway.
8. 
   
9. You SHOULD spray around your home and barns or storage sheds. You SHOULD spray about 3 inches wide. This will look neat and will not leave a wide dead space that is ugly. You SHOULD NOT spray weed killer in drainage areas on your property, this will only cause erosion eventually. You MAY spray ditches but be advised to only spay the very bottom, you MUST NOT spray the sides.
10. 
    
11. You MUST use an edger for your side walks and walk ways. You MUST NOT spray these areas or even weed eat them. This will only cause the edge of the grass to get wider, and will not look professional. Edging these areas will have a neat straight look
12. 
    

This looks like overkill, but by using the key words, you make sure that no misinterpretation is possible. Although using the key words does not prevent you of adding arguments or elaborate some parts in the document to clarify things. The key words are there to make sure the requirements are well understood.

All guidelines I write now are superseded by a chapter (eg. "Keywords to indicate requirement levels") describing the above key words. Throughout the whole document, I apply the key words consistently to emphasize requirements in the document. The key words are also in uppercase to even emphasize them more.

It is now much easier to write more to the point and stricter guidelines, without sounding arrogant. By describing the rationale behind the key words in a introductory chapter, they are perceived as a formal part of the document and not as me pointing with a finger.

Surviving a job interview

So, you made the perfect CV and they called you to come over for an interview. What now?

I've seen so many people stressing out during a job interview, but by changing your mindset a little bit you can be so much more relaxed and make a far better impression. The key factor here is that an interview always works in 2 directions.

Preparations

Again, the foremost important thing to remember is that an interview always works in 2 directions. You are being evaluated, but to be sure there is really a match you must evaluate them at the same time! To be able to say if the job they offer is really what you want and you really want to work there, you have to know what you want of course. This is an exercise you actually have to do prior to writing your CV, so you can steer them early on by letting them know what your career objective is and by implicitly stressing parts of your past experience you liked most and would like to build upon. If they call you now for an interview, you are pretty sure they think there is a match. Up to you to find out if it is really an interesting one.

So, you've let them know what you want and what you're worth in your CV and if applicable in your application form, but to evaluate them, you have to do your homework too. 

Do not only look on their website for background, but look also for subsidiary companies, companies they work closely with, etc... Google is your friend here. Read about the company history, where they come from and what they do now. Are there a lot of jobopenings (is the company growing or mainly replacing people)? Did they have any recent press releases? Are people blogging about them? Are they on twitter/facebook? Are there employees on LinkedIn? Do the employees you find on LinkedIn work for a short or long time for them? What about recommendations? And so on...

The more you know, the better you are armed for the interview, because going to an interview is like going to a battle and you have to win the battle to get the job. Being well informed is also better against stress, because you'll be more relaxed and you'll feel more as 'an equal' to the person(s) in front of you. Stress may leave a bad impression, especially if you are applying for a stressful job. If you have a hard time hiding those sweaty armpits, there are some efficient products against that, like Axitrans (http://www.vesalepharma.com/STA/EN/produits_axitrans.html)

So far the preparations. 

The interview

Before I forget, let me repeat it again: an interview always works in 2 directions!

First of all, make sure you are on time or have a phone number to call them if you happen to be late for some reason. If they offer you something to drink, always ask for water. It helps better than coffee against a dry mouth, you can also sip a little bit during the interview to buy some time when you can not answer immediately and nobody minds if you don't empty it before the end of the interview.

When you carry a briefcase or backpack, put them against the wall, where you can not stumble over it by accident. If you need a pen and paper to take notes, take it out at the beginning of the interview.

Two things may happen now. Or they start talking about the job opening and explain more about the job and/or company or they ask you to elaborate more on your working experience mentioned in your CV. Either way, you can steer the interview a little bit. In the former case, you'll have to listen very well to adapt the answers you'll have to give in the second part of the interview and in the latter case you can elaborate on the things you like most and they will start asking more specific questions along the way. Talk with passion, even if you want to change jobs because you are not motivated anymore, talk about the good things and the things you liked about it. Enthusiasm sells!

A lot of applicants are afraid to ask questions, don't be! During the time you elaborate on your own CV, ask also how they do things within their company. Ask how they work and match your own experience on that. In the beginning, you might have to guess or try different approaches. For example " ...<talk about your experience>... I don't know if you are doing similar? <then pause >" or " ...<talk about your experience>... You can do that in another way also ...<talk about the second way where you have less experience with>... I don't know which way you are working here? <then pause>".

While they explain the job offer and company, try to gently interrupt with questions like "How big is the team? Who will I be working with? What is their experience? To whom am I responsible? If it is an existing position, why has the previous person left the post? If it is a new position, why is it created? Are there any trainings I can follow? When would the selected candidate be able to start? Are there many candidates? ..."

Remember, an interview always works in 2 directions!

I deliberately did not talk about typical interview questions you might get or about psychometric tests. On both you should just be honest and don't prepare too much. It is not really a test you are doing here, it is merely checking if you think as they do. If you try to manipulate this part, you probably won't be very happy in your job. In fact, this part should be the easiest part on your side, because no matter what the result is, you always win. Again, if there is no match, you do not want to work there.

Remember these things when you come for an interview with us ;-)

Good luck!

Scala for the busy Java developer

The title of this blog entry is shamelessly inspired on "The busy Java developer's guide for Scala" from Ted Neward. As a busy man myself and having a Java background with interests in Scala, I went looking for sites, books, exercises, tools, etc... to quickly learn the ins and outs of Scala.

There is of course the main site (http://www.scala-lang.org/), with references to some good books, but that simply takes too much time. A good traject to follow and which I followed also, is the one I describe below.

First thing you need is of course a Scala compiler/interpreter. Why bothering installing Scala on your local machine, even if you have already a good IDE installed. It is far easier to start with an online interpreter (http://www.simplyscala.com/), which simply runs in a browser. It does not run on my iPhone (still iOS 3.1.2, I know,...). Maybe it works on a later version -if so, then probably also on an iPad- or on an Android phone or tablet,... Anyone?

Although that same site has some tutorials on it also, they are not sufficient for a real introduction to the Scala languate. For Java developers, there is a much better introduction from Ted Neward on IBM developerWorks. Here is the deeplink with an overview of all the Scala articles from Ted on developerWorks, sorted by date: http://www.ibm.com/developerworks/views/java/libraryview.jsp?site_id=1&contentarea_by=Java&sort_by=Date&sort_order=1&start=1&end=17&topic_by=&product_by=&type_by=All%20Types&show_abstract=true&search_by=scala%20neward&industry_by=

It is very easy to execute the code from the articles inside de interpreter on Simply Scala, just do a copy & paste. When Ted actually implements a runnable application, skip the object definition and execute the body directly in the interpreter. For example in the article "Class Action", he uses the following snippet to exercise the Rational class:

object RunRational extends Application
{
  val r1 = new Rational(1, 3)
  val r2 = new Rational(2, 5)
  val r3 = r1 - r2
  val r4 = r1 + r2
  Console.println("r1 = " + r1)
  Console.println("r2 = " + r2)
  Console.println("r3 = r1 - r2 = " + r3)
  Console.println("r4 = r1 + r2 = " + r4)
}

Just copy anything within the brackets ( {...} ) into the interpreter et voilà... 

Now that you have a good start and if you have some time left, there are a lot of interesting exercises on the internet to enhance your skills (especially the functional part, which is new for Java developers). Project Euler (http://projecteuler.net/) and Rosetta Code (http://rosettacode.org/wiki/Main_Page) contain quite some interesting and challenging exercises which are also used at universities as small projects.

Have fun with Scala! It might be the language of the future on the JVM, time will tell...

Make you résumé or curriculum vitae (CV) land on top of the pile

During the last 7 years or so, I had to evaluate *a lot* of résumés. A lot of them were good, some even great and some just plain crap. I know that a résumé and a CV are not the same in the US and Canada, but in this blog entry I'll discuss the more detailed CV and will use both names interchangeably.

Where to start? There is a very good website of the University of Antwerpen that elaborates on academic, business and technical communication in written form. (http://www.calliope.be/, dutch, english and french!). I'll sum up the most interesting parts from that site and combine them to make a model CV (my own ;-) )

Types of CV

There are 2 major types of curricula vitae: the functional and the reverse chronological. The former is more oriented towards the professional with a long career and the latter towards the recently graduated or young professional. 

The functional CV elaborates on the functional domains you specialised in during your career *and* on the functional domains you want to further specialise in. Leave out the things you are not interested in (anymore) and emphasize some recently acquired skills you want to focus on in the future. With a functional CV, you can implicitly show your career objectives and what you want to achieve personally. There is less emphasis on employment history.

The reverse chronological CV emphasizes your education and employment history. In a reverse chronological order, work experience, education and extracurricular activities are listed together with some extras relevant for your function or domain of expertise (eg. languages, computer skills, etc...)

The ideal CV for me is a hybrid of a functional and a reverse chronological CV.

Let's build a hybrid CV based on the theorie above.

Sample CV

Every CV needs some basic personal information, but before even putting your address, etc... in the CV, I prefer to see a small summary of your career objective. Here is my summary description:

CURRICULUM VITAE

Sven Beauprez, Managing Partner Xume

Enterprise Solution/IT Architect who uses his communicative skills combined with in depth IT experience to align Business and IT and who designs future proof enterprise wide solutions

It is immediately followed by your personal information (mail and phone removed to avoid spamming). These days, it is more and more important to show your online presence like your LinkedIn profile, Twitter, etc... Personally I use facebook only privately and will not accept just professional contact as friend (feel free to add me to LinkedIn though ;-) ), so I leave it out of my CV also.

Personal data

Name : Beauprez Sven	Date of birth : October 14, 1976
Region: Gent, Belgium	Nationality : Belg
Marital status : In a relationship	LinkedIn : http://be.linkedin.com/in/svenbeauprez
Mobile : +32 (0) ...	E-mail: sven.beauprez@...

Next is a section with your profile containing a high level view on your hard and soft skills.

Profile

-        has 11 years experience in designing, implementing and integrating backend services/systems and web applications

-        has 8 years experience in aligning Business and IT

-        skilled in selecting, coaching, motivating and leading people

-        thinks analytical and in long term solutions

-        is pro-active and takes initiative

-        has strong social and communication skills 

The second half of the first page contains a brief summary of the relevant (!) trainings you had, your education and relevant (!) activities. Less relevant extracurricular activities should be mentioned at the end.

Education/Training

-        2010-2011: Executive Master Class in Innovation & Entrepreneurship at Vlerick Leuven Gent Management School

-        2008-2009: Certified Enterprise Architect from Carnegie Mellon University

-        2007: Certified Scrum Master (instructor Ken Schwaber)

-        2007: Certified Scrum Product Owner (instructor Ken Schwaber)

-        2000: UML course at Rational

-        1999: thesis about e-Commerce + working prototype

-        1994-1999 : Master in Computer Science, specialization Information and Communication Technology, at the University of Ghent, graduated with distinction

-        1988-1994 : Highschool, Mathematics-Science

Activities

-        2003-2008: Steering member JavaPolis/Devoxx
Mainly responsible for the “Open Source” and “J2SE” track, and day to day management at the venue

-        2003-2008: Steering member Belgian Java User Group (BeJUG)
Organized and presented events ( “JDK 1.4 Overview”, “Java Web Development”, “AOP”, “Rich User Interfaces”, “Open Source libraries”, “Security”,...)

All of the above must fit on exactly 1 page (the first page) of your CV. If not, try to rearrange things until it fits 1 page! (I hate a long CV!)

The second page is where it gets interesting. On this page, you should give a functional overview of your expertise. Here, it does not matter when you worked for which company or on which project you worked, all that matters is the expertise you developed over the years in different functional domains.

Try to identify a number of relevant domains, categorise them and write down your results and contributions (experience) in that domain. Here is the functional overview of my experience:

Experience: functional overview

- Enterprise Solution Architecture / IT Architecture experience

o designing and documenting individual solutions/projects (from software to

infrastructure) based on given business process

o recognizing solution patterns common to different solutions/projects and

apply them to new solutions

o building and documenting an application (software), infrastructure (hardware)

and service (SOA) solution portfolio

o acting as a mediator between business and IT

- Software Architecture experience

o designing future proof architecture based on business needs and budget

o auditing existing software architecture

o writing development guidelines & standards

o researching and selecting tools, frameworks and libraries

o setting up continuous integration build environments

o designing deployment procedures

o specialized in Java & Open Source solutions

- Company- en management experience

o coaching and leading of developers/architects

o resource planning and budgeting

o managing and follow up of project implementations

o organizing events/conferences (BeJUG/JavaPolis/Devoxx)

- Recruitment & Selection

o candidate selection based on CV

o interview and evaluation of candidates

This was the hard part. The next pages contain a reverse chronological overview of the actual companies/roles/projects you worked for/as/on. Try to be brief an to the point on each of them. Generally an entry should not be longer than half a page and older entries (eg. more than 7-10 years) can be left out or can do without explanation. Maximum 3 to 4 pages should be dedicated to this part of your CV. Here are 2 entries from my CV:

Experience: chronological overview

-          01/07/2001-now:
Managing Partner and Co-Founder Xume BVBA, an IT Consulting Company

-          01/03/2005-now:
Owner Prorabel BVBA, a Management Company

-          01/04/2010-now: Solution Architect at “De Post” / ”bpost” as Xume Consultant

§  Assisting Enterprise Architecture with defining guidelines to design and document solutions for existing and new projects on conceptual and logical level

§  Research and design of a solution, and bootstrap implementation for Availability and Performance Monitoring (APM) of Java, .Net and commercial of-the-shelf applications (>60 applications in total). Solution will be extended for Business Activity Monitoring (BAM)

§  Research and design of a solution for the implementation of Service Oriented Architecture and Enterprise Application Integration

-          01/10/2009-31/03/2010: Enterprise Solution Architect at “Thomas Cook” as Xume Consultant

§  Formal follow-up of work already done as Software Architect (see below)

§  Assisting the Enterprise Architect with defining standards and guidelines to design and document solutions for new projects on conceptual and logical level

§  Started the design and documentation of 3 new individual solutions for CRM suite, TravelBox (similar to Bongo) and new ThomasCook.be website and the integration with legacy systems

§  Formalized solution patterns already in place through previous work (see below) and set up a solution portfolio of reusable applications.

Based on Gartner documents about “Solution Architecture” and EA course of Carnegie Mellon University

-          01/01/2007-31/09/2009:Software Architect/Technical Team Lead (Scrum Master) at “Thomas Cook” as Xume Consultant

§  Set up a uniform architecture and development environment for all legacy and new projects (>50).

§  Writing and implementing architecture guidelines and standards.

§  Coaching the refactoring of all legacy projects to be able to build with Maven 2 and a local Maven 2 repository (Proximity/Nexus) was set up. All projects are kept in a Subversion repository and continuous integration builds (including testing and code coverage) are done with Hudson.

§  Introduced new, more modern and de-facto frameworks like Spring, Hibernate, Mule,... for as well as web development as service integration (ESB) and wrote the corresponding architecture and coding guidelines.

§  Lead the team with the internal team lead through several projects, based on Scrum principle and coached the day to day development.

§  Recruited new people and helped the team grow from 3 to 30 people.

§  Advised the IT manager with the purchase of a new server parc and the implementation of test, staging and production environments, as well as with the choices of which courses developers and system administrators should follow to be ready for the future. Follow up of the implementation and roll-out for the new SSO solution with Bull Evidian.

§  Advised CIO Belgium with the purchase of new software platforms (portal) and with the choice of a co-sourcing partner for future development of large projects.

§  President of the Technical Advisory Board (TAB) in which decisions concerning future IT directions/opportunities were set.

Technology: Hudson, Maven, Cobertura, LifeRay, Spring, Hibernate, Mule, Junit, Jira, Oracle, DB2, MQSeries,  ... (see gathered knowledge)

Now come the "extras", but nevertheless also important. Depending on your domain, the extras can be different, but there should be at least a section with your language skills and a section with your computer skills (if you are an IT-person, it should contain an overview of libraries, frameworks, tools, products, etc... you have experience with). Hobbies could be interesting, but it is not a must.

Although in the modern age of social networks like LinkedIn, where people can get recommendations, references are not a must, but can be added as a last section in the CV.

Layout & Style

Now that the content of the CV is covered, layouting should be considered. It is very important to make your CV easy on the eyes:

• Emphasize the section headers by using a bigger font in boldface for example 
• Use indentations to group information that is part of a higher level
• Use italics, underline or boldface to emphasize entries or important parts of a text
• Use tables to arrange similar information, such as language skills
• Avoid prose, use short phrases instead
• Be concise and to the point. 

As a side note: there is a EU initiative to make documents such as a curriculum vitae more transparant within Europe http://europass.cedefop.europa.eu/. It is also possible here to generate your CV based on your input.

Update 28/12: There is a follow up post called "Surviving a job interview"

Our new company blog

It took a while, but we finally decided to start a company blog. On this blog you'll be able to read all about our interests, from very technical stuff to how to run and manage a business, the projects we are working on and occasionally some more personal ramblings.

Hope you'll enjoy it and feel free to add comments whenever you like.