Find your Focus

When I first started out as a junior developer, I was working on two parallel projects – A database entry system and very early website.  Both were exciting, both were interesting and on both I scratched the surface on what I was doing.  I realized at that time that I enjoyed doing both but that I couldn’t do both well and learn everything I would really need to become really great at it.  So I thought about what I wanted to focus in on and learn about more – web-based development or databases.

I chose web-based development and then started the path down VB, ASP, Cold Fusion, PHP, COM, .NET, etc, etc.  I was focused on an area, not a language – this was key – I didn’t want to understand the pros/cons of languages and how they could interact with each other better.  I wasn’t able to ignore databases completely as working with any of the above was a requirement, but I didn’t focus all my learning energies into them at that point in time.  Later, at one of my jobs, I had the opportunity to join the Database group and immerse myself in that technology for a few years which helped me gain a further appreciation for that role and apply it my skills in Software Development (I knew I wasn’t going to be a DBA, but I could be more knowledgeable in that area).

What’s all this mean?  Then and especially now, as a junior starting out, I needed some focus and I had to assign that to myself.  I seeked out jobs that narrowed on web development, I read every book I could to get up to speed and be more useful in meetings, I worked late on projects and when not on projects I tinkered with new ideas and concepts I was learning.

Being a Junior developer is not easy – everyone is asking for everything and you’ve only got so much experience under your belt.  There is an unwritten onus on every junior developer when hired – you need to put in extra time and effort to get into the game – if not said, it’s there, if said, well now you know.  When everyone is coming at you with a myriad of requests, I found having your own focus was a great way to showcase where you want to be and get to – people can connect the dots to where you’re headed and when you’ll get there (and if they can’t they are doing it wrong) and if you’re doing things right – they’ll want to be there when you connect the last one.

 

How not to Prep for an Interview – Part II

bad_interview_questionsSo part deux (two) in this epic series of how not to prep for an Interview.  In our first part to this mini-series the focus was on the Interviewee and what that individual needs to do to prepare for an interview.  But like any road, it runs both ways, and yes, you the interviewer need to be just as prepared.

There are some old adages that you know within the first 30 seconds, 5 minutes, the colour of their shoes, etc, etc that you are going to hire someone that walks through your door.  People are very proud to state their track record of being able to identify the flowers from the weeds very quickly and save time.  Is any of it true?  I can’t say for sure, I know if the candidate has followed the advice in Part I – they have a much stronger shot at getting through the interview, if however they don’t, well now you are in a hole that you need to start digging yourself out of pretty fast.  Not easy, but possible.

Be Prepared

Yes, you the Interview must be prepared.  You need to put your best foot forward because you, and perhaps the others in the room are the ONLY window this candidate has into your organization.  They are evaluating everything you say as gospel, as the organization and when they talk to their friends about the interview later on, you are who they will reference because you are all they will know.

Introductions and Salutations

  1. Introduce yourself – yes I am guilty on this – I’ll say all the niceties of welcome, can I get you anything and than start right into #2 completely forgetting to introduce myself and what my role at the company is.  Kind of hard to introduce yourself half-way through, so something I try to work on.
  2. At this point, I walk the candidate through the process of what we’re going to do today – I’ll explain who we are, here about some of your experience, do some technical questions and then some work on the whiteboard.  Not only does this help keep it straight in your mind, it puts the candidate at ease knowing what is coming next.
  3. Write out a quick paragraph on your organization – the highlights, etc. – don’t brag, we don’t need a 20 minute introduction into the glory of InterNode Inc.
  4. Explain specifically what your group does and how you guys work.  Especially in Software Development – candidates always, always want to know how the teams are setup, what kind of projects they will be working on, what technology stack do you work on.
  5. Tell them what you are looking for – we need a developer who has a passion for technology, loves to try new things, is great working on a team or on their own.

Notice in number 4 – I didn’t have to say they know languages X, Y or Z – that’s up to you if you want to add in there, I personally don’t – you can teach anyone to code but teaching passion and dedication is much, much harder.

Start the Conversation

At this point the stage is set, you’ve given them the spiel on who you are, now it’s time for them to sell themselves to you.  Who they are, what they have done, how they meet your job requirements, etc, etc.  Usually at this stage is where I take a lot of notes and try to interject with small clarifying questions on what role they performed on which application and ask them to draw out the architecture (not revealing any trade secrets).  I find when you allow a candidate to draw out their accomplishments on the board, it makes them more comfortable and confident as they talk about their accomplishments.  My follow-up to this is where I really seek to gauge their thinking and approach to problem solving when I ask them what they would change in the architecture to make it better.  The guys/gals that are really on their game, are the ones that suggest changes on how things could be better – they know it’s not perfect, they know there are new technologies and options out there.  When someone says they wouldn’t change a thing, that’s an X, you can always make something better.

Know thy Interviewee’s Level

So all of this is from the slant of interviewing someone technical – a developer, quality assurance tester, business analyst, etc.  Depending on who they are, you need to understand their position and level that you are hiring for.  At one company I was involved in a crazy hiring spree and I entered the room thinking I was interviewing for an Intermediate Software Developer position – I nailed the candidate hard – he failed on everything.  Later I found out he was interviewing for the junior position, which I didn’t know, my bad – I ran through it in the wrong way and had a completely different set of questions prepared that I would have answered.  The level of the position is incredibly important, I expect much more out of Senior resource then Juniors, there is an investment cost when they start and I’m constantly weighing that in my mind when running through the Internet.

The Whiteboard

Oh so scary, get up on a board and write stuff.  I have seen people sweat buckets over this despite reassuring them we don’t expect 100% syntax adherence, 10 years ago… maybe, but not now.  There are so many IDEs out there with Intellisense it is very hard for someone to know all the syntax corrections because some happen even when you are not looking.  My personal preference is to let them code the problem in their most strongest language.  I’m a C# guy myself so I can run those whiteboards pretty well, but if it gets into Java or some of the new JavaScript models – I’ll bring someone in to review the code – they have a much more keen eye and can spot subtle items which I might miss.  So when on the whiteboard, make sure you have an expert on hand either before or after to review what was done by the candidate.  The Whiteboard serves a dual purpose to see if they, as a potential employee, would be willing to stand up in front of a colleague and draw out ideas.  This speaks to confidence and collaboration.

Questions, Questions, Questions

Whether it’s a 15 or 60 minute interview – always give your potential candidate the opportunity to ask questions at the end.  Some might be more elaborations on what was already discussed, some totally out of left field, but still the opportunity must be there.  From a grading perspective, this is the last opportunity a candidate has to impress me because it shows they were listening and are interested in the position.  Also, it gives the candidate one last opportunity to sell themselves if they made some mistakes early on in the process.

So, that’s it, that’s how I run my interviews for the world to see – I’ve had some good interviews, some bad ones and some very ugly ones – but I think at the end of the day I’ve always tried to give the candidate an opportunity to sell themselves while being a good representative for whichever organization I am currently working with.

How not to Prep for an Interview – Part I

0x600I’ve been trying to figure out how to name this post because I knew from the get-go that it was going to be done in two parts where the viewpoint in Part I is from that of the person being interviewed (the interviewee) and Part II is from that of the person conducting the interview (the interviewer).  Both perspectives are in regards to how one should not conduct themselves at interviews.

I’ve been involved in a least 100+ interviews, being on both side of the fence (more on the interviewer side) – can’t say 1,000+ and I am actually happy to say I have not had to do that  many in my lifetime.

When prepping for an interview (any interview, any job), the first question you should ask yourself is always…

Do I want this job at this company?

If the answers are any combination of “meh”, “not really”, “I don’t care”, “it’s not what I want” – then save yourself the time and energy and don’t apply.  All you are doing is wasting your time and the person’s time that is interviewing you.  And should you decide that later on, you’d like to work at this company, you’ve just created a bad impression with the company that when your name comes up again and you want to work there, they will look to pass you over (I would, in a heartbeat).

I’m not a fan of this “I’m going to throw my line in the water and see if I get any bites” approach to job hunting or the “I’m going to go and practice doing interviews at these other companies before I go for the real jobs” – why?  Why waste all that time, all those “fake sick” or vacation days from your company to go test all that out.  You most likely have friends in your field and the internet is a massive source of interview questions (especially on the software development side) – do all of that on your own time.

So now you want the job, the interview is scheduled, it’s time to prep.

Number One strike against any interview, showing up late.  Bad weather, not an excuse.  Sorry, bad weather happens all the time, prep for it.  If there is bad weather and the buses are running slow, pay for a cab, it costs $40 vs $5?  Ask yourself how badly you want this job and the $40 seems like a paltry expense.  By showing up late you’ve already put the seeds of doubt not only in the interviewer, but the receptionist at the desk – and you haven’t even done anything.  Same goes for being early, if you are there 10 – 15 minutes early, that is acceptable and welcome.  If you are there 45 minutes early, that’s a little problematic for the people interviewing you.  Should you get there early, go find a coffee shop, a bench, a chair, something.  Take your time, you don’t want to come off desperate.  A little early shows you are prompt and considerate of other’s schedules.

Number Two strike against any interview is the moment you sit down and you the Interviewer asks you if you know anything about their company and you say – “No!” or some gibberish answer about – “Yeah you guys build software right?”.  Companies invest lots of time, effort and money in promoting themselves on the Internet.  Information is readily available to you from your fingertips on that long bus or short cab ride.  Take the time to read it – if you don’t want to take the time to read it, cancel the interview, you really, really don’t want to work there.  Nothing burns me more than having to explain to someone what we do – before the Internet?  Sure, it was a lot tougher, you had the yellow pages, maybe financial reports that had to be requested, now it’s all open doors.  There is absolutely ZERO reason why you should not know what the companies product and services are, what they have recently been blogging about and what their latest press releases are before going to an interview.

Number Three strike is the candidate that can’t say no.  I’ve been known to throw out completely wrong questions in interviews, some completely ridiculous ones only so I can see if they will say no and not try to bluff their way through it.  It’s not to be mean, it’s not to make fun of something or have a good laugh afterwards – it’s to make sure that when they don’t know something, they will be honest and say I don’t know or you can’t do that.  Because in software and technology, no one knows everything, I don’t care what level of rockstar, ninja, samurai coder you are, you don’t know everything.  I do give exceptional bonus marks to those that say “I don’t know… but here is how I would try to figure it out”… well you just flew to the top of my list.

Show Passion.

You can see the thread going through this post, if you aren’t interested don’t apply.  I’m only looking to hire people that have a passion for what they do, if you don’t that’s cool, but I know there is someone out there that does and I’m willing to wait.  I’ll push back on recruiters for this very reason.  You might be a rockstar coder, but you might also be a jerk and think everyone else on the team is sub-standard.  For me, the guys/gals that show up early, love what they do, want to learn more, maybe don’t know all the answers – those are the people I want to hire.

Two best interviews I ever had, and people I subsequently hired immediately, were people that were not the best coders BUT they came to the interviews prepped with demo code have looked at what we were looking for, showcasing how they can learn and build new apps and apply their own sense of flare to it.  They knew the company inside and out (sometimes better than me).  They wanted it, they were hungry for it.  One guy missed a career fair, drove all the way out to our office to meet with me – that’s passion, that’s desire – he jumped to the top of the list.

You are interviewing at a company.

Lastly, and this is a sad one, Interviewees often times forget that they are not interviewing for a group but a company.  I have nothing but the utmost respect for our Office Managers, Administrators and Receptionists.  At the end of each interview I always ask them how they were when they came in, were they polite, were they rude.  Sometimes it’s a deal breaker – “they came in, demanded I hang up their coat and get a drink” – done, you’re out – no one is beneath anyone else and how do I know you won’t treat a junior developer in exactly the same way?  I don’t and I’m not willing to take the risk.

Now, what about technical skills you might say?  What about the gold that actually ships the product out the door?  All that is secondary to me, because if you have all of the above, we can teach you coding, we can show you performance and error handling what we can’t show you is any of the above.  I’ve hired people based on the above and they have turned into some of the best coders, team leads and managers I have ever worked with – the code didn’t get them there, all of the above did.