---

title: "Five (and a bit) useful questions to answer in your first week at a new job"
author: "Thomas Wilson"
date: 2020-10-10
draft: false
slug: "2020-10-10-five-useful-questions-new-job"
tag:
  - new-job
---

I've just had my first week at a new job (I'm now a frontend software engineer at [Oxwash](https://www.oxwash)), which is cool. I find first weeks intense because I have to balance a) the immediacy of being introduced to everything and everyone in "real life", i.e. not an interview setting, for the first time, and b) trying to convey your long-term personal and professional ambitions to your new bosses without sounding like a career lunatic or emotionless psychopath.

Managing long and short term goals is hard for humans to do, but worthwhile and rewarding when you get it right. Long term goals are rarely immediately relevant or present, it's not always easy to go from "I would maybe like to be an engineering manager" to an actionable thing. It's even harder to consider long term goals in chaotic situations, like when you're being introduced to new people, places, processes, technologies, terminology, and expectations. Plus the added complexity of trying to present yourself as someone who can totally stay afloat and cognisant during all the above.

But if I don't have a long-term idea of who I want to be, even if it's subject to change, I worry that I'll be nudged into doing entirely what's best for the immediate concerns of others or the company. I would rather that my personal and professional development come from a dialog between what others need me to do, and what I think I want to be doing.

For that reason, I came into the first week at a new job with a couple of personal and career-focused questions to help me understand myself and others. These questions ended up being really helpful to me, even if the answer to the questions is was a (polite) "can we come back to this later?".

These are the questions I arrived at when I thought about all these things. They could be riffed on to help find something useful to you, or taken verbatim. I don't think their usefulness is limited to the first week at a new job, nor do I think they necessarily need to be asked to anyone other than yourself. The act of answering your own questions is a good little meditation (and it's at least 50% of the reason I try to write so much).

So yeah, here are the five questions I came up with:

## Imagine 12 months has passed - what could I do that would bring the quality of my work from 'Good' to 'Excellent'?

There are a couple of dangerous implications with this question, especially in a first week: it implies that you are capable of doing excellent work. You may well be, but it definitely sounds like you could be over promising.

Despite that, I found this a useful question because it shows you how people understand, see, and value the kind of work you'll be doing. As an engineer, you'll get a different response to this question from people in management, product, operations, strategy, and tech. This is great - it shows you how the current tech team and offering are seen by the company at large, and how each person/team would define success.

Another little life hack for you is that people rarely have a well defined, concise response to this question. You're probably not going to get told "a 7.5% decline in response times over the next 12 months" (obviously great if you do). Take a note of these points, of what people want, and use them when you're talking about, planning, and polishing tech internally.

## What does the company look like in 12 months, five years, and ten years?

By default, your onboarding will give you a good idea about what you'll be doing immediately, maybe in the next 1-3 months. I found asking this question a great way to prepare me mentally for what I might be doing in the future.

Asking this question to anybody senior in product or strategy (even in C-Suite, if you can) will help you understand what you'll be working on if you stay at the company for a longer (in startup years) amount of time.

As before, this knowledge can help when planning and building software or roadmaps. Things will always change, and your software will always be somehow inflexible or caught off guard, but hopefully this question will help you minimise that.

This question is most valuable in early stage companies, because of the difference between present and planned situation is probably quite large. I have intentionally joined an early stage company, and while they're definitely no longer struggling for product-market fit (if that's even a thing anymore?), the chance that they have already streamlined and perfected everything by now is pretty close to 0%. This is great - you can use your knowledge you're gaining in answering these questions to help get them closer to that goal.

The caveat to this is that the uncertainty and unpredictability could mean that the longer-term projections or ideas are _just_ words. Customers, economies, investors, management, talent, and global pandemics are all winds that will guide your ship. Don't get tied to these ideas, and keep a pulse on it - things can change fast and you'll have to learn when to stick to what you've learned and when you need to learn new lessons.

## When, and how, is my performance going to be evaluated?

This is probably the most boring of the questions, because it is self-serving. However it _is_ important to know how you're going to be assessed, because you want little to no concern about losing your job, failing your probation, or what not. At the end of the day, any good company is going to be equally critical and supportive in examining your work, and feed back to you. This is naturally uncomfortable enough, and so the least you can do is make sure it's not happening against ❓mystery criteria❓.

The answer to this question won't be relevant until you start digging in to actual work. I would still recommend making a note of it. It might encourage you to keep a better log of work you've done, problems you've faced, ways you've improved, or whatever. It might let you know about the company's culture around sharing, feedback, and openness.

## If I'm struggling or have problems, where do I go?

This is the kind of thing you want to know before you need to know it. It might be your direct manager 95% of the time, but it's always good to have an idea about where to go if you were to have a problem with your manager.

Get a sense for which people are best for which problems: management questions, tricky technical work, variable mental health, and ongoing family problems will at some point affect your work. Understanding who needs to be told what, and what kind of support can be offered (internally or externally) is a good thing to suss out.

## What are your immediate team's backgrounds and interests?

Get to know your team, as much as this is _painfully_ obvious, it's surprisingly easy to forget in the chaos of starting a new position. Allow these conversations to happen naturally during your first couple of days working alongside your new team. Don't come in with forced or canned one-liners with your team, this is your first week not a corporate retreat.

I found it useful to get a broad idea about who my team is and what they find interesting. This goes for personal as well as professional interests. We're all complex, complete humans and you'll find something to bond about, even if it's just the weather, crowding on the underground, or the best kind of milk to have in coffee.

Knowing what people do/not know, or where they are/not confident could help you phrase future feedback or explanations in a slightly different way. I'm not always great at asking for explanations of basic terms when someone explains something at a million miles an hour, and I know some people feel similarly. Likewise, when you need feedback or clarity on something, it's good to know where to go in order to get it.

## Bonus Question: Does anybody have any dietary requirements or allergies?

If you're a cook or a baker you might want to bring in some sweet treats now, or in the future. It's always a good idea to know if anyone's going to be excluded, or mortally threatened, if you bring in a particular kind of baked good.
