Archive

Archive for the ‘Interview’ Category

Interviewing Tips: The Interview Anti-Loop and the Warren Harding Error

April 22nd, 2010

A couple non-traditional considerations when preparing for a software development interview.

Prepare for the Warren Harding Error, Thin Slicing, Snap Judgements, and rapid cognition.

The Warring Harding Error as described by Malcom Gladwell:

Many people who looked at Warren Harding saw how extraordinarily handsome and distinguished-looking he was and jumped to the immediate – and entirely unwarranted – conclusion that he was a man of courage and intelligence and integrity. They didn’t dig below the surface. The way he looked carried so many powerful connotations that it stopped the normal process of thinking dead in its tracks. The Warren Harding error is the dark side of rapid cognition. It is at the root of a good deal of prejudice and discrimination. It’s why picking the right candidate for a job is so difficult and why, on more occasions than we may care to admit, utter mediocrities sometimes end up in positions of enormous responsibility.Blink: The Power of Thinking Without Thinking

As Developers (and Generation X / Yers) we tend to buy into the ideal that “on the internet no one knows your a dog”, an ideal that’s been seared into our minds by Sesame Street and the like. An ideal where sunny days, chase the clouds away, where knowledge, technical skill, and communication should outweigh appearance – a place where being a dog, human, or giant harry elephant should be irrelevant. Unfortunately that’s not reality. Clean up for your interviews, put away those circa Cobain sneakers, and pack in the facial jewelery. Warren Harding (considered one of the worst US presidents) may have been elected based on his appearance. First impressions matter.

Beware of the Interview Anti-Loop

The Interview Anti-Loop as described by Steve Yegge:

when I was at Amazon … We eventually concluded that every single employee E at Amazon has at least one “Interview Anti-Loop”: a set of other employees S who would not hire E. The root cause is important for you to understand when you’re going into interviews, so I’ll tell you a little about what I’ve found over the years.

First, you can’t tell interviewers what’s important … they believe they are a “good interviewer” and they don’t need to change their questions, their question styles, their interviewing style, or their feedback style, ever again. …

Second problem: every “experienced” interviewer has a set of pet subjects and possibly specific questions that he or she feels is an accurate gauge of a candidate’s abilities. The question sets for any two interviewers can be widely different and even entirely non-overlapping. …

The bottom line is, if you go to an interview at any software company, you should plan for the contingency that you might get genuinely unlucky, and wind up with one or more people from your Interview Anti-Loop on your interview loop. If this happens, you will struggle, then be told that you were not a fit at this time, and then you will feel bad. …

And then you should wait 6-12 months and re-apply. That’s pretty much the best solution we (or anyone else I know of) could come up with for the false-negative problem. – Get that job at Google

Don’t Trash Former Employers and Employees

One final bit of advice that’s often overlooked. Avoid talking badly about past employers and coworkers. If you had an unfortunate string of bad career experiences, consider hiring a therapist, or telling your Mom about it. The job interview is not the place to retrace or reflect on past personal struggles, and it’s not the place for trashing former coworkers and employers.

Author: Adam Kahtava Categories: Interview, Musings Tags:

Transparency: How Much is Too Much?

March 7th, 2009

Gary Vaynerchuk offers this piece of advice:

The only way to succeed now is to be completely transparent, everything is exposed, everything you do – Gary Vaynerchuk

For most web / knowledge workers, transparency is key to cultivating an online presence – today, your online presence (your Google search results) is your resume, everything you do online is fair game – your search results (or lack of results) generally reflect whether you're an overall good-person, experienced, or a bit outdated.

A reassessment: last month the faltering economy finally hit home – I was out of work. While search for a new job, I was surprised that most potential employers (nearly all) were looking me up on Google. From Google they'd land on my blog, my Twitter account, flickr, and so on. In one of my interviews I was told of an unfortunate candidate that had questionable content and photos online – this was a deciding factor in his no-hire decision. This had me feeling a little uncomfortable and begged for a reassessment of my level of transparency.

Randy Pausch once said:

I'll [hire] an earnest person over a hip person every day, because hip is short-term, earnest is long term – Randy Pausch

I echo Randy's sentiments. If you're an earnest, authentic, and good natured person, then transparency can be a huge asset. You should be exposing everything you do! Well… maybe not everything, there's little value in knowing what you ate for lunch, or when you're sleeping / awake – practicing some self moderation and making use of your inner monologue is recommended, because excessive transparency can bleed into white noise.

no matter what remember the web is NOT Las Vegas. What happens on the web does NOT stay on the web. I'll bet this guy wishes he'd have remembered that. – Arcanecode, Guard your credibility

With applications like Twitter and Facebook it's easier than ever to be transparent, but do we run the risk of being too transparent? How much is too much?

Author: Adam Kahtava Categories: Interview, Musings, Personal, Twitter Tags:

Strange Interview Questions === No Job

June 18th, 2008

I was asked a series of questions during an interview that I’ll never forget.

The interview was at a successful company in the process of growing from a start-up. They offered a fantastic work environment, each developers got dual LCD monitors, state of the art machines, fooze ball, and to top it all off, they had a cafeteria with gourmet chefs  – I even had lunch there, it really was good food! It could have been a great place to work, but… the interview left me running for the door.

Some of the unnerving questions:

Do you smoke? Does anyone in your family smoke?

It turns out that they had a strict no smoking policy written into their contract. Yup… You had to sign, that you and your family will remain smoke free (including second-hand smoke) for the duration of your employment.  While I don’t think smoking is smart, and can see some benefits of having an explicit no smoking policy – still… this question didn’t seem right.

Potential benefits of a strict non-smoking policy:
More productivity (no cigarette breaks for employees), an odour neutral working environment, fewer employee sick days, cheaper corporate health insurance, and it could filter out potential drug users.

Draw backs:
Rapport with the interview team was immediately shattered, it’s probably illegal to ask this question in the first place. It was an invasion of privacy (if you’re demanding this, what’s next?). It felt very Orwellian (would they have Big Brother monitoring us too?), confusing (how can I control second-hand smoke?), and just weird (would I be fired if someone planted a pack of cigarettes in my desk?).

Do you play video games?

There was another sigh of relief when I answered “Not really”. I don’t play video game – well… aside from playing Tony Hawk on my classic Play Station every 6 months or Pong on my cell phone. I have better things to do than play video games, even if it’s doing nothing – like watching the paint peel off my wall (clearing my mind). Seriously though, I’ve watched family members and friends drain their lives into video games, as a result I’m not crazy about video games (but the Wii is fun). This question, like the previous was another negative hit for my employment prospect.

Potential benefits of having non-gamers as developers:
Better rested and more productive employees (they wouldn’t be staying up all night playing World of Warcraft), fewer sick days, and more focused employees (web surfing for game tips would not be an issue).

Draw backs:
Being a gamer doesn’t say anything about your performance as a developer. I started to get the impression that productivity really matters to this organization. I felt confused (why is this so important? Is there something they’re not telling me?), and it was another blow to privacy (why do you care if your employees play games?), and a blow to trust (will I have to answer questions like this everyday? I’d like to maintain some freedom, what if I decide take up gaming?).

Do you have a problem with being at work at 8:30 sharp every morning?

Now scenes from A Clockwork Orange are flashing through my mind – I’m being strapped in a chair, eyes pried open, hands chained to a keyboard, I’m being interrogated on the events of last evening, followed by a nicotine breathalyzer. OK… they didn’t embrace flextime. This organization was not a good cultural fit, too many weird questions, interview was officially over in my mind.

Potential benefits of a regimented routine:
You know when your employees should be at work.

Draw backs:
Going to work could feel like boot camp or the army, demanding rigid hours could imply a lack of trust in your employees, demands like this would certainly engender turnover, and companies with high turnover are bad places to work because there’s a cost for turnover.

Some smaller companies might like to know their candidate at this level, and if that’s the case then take them out for a couple drinks or dinner – try to learn these questions, don’t outright ask them. Questions like these might hurt the reputation of your organization, after this interview I was resisting the urge to run for the door.

What kind of interesting interview questions have you been asked in the past?

Author: Adam Kahtava Categories: Interview, Musings Tags:

Getting a Job at Google: A Web Developer Fizzbuzz

May 24th, 2008

Back when the web turned 2.0, AJAX was all the rage, and gas was cheap, a Google recruiter contacted me. We worked through a couple screening interviews – I explained how I was a .NET / ASP.NET / C# developer with some experience with Java and PHP, I described how C# was somewhat similar to Java. Things went great, I moved on to the next step of the process – writing code (a JavaScript widget for Gmail) with a 2 day (weekend) hard deadline. At the time I was wearing JavaScript diapers, but tried the exercise anyways – I'm still convinced the recruiter confused my Java / C# experience with JavaScript. Anyhow…

The Google Web Developer Exercise:

Web Developer Exercise

Attached are three states of a new contacts widget. This widget will be used across Google and may be anywhere on the page. Designers will also use this in mocks for usability tests. Create the HTML, CSS, and JavaScript for the widget as described in the image. Your solution must work in Firefox v1.5+ and IE v6+. Bonus points for a solution that degrades nicely on older browsers.



After my first attempt, I concluded that:

  1. My JavaScript knowledge was embarrassing
  2. Dynamic programming languages like JavaScript using prototypical inheritance were awesome – as a monocultured .NET developer I had sorely been missing out
  3. Framework Web Developers (ASP.NET, Ruby on Rails, and so on) aren't really Web Developers – we depend on a framework (an API) as a crutch, where the law of Leaky Abstractions is very real, and often when it rears it's head we use our golden hammer (our multipurpose language of choice), but there are better tools at hand
  4. Web Developers claiming n years of experience need to at least know JavaScript, CSS, HTML / XHTML, a server-side language, and some XML / XSL – NOT just a single multipurpose language or framework
  5. Innovation can only happen when you become one with the technologies surrounding your realm – for example: Jesse James Garrett probably would not have publicized AJAX had he been an exclusive ASP.NET developer. Diversity is essential for innovation

In retrospect this exercise is brilliant, it's a more complex derivation of a Fizzbuzz exercise, which effectively weeds out the knowledgeable candidates from the n00bs. JavaScript is notorious for being one of the world's most misunderstood language, many developer (and the ASP.NET Framework) still use JavaScript techniques from the old days of Netscape. For example: <a onclick=”return false;” …, or <a href=”Javascript: do something;” … are common DOM Level 0 inline techniques that should be avoided. These techniques have been replaced, but finding developer that use these JavaScript techniques can be hard.

By having a developer complete this exercise you effectively determine that the they understands these concepts:

  • Cross browser compatibilities and work arounds for both JavaScript and CSS – with a preference given to feature detection (object detection) vs browser detection, an understanding of the different event handling models between browsers
  • An understanding of the separation of concerns – JavaScript, markup, and CSS should be separate files, or at least separated within the document
  • Event registration and listening – DOM events, the different browser event models, no inline level 0 event declarations, no pseudo JavaScript protocol inline declarations within markup
  • An understanding of functional languagesclosures, namespaces, lambdas, recursion where necessary
  • Node manipulation – creating, swapping, removing elements
  • Knowledge of non-obtrusive JavaScript techniques
  • Importance of modular / compartmentalization of CSS and JavaScript – defensive programming techniques that minimize the risk of interfering with other scripts and elements within the page, part of the non-obtrusive techniques, how to avoid global variables
  • An understanding on how to debug JavaScript from both IE (link) and Firefox (link)
  • JavaScript code conventions – naming conventions, statement conventions
  • CSS naming conventions
  • General DHTML / AJAX techniques – showing and hiding elements
  • A gauge on their attention to details and UI design intuition – what their gut tells them to do when things aren't spelled out

My latest crack at the Google Web Developer Exercise:

You'll have to visit my site (view this blog post outside a RSS reader) to view the code in action.

The code: GoogleExercise.js, index.html, GoogleExercise.css

Today I'm wearing JavaScript training wheels – feel free to comment on the code, I'm always looking for improvements and suggestions. I did take a couple shortcuts on the CSS / UI side of things as I was focusing more on the functionality.

Using one of the AJAX Libraries (like jQuery) we could certainly do this exercise in significantly fewer lines of code.

Today I still think about Getting that job at Google, Yahoo!, Amazon, or Microsoft. How well do you know JavaScript?

Update: I redid the Google Exercise using jQuery and more semantics, you can find my latest version here: The Google Exercise Revisited: Semantic Markup with jQuery.

Roles: Questioning My Identity in the Software Realm

December 8th, 2007

For the past couple months I've been drinking in (watching) the videos on the Yahoo UI Theater. After watching Peter-Paul Koch's (PPK of Quirksmode) video: Fronteers: Guild of Front-End Developers, I've been questioning my place in the software sphere. PPK makes the point that organizations should have clearly defined “front-end engineer” roles for maintaining standard compliant sites, maintaining conceptual integrity of the product / web application, and so on. This is a common train of thought, in the Mythical Man-Month (1975), Fred Brooks suggests that a software team should be run like a surgical team where specialized roles like the surgeon, nurse, aesthetician, and so on be delegated and adhered to throughout the duration of the project. Most organizations don't have these roles defined, but that's another story.


Above: PPK's Video from the YUI Theater.

The categorization of roles and topic of role is common in most companies and often discussed during interviews; most interviewers or companies want to know what position you play and how you'll fit into their organization. The interview question is generally mutually exclusive, your choices could be: a Generalist, a Specialist, a Software Architect, a Business Logic Developer, a SOA Developer, a Database Analyst / Programmer, a Graphic Designer, a Web Developer, a Business Analyst, and so on… However; everytime I answer this question I can never respond with an answer that I'm satisfied with, I always feel as though I'm pigeonholing myself into some stereotype or category. From my experience some of the stereotypes associated with roles are: “Web Designers”: artsy, can't really grasp difficult problems, “Generalist”: technically competent, doesn't understand good user interfaces, often doesn't understand the big picture, and so on. It's kind of like someone asking: “what kind of music you listen to?”, but only letting you choose a single genre, then having someone psycho analyze you based on your genre selection – speaking of which, here's a link that already does this (kind of): Which genre of music fits you.

This all brings up the question of identity. What am I, what is my role, what single role do I feel fits my skills and experience? Perhaps I'll start labeling myself as an information technology (IT) addict. :) I love, eat, dream, breath, drink technology. I have an obsession with the Software Development Lifecycle, I always have a couple IT related books on the go, I listen to IT related podcasts while commuting, I like writing code, I write code after work, I write code on the weekends, I contribute to online forums, I edit IT books, I like using Test Driven Development, I like front end work, I like back end work, I like it all.

Author: Adam Kahtava Categories: Interview, Musings, Software Tags:

Interviewing: The Good The Bad and The Ugly

September 5th, 2007

Interviews are usually fun, interesting, and always different.  Last month I went through a number of job interviews for a software developer / consultant positions – my wife got a fulltime position in Calgary, we moved, I needed a new job.

Some of the types of interviews I attended:

A pop-quiz / quiz show type interview, where the interview shook my hand, sat down, and proceeded to run through lists of questions procured from the internet – afterwards, I was able to find the question list the interviewer had quized me via the internet. This went on for an hour or so, when the interviewer ran out of questions he abruptly stood up, shook my hand, and left me to find my way out. 

Reflections: from what I observed, their corporate environment differed significantly from what was presented on their corporate webpage. In addition their interviewer and interview style contradicted their corporate statement of values and corporate culture. I should have been better prepared, but without a specific job description it was difficult to prepare. Many red flags were raised – most large companies should have a formal interview process or an HR department, shouldn’t they?

The second worst kind of interviewer is the Quiz Show Interviewer. This is the kind of person who thinks that smart means “knows a lot of facts.” They just ask a bunch of trivia questions about programming and give points for correct answers. – Joel Spolsky: The Guerrilla Guide to Interviewing (version 3.0)

A write the code first interview, where I was greeted by a nice HR lady, shown to a room with a computer and given a test with a one hour deadline. In the second interview I was met by two developers, I was given a couple white board questions, and asked resume related questions.

Reflections: this company seemed to have many different job descriptions for the same position, the nature of the work didn’t vary, but the educational requirements did – their job descriptions individually targeted a High School, a College, and a University Grad. Their job discription was vauge, and wide – it seemed like they were trying to pull anyone in. From what I observed, the staff looked exceptionally young, the interviewers looked tired, and the computer I wrote my test on was old. I did like that I had to write code through the interview process, but again many flags were raised – mature employees are a sign of a healthy work environment, tired interviewers with transparent skin don’t give off good first impressions. 

the behavior of interviewers influences their decision to accept a position, … despite the fact that companies are increasingly desperate for talent, many are becoming their own worst obstacles when interviewing qualified candidates. Among the sort of behaviors that adversely affect job seekers’ willingness to work at a company are interviewers who are aloof … – http://www.management-issues.com/2007/8/9/research/poor-interviewers-driving-away-talent.asp

Anyhow; I’m now happily employed, and working with a great bunch of developers on an exciting Agile project based around Test Driven Development (TDD)  / Unit Testing, Continuous Integration, and the .NET Framework!

Author: Adam Kahtava Categories: Interview Tags: