Thursday, September 30, 2010

Do you have any questions for us?

This age old question is usually asked in a disingenuous way at the end of interviews and is rarely viewed as an opportunity by applicants to ask questions (for good reasons most of the time of course, i.e. we are in a recession so we can't be too picky). Despite external conditions, I think it is high time people started asking some questions at least to get a sense of what they are getting into. I for one should have asked some intelligently worded questions to get a hint of the nightmare I was walking into; sure I am making more money and we are in a recession, but the place is Chernobyl. At times it feels like interviewers are not that sharp and are just Googling for the hardest questions they can find to ask someone; questions they could not answer themselves without looking up. Had I known what I know now, I would have tried my best to make amends with my previous employer or at least attempted to move across IT departments. Oh how I languish in this dysfunctional organization...
Anyway, enough of my ranting... what should we or could we ask without seeming like an antagonist before accepting the offer? I can only write about programmers (from here on referred to as IT) in this particular blog because that is what I do but can and will add questions others submit for other career paths. Before we answer the questions just raised, let's talk about some of the things you can do prior to interviewing:
  1. Find out about the company culture from insiders and people that have worked there
  2. Find out how integral a part of the company the role you are pursing will play
  3. Find out how much the company invests in IT and where they stand in terms of reputation and ability
  4. Find out how often they hire and what is the turnover rate
  5. Is it a sweatshop?
  6. Find out where they recruit talent (not too important and can be misleading but you should know)
These are just some of the many questions you can start thinking about before even walking in for an interview. Remember, if hired, you will be working with these people for the minimum of 8 hours a day and will absorb some aspects of the culture, good and bad, and will be working with the tools that are in house to get the day to day done. So, lets dive in to the six preliminary things to explore before approaching a company for employment.

Number 1: Find out about the company culture from insiders and people that have worked there

This can help point you to the potential good and bad qualities the company embodies. From investigating the culture, you may see a few things:
  1. You can see what kind of internal politics may exist
  2. It can also tell you whether there is a decent hacker culture (good hackers, i.e. good programmers/architects/designers)
This in no way is a silver bullet, but at the minimum you are doing your due diligence to determine whether it is a fit for you. If you have friends there that are happy and not leaving anytime soon, you may choose to not look too deeply into this. Working with friends is a cool thing and helps productivity.

Number 2: Find out how integral a part of the company the role you are pursing will play

This is important depending on what it is you plan on getting out of the job. If you are taking on this new role for more family time, time for school at night, more time for side work, or building a company on the side as our friends from 37signals suggest, then what you may be looking for is a role that is not too time consuming and intense. Do not step into an area where you will be building the equivalent of a rocket ship if you have outside interests you wish to pursue. You will hate yourself if you do.

However if the focus is to get into full-fledged career mode, and you are looking to grow in a new and exciting company, then you should be looking for a role in an area that will have a decent if not great impact on the organization. This should be in an area where you can flex your intellectual muscle and contribute to the bottom line in a way that is satisfying to you, the customers, the team, and the company. You will be looking to try new things, learn new technologies, new algorithms/methods, and work with a happy bunch of guys who just like doing cool stuff. This is the nirvana state; this is where we all want to end up whether it is working for ourselves or someone else. This is what I seek at the moment.

Number 3: Find out how much the company invests in IT and where they stand in terms of reputation and ability

The reason I mentioned this one is because of my current plight. I left an organization that placed a high value on its IT staff, despite IT being viewed as an expense and not a core part of the business. The end result of placing high value in IT was that they got more out of IT. This enabled them to build cutting edge platforms and frameworks that gave them an advantage. This technology was standardized within the company so all groups were able to use it, and it had great support and documentation. Applications were built quickly and easily in-house. Drawbacks to this of course are that the IT guys not building the frameworks and tool sets became highly specialized and are completely absorbed by all the in-house stuff. They can potentially lose touch with the open-source frameworks and tool kits over time. A win-win for the business, yet questionable for IT. One can argue that you can keep up with open source when you get out of work but I would argue that most people do not.

Coming back to my point, a company who just views IT as some sort of a utility or tool to use and does not invest or place value in that section of the company is bound to have the following symptoms:
  1. High turnover rate (bad for business and the product)
  2. Bring in bad developers, i.e. political scientists (those damn politically inclined employees!) masquerading as computer scientists
  3. Turnout buggy software and bad practices (this will ruin you in interviews as this infectious disease will take hold of you)
  4. Be very tactical and not strategic (not such a bad thing all the time as we cannot predict the future and should build for today's requirements; they call it software for a reason: it is flexible and can be refactored)
  5. Have a shitty vision and leadership
I had one Managing Director (MD) tell me that IT is viewed in most places a light bill, something you hate to pay but need to. These kind of statements are detestable to say the least. This sort of overt minimization demoralizes hard working smart people and leads to 1, 2 , and 3 above. Programming is very creative, dynamic, and fluid to say the least. It is very rewarding when you can take an idea and materialize it in the form of software. I think that this is exciting and is what drives me.

Number 4: Find out how often they hire and what is the turnover rate

If people are leaving all the time you need to know this. People leaving in droves from a company may be a sign of some nasty things taking place that people are running from. You may be walking into a land mine field. Please if you take none of my other advise at least consider this one. We all deserve to be in a decent place of employment.

Number 5: Is it a sweatshop?

If the culture is about ASAP, get it done now, we work around-the-clock crap, stay the hell away if you want any semblance of a life! If you like working in this way, all power to you but remember the company will probably forget this when it comes time to hand out the pink slips. In the words of the rapper Pharell: “You should think about it, take a second...”

Number 6: Find out where they recruit talent

Where they recruit talent tells you a few things:
  1. It tells you the caliber of people that you will be working with
  2. Allows you to investigate the kinds of people you will be working with indirectly by understanding the campus culture they can from (you can find out about the school culture through social networks and online resources). We are all, at the end of the day, the sum total of our experiences and products of our environment
  3. What kind of leadership will be emerging from the company in the years to come as these developers mature and grow. Please note though, that if the culture test fails because of extreme politics, it is likely that this talented pool of employees will either become highly political themselves or just leave and go somewhere else. True hackers hate politics and just want to work with good people having fun solving problems together and cutting cool code
Please take points like the last one with a grain of salt. Some people that go to Ivy league schools are not as great as their resume makes them appear. I worked with a few individuals from Ivy league schools that were shockingly bad and did not understand the fundamentals of comp sci. Also, the non-ivy leaguers tend to work hard because they are at a disadvantage from a recruitment perspective. They know their schools will not likely open any doors. They tend to work really hard to learn and are usually passionate about what they are doing. In the end though, it is hard to really rank people until you have worked with them and seen their output.

Questions to ask interviews/employers

So what questions should we ask after the interview? Here is a short list of questions we can ask (open to suggestion, these questions are just what I have thought of pretty sure you guys have better ones):
  1. What kind of source control systems do you use? You may think everybody is using this these days but you will be surprised. I know of a friend in Wall Street who works with a team that has special folders where custom scripts check timestamps for “check-ins” and promote code to production. They do not use source control at all. This is madness!
  2. How big is the team and how much are you planning to grow to? Is this a new team? (If it is not a new team and they are growing fast this can be a sign of people having quit in the past or were laid off or may just be a genuine sign of growth)
  3. What kind of work is the team doing now and what will the new team member be working on?
  4. What level of support does the team provide? Level 1, 2, or 3 or all?
  5. What technologies are you using currently and what will you be using in the future?
  6. How is the team structured? Do you have a technical lead? Are your projects tactical in nature or strategic? If tactical, will the focus ever change to strategic? (if all they are doing is tactical work, then you may be going in to a maintenance shop where real development may not be taking place and you are just bolting on new features or fixing bugs; but as Guido van Rossum points out code is often read more than written so it will probably be hard to get into fresh development but make sure you are comfortable with this. Code maintenance and development ratios should be balanced wherever you go)
  7. Do you have code reviews? Architecture reviews? (Signs of how much they value quality and strive to keep things clean; again within reason not incessantly everyday in the form of micro-management)
  8. What kind of work is coming down soon?
  9. Do you have a QA team?
  10. Do you have an automated build process in place?
  11. What are your release cycles?
  12. Do you split the team up between UI and server-side developers?
  13. Do you have an Business Analyst for requirements gathering or is your core development team in charge of this?
There are many more questions one can ask to try and understand what they are to expect before taking the job. You will not be asking all the questions but should select from the sample above and whatever the community submits and judge which ones make the most sense in your particular situation.


Follow me on Twitter mrosario2012

No comments:

Post a Comment