Interview is a Job

An interview process should not end up in a situation of a cat in a bag. A friend of mine is going through an interview process, and I observed his line of thought and decision making. These are my observations along with what I think about technical part of interviewing process in particular. 

Job Interview is an art. Interview process puts both sides, interviewed and interviewer, on a spot. Interviewer is trying to find the right person, which might include, but not limitted to personality fit, professionalism, experience, etc. Employer typically has a few things that they are willingly sharing with an interviewed such as working hours, benefits, type of work, and other pieces of information that you migh or might not find out through public channels. Interviewed is looking to find out as much as possible about working conditions, expectations, overall compensation, fit into his/her personal work/life balance, etc. There's always a technical interview, that frankly I don't accept anymore in the shape and form it happens these days. More than that, I think that interview and technical question(s) are a good way not only for interviewer to determine if candidate is the right candidate for postition, BUT also for an interviewed help to determined if eployer is the right place to invest time into by taking the position. My friend`s test is a good example for that. He was given a mini project to build, a web application, that is using a framework he's never dealt with. Initial "business requirements" of half a page of bullet points were given to him. He approached the test and here's the conversation we had I'll try to analyze.

Let's see what we've got so far

1. Both sides have a good vibe about personality fit and other conditions
2. Technical interview that resulted in an assignment that has a completion deadline
3. Assignment with business requirements

Looks great, but... not so rosy as it looks. Assuming #1 is acceptable on both sides, #2 and #3 have a lot of hidden gems for both sides.

Interviewer: 

• Time boxed assignement, abiity to complete work with time constraints
• Candidate demonstrates his/her ability to solve a given problem showing how they approach requirements and solve those
• Demonstrate technological knowledge
• Submit working solution

Interviewd - RED ALERT. Why you're asking me? What's wrong, this is a way we've done it for years. Exactly. Just because it was done so, doesn't mean it was done properly. And this is why I think this an indication of a poor potential work place:

1. Solving a test problem requires work to get done in a limitted amount of time. Does one "gets the job done" or "designs and implements as if it was production code"? If your future employer is not clear about that requirement, what exactly you're suppose to present? And if you don't clarify that, shame on you, means you're not serious about what you're doing. Assuming you got that answer, there are a few options, where 2 are obvious. A) you solve it quick and dirty to "get the job done" - then what is that your future employer is looking for, because code quality that is not. B) you create a monster project that is geared towards all the "illities" (maintainability, testability, etc.) just to calculate tax or find the shortest path, which will be packed with complexity without showing how you actually think.
2. Technology knowledge. I see it in a different light - there's a whole, it needs to be filled in, and you're the candidate to be the filler. What if you solve it in a different technology? What if you have a better perspective? Does that mean your employer is constrained to "one truely way" and nothing else?
3. How much business requirements are actually business if there's no email/phone number to connect with a business user to clarify requirements? How often did you do that in the real world when wanted to work in a collaborative environment? How can you expect to work at a place were you can talk to business when during excercise you are dealing with techies only? Hmmm, perhaps it's not the air that you breathe ;)
4. Submit working solution. This one is in particular interesting. Requiement like "self contained without dependencies" tellms a whole story about working place and begs for questions, serious questions. If I submit "working code" not via ZIPped package, but as a URL on a publicly hosted repository, would that work? if I have dependency on a 3rd party open-source library to cut the useless ADO access or CSS work, is that breaking some holy rules of a company? Does that mean "not invented here" syndrome is already there and these are warning signs for an interviewed to take in account?

As an interviewed it is YOUR responsibility to bring this questions up, or don't be surprised to find your self in the process again with yet-another-employer. Remember, employer is interviewed as much as a candidate. Your job starts way ahead of signing a contract, it starts with an interview.