Job seekers are frequently advised that an interview is not just for prospective employers to see if you, the interviewee are the right fit, but also for the interviewee to see if they find the prospective employer to be a right fit. Every prospective employer should give the interviewee the opportunity to ask any questions they might have. You should be leery of any interview in which you are not given sufficient time to ask questions. Clearly, prospective employers who do not make time for you now certainly aren't going to be more considerate after you are hired. In fact, companies will never treat you as well as when they are looking to hire you. Generally, the better you are treated during an interview, the better you will be treated during your employment. As such, be sure to leverage the opportunity during your interview to get answers to the following 11 questions:
- What is your background? Were you promoted from a technical role, or a business role?
- Do you have a favorite book about technology and/or management?
- What ticketing system(s) do you use?
- Do you have a formal Disaster Recovery (DR) plan?
- How often do you perform test restores?
- What is your inclement weather policy?
- Why are you looking to hire? Are you back-filling this position, or is this position new due to growth?
- What does your unit testing and QA procedure look like?
- Do you have a change management process? What does that look like?
- What role does this position serve in the company?
- What does your patch management cycle look like
For some reason, there is a pervasive myth that if you are an expert in a given field, you are qualified to manager others in that field. Nothing could be farther from the truth. It is not a manager's job to be an expert in their field (This is the role of a Subject Matter Expert [SME]), instead it is a mangers job to be an expert in personnel management. Management should be seen as a role parallel to engineering, not a role which is over engineering to which one is promoted.
This leads to two types of companies: Companies that understand that personnel management is an entirely different discipline than engineering and companies that do not. You want to be working for the former. This is because a manager who was hired for his or her people skills and expertise in organizational management will be far more pleasant to work for than one who was promoted for their technical expertise.
By inquiring as to the background of your interviewer (who is presumably your prospective manager) you can determine the management philosophy of the company and individual you are interviewing with. If you are not interviewing with your future manager, this should be cause for concern. While it is not uncommon to first interview with a hiring manager or an HR person, at some point during your interview process you should be interviewing with your future manager. If you do not, this is a cause for alarm as you have no idea if you will get along with your future manager and you may not make a good fit for the team that they run.
If you find that a manager has been promoted for their technical expertise, before you write them off completely ask:
Asking this question will tell you a lot about your future manager. You want to be sure that your manager is an expert in management and has considered their management philosophy. This helps to avoid authoritarian managers who motivate and manage by fear. Far better are those managers who motivate and manage through loyalty. Managers who have not even taken the time to ponder this very basic question about management style are far more likely to be the former type of manager instead of the latter. Managers who motivate employees and manage through loyalty are often far more capable of introspection.
This question also allows you to determine if your future manager knows anything about management. For example, a manager who has read books like "The Mythical Man Month" or Gene Kim's "The Phoenix Project" and responds with one of these as their favorite tells you a great deal. For example, they know that adding people to a project does not necessarily speed up that project. They know the importance of measuring work and determining where their bottlenecks are and they know the Three Ways of DevOps. Managers like these are a rare unicorn, possessing both technical expertise and capabilities in personnel management. These kinds of managers have probably made a career shift from a technical role to a managerial one - perhaps getting a masters in business by taking night classes.
On the other hand, if your prospective manager respond with something like Kōnosuke Matsushita's "The Path" or Ken Blanchard and Sheldon Bowles' "Raving Fans" or a similar tome, this tells you something completely different: This manager probably has formal training in management or business, but probably does not have much experience with the challenges in management within the technology field. While they know how to work with and motivate people, they may have very little understanding or sympathy for the difficulties of technology. Explanations of issues or outages may sound like technical jargon or mumbo-jumbo to this person which they may see as just means masking excuses for poor performance in some cases.
Or, if your interviewer responds with a book from the O'Reilly series, "Beginning Linux Programming" or the "TCP/IP Bible", this tells you that this individual was most likely promoted out of the field and has little experience in management. They may have made very little effort to try to improve as a manager or understand the role that they have been placed into. Instead of managing, this person may demonstrate very little ambition for betterment in their new role and attempt to continue doing the duties of their previous role, leaving their employees without direction or shielding those employees from upper management.
While ticketing systems can seem like a drag and a mechanism for "the man" to control every little detail of your time and make sure that they are squeezing every ounce of productivity out of you, believe it or not, ticketing systems are your friend. While tracking your Time-On-Task can seem ominous, it is important that managers keep track of how much of their employee's time is used in order to maintain an optimal Pareto efficiency. Good managers will know that you can't achieve a 100% or more utilization without suffering productivity decreases from their employees and instead will target around 90%.
But without tracking your time, your manager can't do that. If they don't know that 8 employees are having to achieve a 97% utilization and your backlog of tickets is still growing, they don't know it's time to hire. Simply put, tracking your work helps achieve a good work-life balance for you if your manager is using this data correctly.
Asking what ticketing system is used tells you a lot. First, if they use 3 ticketing systems as one employer I worked for did, then they are using none of them properly. Conversely, if they have no ticketing system and work out of E-mail, then you can be confident that they don't have it together enough to be able to tell how much work they have and manage their workforce appropriately and in either of these cases your work-life balance will suffer. Finally, a good ticketing system will have the ability to track time against a requester and against the systems impacted. You want to be able to trend which server is constantly breaking, or which annoying users is always putting in tickets and wasting team time. This allows you to identify and remediate trouble areas within your organization or find areas of growth which may need resources directed towards them. Similarly, a good ticketing system will have team queues and allow teams to have a digital Kanban board for managing their workflow.
Few things are as important within an IT organization as scalability and redundancy. Scalability ensures that an organization has thought not just at the small scale, but a large scale as well. As things scale out, they sometimes encounter architectural challenges; particularly when scaling geographically. Companies that need to think at large scale generally indicate they have seen growth and are healthy. There is nothing worse than an app hitting a brick wall in terms of scalability and having to pull long hours in order and re-architect an application and to overcome design challenges that could have been prevented by simply doing the job right in the first place
Similarly, redundancy ensures that in the middle of the night when a server's disk does fill up and the server goes offline or a power outage occurs, you are not receiving phone calls at 3 AM. It guarantees that the application and hardware fabric is robust enough to elegantly handle failures without causing an emergency. This also ensures minimal outages which can be stressful even during business hours, let alone during the middle of the night or during the holidays.
Asking about a disaster recovery plan is a great way ensure that a company has scalability and redundancy. Ideally, their DR plan will be tested periodically using a DR exercise. I once worked for a company that moved offices and during the office move, they simply simulated a disaster. Everyone went home and telecommuted for the week while a moving company moved the entire office. One week later we all started showing up at the new office and during this time, our customers didn't even notice. They had built a solid enough architecture with enough scalability and redundancy to be able to accommodate that. Not all organizations have.
A company that has planned for DR is a company that has A) redundancy and B) can scale their redundant environment in an emergency to make sure systems stay online.
Often times, backup procedures are not followed - and this is more common than you might think. Asking about test restores ensures that a company has it together enough to A) have backups and B) has the luxury of enough funding and time to actually validate those backups from time to time and ensure they can be restored with minimal-to-no downtime. Backups are like insurance. No one plans for data loss, so this is often the first thing to suffer when staffing gets tight or a team gets overloaded. This can be a canary in a coal mine in terms of how well management has it together. When test restores go out the window, you know that an IT team is beginning to face challenges in either organization or time available to service workload.
While not very important if you live in California, for those who may live in snowy climates or other areas with extreme weather (like hurricanes and tropical storms) it is important to know if your employer is considering your safety. In the IT field, we have the the ability to work from home for a day or two. In fact, some studies show we may even be more productive when working from home.
Weather-related accidents contribute to 7000 deaths, 800,000 injuries and 45 million dollars of damage each year. An employer who is considering this and tells you to stay home for your safety and work from home instead of coming into the office is bound to be a good employer. This kind of employer sees you as a person, instead of just a mechanism for generating revenue.
This question is a great way to suss out if a former employee left due to discontent with the position. Ideally a company will be hiring due to growth instead loss of a dissatisfied employee. If the previous employee was unhappy, there is a chance that you will be too. If the employer cannot answer this question due to their HR policies, the most likely cause is that the previous employee was fired for performance-related issues.
Inevitably, most IT organizations do at least some amount of in-house development. For some, this is their revenue source. Ensuring that groups follow a full battery of automated testing which validates that all features and functions operate as expected is a mark of a healthy IT department. For those companies that develop a software based product, this kind of testing and Quality Assurance is essential so that the service that the IT team provides is less likely to see outages and bugs.
While change management may seem like mundane and unnecessary paperwork, it is important to make sure that changes 1) do not collide and 2) happen within convenient time-frames. Unmanaged changes can often happen at times which mean that if there is a problem with a change, you will be woken up at a very inconvenient time once a problem is finally discovered or you may end up working late or during a holiday or vacation due to a failed change. A well defined change management process will go a long way towards ensuring a good work-life balance for employees. The best change management will integrate automated unit testing results and human checks to prevent mistakes. In fact, automated configuration management systems like Puppet or Chef are the single biggest way to prevent mistakes. Machines don't make mistakes; humans do.
Knowing what role your position will serve within a company is very important. Roles that fall under cost centers and expenses within an organization will often be squeezed to reduce expenses and maximize profits. This can often result in sub-par equipment or deploymentswhich ensures that there will be more time spent maintaining and supporting the environment. Conversely, IT departments which are associated with profit centers are responsible for the success and revenue generated by a company. While this can be stressful during outages which will directly impact the bottom line, it also helps to ensure that when IT requests resources that are sincerely needed, these are not denied in a cost saving bid. Furthermore, organizations which silo into Operations, Networking and Development teams can often become embroiled in turf wars. When these teams are consolidated and operate in concert, success for one is success for all groups while headaches for one become headaches for all.
Good organizations should have a patch management system. Great organizations will patch monthly and will ensure that patches go into a QA or staging environments first and systems are checked for issues. Then these patches should be promoted to production. Typically, you will find that unhealthy organizations do not find the time to keep up on this monthly maintenance task.
No comments:
Post a Comment