What should I do if I get a job offer, but don't really understand what it is I would be doing?

Question

I had interview for a position with a small managed IT company. It was recommended to me by a friend, but he didn't really know the details of what they did. The job posting was rather vague and focused on the technologies the candidates should know.

In the interview I eventually asked, "what exactly is the goal of what we do here?" one of the interviewers replied "get tickets closed". I think he was trying to be funny. Honestly the fact that I would have to report to him and he can't explain something simple like that was a deciding factor in me declining the job offer. I guess I should've tried asking again.

I asked if there was a list of products we supported. I was told no, but most would be available on a Google search. This too was rather vague.

Am I jumping to conclusions in thinking that these people would be difficult to work with since they can't explain things? In interviews are there other questions I can try asking to get a better sense of what the work is actually doing? I could have tried contacting them the next day and asking "I'm still a bit unclear what I would be doing in this role. Can you give anymore details?" (maybe the second time they wouldn't answer "what our clients want").

Answer 1

An interview is a two-way road, where the organization evaluates the candidate and the candidate evaluates the organization and the opportunity.

Having a bit of humor is good in a conversation, but not at the cost of clarity. If they cannot make it clear to you about your roles and responsibilities, that's a red flag. I'd probably do the same what you did.

Answer 2

First of all, it helps to research what a "managed IT company" does. That type of company is in the business of taking over specific parts of client IT and running it for them. Where I live, a "managed IT company" mostly installs equipment, software, and networking and keeps all that running. There are two types of such companies: one that operates on a "break - fix" model where they take over anything that the customer has and responds to when things "break". The other dictates the equipment that the client should buy and has a yearly subscription model where they do everything for a flat fee.

So, the question is: what were you interviewing for? If you are interviewing for an IT position, then you are a technician and expected to know how to install, diagnose problems, and fix them. How broad is your experience with all the different things that you could run into?

Edit (add the following):

So, what to do when a company doesn't tell you what the job is?

1. Ask what the company's mission or goals are.

2. Research what similar companies do. This is where a search engine comes in. If you had searched for "what does a managed IT company do", you would have found at least a definition of what that type of company is.

3. Look on job rating boards for that company or similar companies to see what people in that job complain about.

4. Ask if there are security clearances needed. For example, at one place I worked, a nearby aerospace company was notorious for not telling people what the job would be - because you needed to have a security clearance to know. All you knew going in was that they paid real well and once you got the clearance, you wouldn't be able to talk about your job at any local "watering hole".

5. Finally, trust your gut. If I don't feel comfortable with the people I interviewed with, that would be a real big red flag about the job.

Answer 3

The answers you are getting to this question are likely because the support model that this firm offers to its clients is not strictly bounded. The answers seem vague and open ended, but they might actually be trying to communicate specifically that the work itself is highly variable, as opposed to poorly understood.

E.G, the firm is contracted to solve IT problems for its clients, and operates as an internal IT firm might operate, meaning your demands and boundaries of support might vary depending on whose ticket you're working.

If this firm typically contracts to small businesses, this model is poorly defined but sustainable - You will be dealing with random secretaries / white collar office workers and their bosses who primarily use MS Office and off-the shelf hardware, ± a few programs that might be more specific to their industries, and so their technical needs are not terribly complex.

Generally, organisations that have technically complex needs are smart enough to staff their own IT, and probably don't contract out to a separate firm to do it.

Is it worth taking a position that has this kind of variability in expectations?

For the most part, you can view this role as basically being the in-house IT guy for a small business. There likely isn't much room for advancement, the pay probably isn't great, and there will be a cap on what you can learn in the position.

However, you will cut your teeth on real problems and build practical experience troubleshooting and honing soft-skills such as expectation management.

If this is early in your career as an IT professional, it's a decent place to start but I wouldn't try to make a home with this firm.

If this is later in your career as an IT professional, look elsewhere.

Answer 4

Since I wasn't present, I can't really comment on the actual answers the person gave. If at all, they seem a bit flippant to me, which may or may not be a red flag. Bosses are human too, and it isn't even clear if that will be your superior at all.

In my company (which is a not so small "full stack" IT company), I never interview candidates for one specific task, project or customer. I always look for people with certain skillsets or characteristics. In my own team, I could onboard anyone who basically does technical IT work with a strong focus on container/cloud or CI/CD based technologies. I would in fact take anyone who has strong skills or convinces me due to character or other good impressions. I of course select strongly on intersections with the technical topics that interest myself and which I am good at myself - i.e., if I'm a Unix guy, I would send .NET/C# specialists on to my colleague who revels in that. That said, people occasionally ask me what their first job would be if they accept, and I never can answer that.

In my case, we have lots of people and plenty of projects; people and projects are matched on skills primarily, organizational units only secondary if at all. There is a constant movement of people between projects; and projects come and go as well. The employment process usually takes at least three months here (due to people generally having a three month notice period in my country), and lots of things could change in that time.

In my experience it's best if they understand all of this from the get-go; some people thrive in such an environment, others really want to know what concrete product they are responsible for. Those may be best served not to apply at a job with a generic IT company, but maybe try to get into the IT unit of, say, a medium-sized engineering firm; in this case it would be clear that they are working on product X of that company.

From your question, I have the impression that they were hiring people for a generic "application management service" team - those support arbitrary applications for customers (and often many of them at the same time), and really do not care which individual applications those are.

In those operations circles, "closing tickets" is indeed often not just a tongue-in-cheek joke, but actually quite high on the list of priorities; unlike in more development/project-oriented teams, there are often service level agreements where it can cost real money if tickets are not closed quickly; and often closing the ticket quickly (while staying just within some contractual ruleset) is more important than improving the actual software. There may be separate change processes to fix root causes, but the first line support teams need to work quickly to get customers running ASAP. In my company we manage certain applications where certain problems incur real-world costs of upwards of 100.000€ or more per hour.

In contrast, the mindset in (agile) development often is more along the line of trying to plan the workload so that it has a realistic chance to be fulfilled in time - it is (hopefully) not event/ticket based. This is quite important for many developers (rightfully so), and putting such a person in a time-critical application management team might be the worst you can do, for everyone involved...

Answer 5

In your situation, I would ask for more money. Ask for a much larger salary. Ask for a significant signing bonus.

If you ask for enough money, they will probably ghost you (which can be considered a good thing). If they pay the signing bonus, then you can rest assured that you will be well compensated while you figure out what they really want (also a good thing). Heads you win, tails you win - the CEO's gambit.

Answer 6

While the vagueness of their answers might signify they're not at liberty to go into too much detail with non-employees or someone under a non-disclosure, it also seems to signify they're not all that well organized. Until you can get clarity, you'd probably be best to avoid them.

Answer 7

You asked the wrong question :)

Not a bad question, just the wrong one for what you indicate you want which seems to be

What will I be doing?

Examples of types of questions you want to ask for your needs as you described them are:

• What are some typical tickets that I would work on ?
• What is a typical hour spent doing ?
• What tools are used to work on tickets ?
• What is an recent example of a ticket that I might typically work on ?
• What would I expect to be doing after a week in the job? After a month? After a year?
• How would I succeed and thrive in the day-to-day activities involved in this position ?
• How could I exceed expectations in this position ?