Questions to Ask in a Software Engineer Interview
Questions to ask the interviewer in a software engineer interview, for developers, web developers and computer science graduates who reach the end of a technical interview and are asked whether they have any of their own. They run in six groups: the role, how code gets written and shipped, on-call, the team, growth, and the company behind it. Many of the notes suggest a follow-up, and some say who in the loop is the right person to ask. If you only get five minutes, the first five are the ones to ask.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Role
What does a normal week look like for an engineer on this team?
Why ask it
Best asked of an engineer on the team, who can walk you through last week instead of an ideal one. A real week has named meetings, interruptions and quiet stretches in it, and "it varies, we move fast" has none of them.
What would I be working on in my first few months?
Why ask it
A team that is ready for you can name the project, or at least the part of the codebase and the person you would work alongside. If the answer is that it depends on what is on fire when you arrive, ask what the last new hire ended up doing, since that is the likeliest version of your own start.
What is the tech stack, and where would I spend most of my time in it?
Why ask it
Get the languages, the framework, the database and where it all runs, then ask which of them the team is moving away from. A stack in the middle of a migration means working in the old thing and the new thing at once, and that changes the job more than any single technology on the list.
What does success look like in this role after six months?
Why ask it
The useful answers are things you could tick off: a service you own, a feature in users' hands, a place on the on-call rota. 'Fully ramped up' is not one of them, so ask what ramped up means on this team. Whatever they name is likely what your first review is measured against, so write it down.
What is the biggest challenge the team is facing right now?
Why ask it
The answer is often the reason the role exists: a migration running late, a system that has outgrown its design, or too much roadmap for the people on hand. Ask whether you would be working on it or around it. If nothing comes to mind, ask what the team would fix first with one more engineer.
How much of the job is writing code, and how much is everything around it?
Why ask it
At senior levels the answer can be less than half, with the rest going to design documents, reviews and coordinating with other teams. Neither split is wrong, but it is better to hear the real one now than to discover it in your second month.
What did the last person in this role do, and where are they now?
Why ask it
Someone promoted out of the seat leaves behind a different job from someone who quit within months. If the role is new and there is no last person, ask who has been covering the work, because that is who will hand it to you.
Which parts of the stack would I need to know on day one, and which could I learn on the job?
Why ask it
A job advert can list every technology the team has ever touched. This sorts that list into what you would lean on in the first weeks and what they expect to teach, and it is a fair moment to say plainly which of those you have not used.
Would I work across the front end and the back end, or mostly on one side?
Why ask it
"Full stack" in an advert covers everything from an even split to a back end team that needs someone to touch the templates now and then. Ask where the interviewer's own last few tickets sat, which shows how the line is drawn here.
Who has struggled in this role before, and what tripped them up?
Why ask it
It asks about the way the job goes wrong instead of the ideal candidate, so the interviewer can answer without passing judgment on you. Whatever comes back, whether pace, vague requirements or working alone, is the thing to measure yourself against before you accept.
Would I join this team specifically, or be matched to a team after an offer?
Why ask it
Some larger companies hire engineers into a general pool and place them afterwards, which means the people interviewing you may not be the people you work with. If that is the setup, ask how matching works and whether you can speak to the team before you accept.
Is the work on one product or for clients, and how many projects would I have open at once?
Why ask it
A web developer at an agency and an engineer on a product team at a tech company can share a stack and have little else in common. On client work, ask who speaks to the client and whether your hours are tracked against a budget, since both shape the day more than the framework does.
What did your strongest recent hire do in their first three months?
Why ask it
A real person's first months are a better guide than a list of expectations. Notice what gets mentioned first, whether that is shipping something, asking good questions or picking up on-call, because that is what this team sees and rewards.
How do new engineers get up to speed here?
Why ask it
Listen for things that exist: a setup guide someone updated recently, a named person to sit with, a first task chosen to be small. Then ask how long the last new hire took to get a change merged, which shows whether the plan works.
Which parts of a computer science degree does the work here actually draw on?
Why ask it
One for a first job. Some teams reach for algorithms, operating systems or database theory every week. Many lean harder on things a CS course barely touches, such as reading old code and working in version control, and hearing which it is tells you what to brush up on before you start.
How much say would I have over how something is built, as opposed to what gets built?
Why ask it
On many teams the what is decided elsewhere and the difference lies in the how. If designs arrive already settled by a lead or an architect, the job is implementation, which can suit a first role and chafe a few years in.
How much of the team's time goes to bugs and maintenance rather than new work?
Why ask it
Interrupt work is the gap between the job as advertised and the job as lived. A team that tracks it can give a rough share. If nobody tracks it, what the person answering did yesterday is a truer sample than their estimate.
Is there anything about my background that makes you hesitate?
Why ask it
A closing question for the hiring manager, and only worth asking if you want the answer. It gives you one chance to address a doubt, such as no experience at their scale or a short stay somewhere, while you are still in the room. Some interviewers are told not to give feedback on the spot, so take a polite non-answer at face value.
Code
How is work planned here: sprints, kanban, or something looser?
Why ask it
The label matters less than what happens inside it. Ask how long a cycle runs, who estimates the work, and what becomes of a ticket that is not finished when the cycle ends. Unfinished work that rolls over quietly and unfinished work that sets off a meeting are two different amounts of pressure.
How does code review work here, and how long does a pull request usually wait?
Why ask it
Ask how many approvals a change needs and who is allowed to give them. If anyone on the team can approve, reviews tend to move, and if only two named seniors can, their holidays become your delays. Find out too whether a new hire reviews other people's code from the first week, which is a quick way into a codebase.
What do code review comments here tend to be about: style, design, or correctness?
Why ask it
Reviews that mostly argue about naming and formatting point to a missing linter and attention spent in the wrong place. Reviews that question the whole design mean that conversation is happening late, so ask whether designs get discussed before the code is written.
How long did your own last change take to get from first commit to production?
Why ask it
The number folds build times, review queues and release approvals into one figure, and because it is their own change they cannot answer with the policy. An hour and a week are both believable answers, and where the time went is the part worth hearing.
How often does the team deploy, and who decides when a release goes out?
Why ask it
What counts as often depends on the product: a web service can ship many times a day, while firmware, mobile apps and regulated software move slower for good reasons. The second half is the part to press on. If someone outside the team owns the release, ask how long work waits for them.
When a deploy goes wrong, how do you undo it?
Why ask it
A rollback that takes one command or one click makes shipping low stakes, so people tend to ship small changes often. If undoing a release means writing a hotfix and running the whole pipeline again, releases tend to get bigger and rarer, and nobody ships on a Friday.
Is there a separate QA team, or do engineers test their own work?
Why ask it
Both setups can work, so listen for who is on the hook when a bug gets out. A QA team can mean finished work sitting in a queue. No QA team means the tests are yours to write, and the tell is whether estimates leave room for them.
What does the test suite catch, and what kind of bug still reaches users?
Why ask it
The kind of bug that got through most recently shows where the holes are. A team that can name the category, such as data migrations, payments or one mobile client, knows its own weak spot. 'Nothing much gets through' is harder to believe than a named gap.
Can I run the whole system on my own machine, or do I work against a shared environment?
Why ask it
A setup that starts with one command gives you fast feedback. A shared staging environment can mean waiting your turn and debugging other people's half-finished changes. How many people share it is the number to get.
Is the system a monolith, a set of services, or something in between?
Why ask it
Neither is better in itself. With a monolith, ask how long the build and the tests take and how teams keep out of each other's way. With services, ask how many there are per engineer and what it takes to follow one request across them.
How much traffic or data does the system handle, and where does it strain?
Why ask it
Scale shapes what kind of engineering the job is. A product with a few hundred users tends to be feature work, while one under heavy load turns ordinary changes into questions about performance and migrations. The part that strains is likely where the hard problems, and the pages, come from.
Which browsers and devices does the team support, and who decides when to drop one?
Why ask it
In a web developer interview this is the scale question in another form. The oldest phone or browser still on the list sets how much of a week goes to testing and workarounds, so ask what it is and whether the list follows visitor numbers or one important customer's laptop.
How do designs reach developers, and how finished are they when they arrive?
Why ask it
A file with every state drawn, a rough sketch and a conversation over a desk are three different jobs for whoever builds the page. Ask what happens when a design turns out to be awkward to build, and whether the developer gets a say before it is signed off.
Who looks after accessibility and page speed, and is either one checked before a release?
Why ask it
A check in the pipeline, or a named person who tests with a screen reader, means the work is part of the job. Where both come up only after a complaint or an audit, expect to fit them in around feature work.
How does the team handle technical debt, and which piece actually got paid down this year?
Why ask it
Most teams will say technical debt matters, so ask for one piece that got time on the schedule and who argued for it. If nothing comes to mind, you know which side loses when the roadmap fills up.
How much of what I would work on was written by people who have since left?
Why ask it
Code whose author is still around comes with an explanation, and code whose author has gone comes with whatever they wrote down. That is ordinary at an older company. Ask where the reasons behind old decisions are kept, and whether estimates allow for the digging.
Where does documentation live, and how do you tell when it is out of date?
Why ask it
Every team has stale pages, so what matters is whether anyone can say which ones to trust. Ask what a new engineer reads in the first week and who last edited it. If the real answer is that you ask whoever built it, find out how much of that person's day already goes to answering questions.
If I wanted to bring in a new library or tool, what would that take?
Why ask it
The answer you want sits somewhere between 'just add it' and an approval committee. It shows how far the team trusts individual judgment, and how many past choices it is still living with.
How are engineers here using AI coding tools, and is there a policy?
Why ask it
This varies widely by employer, from a paid license for everyone to a ban on confidentiality grounds, so ask how it works there. The useful follow-up is how AI-written code gets reviewed, which shows whether anyone has thought past the purchase.
Who can see production data, and how would I get access when debugging?
Why ask it
With too little access, every investigation waits on someone else. With open access for everyone, you learn something about how customer data is treated. In a regulated industry there will be firm rules, and they are worth hearing from an engineer who works under them.
Do engineers here pair program, and when?
Why ask it
Teams range from pairing all day to never, with plenty in between that pair only when someone is stuck or new. If you learn best next to another person, 'rarely' matters, and if you need long quiet stretches, 'most of the day' matters as much. On a remote team, ask what it looks like in practice: a shared editor, a call, or not at all.
How close was the problem I just worked on to a normal day's work here?
Why ask it
Suits the last minutes of a programming interview, asked of the engineer who set the exercise. Some teams cut their problems from real tickets and others use puzzles nobody meets on the job, and the person who chose it knows which. Either answer leads into what a real task looks like.
What is the most interesting technical problem you have worked on here?
Why ask it
Engineers tend to enjoy answering this, which makes it a good choice when only a few minutes are left. Notice how recent the story is, and whether the difficulty came from a real constraint such as load, cost or correctness, or from wrestling with the company's own tooling. Either way it is a preview of the hard days in the job.
On-call
How does the on-call rotation work: how many people share it, and how long is a shift?
Why ask it
The arithmetic is the answer. One week in eight is a different life from one week in three, and a rota of three people has no slack when someone is ill or on holiday. Ask as well whether a shift covers nights and weekends, or only working hours with another office picking up the rest.
Does this team run what it builds, or does a separate operations team carry the pager?
Why ask it
Companies split this differently. Where developers carry the pager, a bad release is your own broken night, which changes how carefully people ship. Where an operations team carries it, ask how a problem gets handed back to the engineer who wrote the code.
Would I join the on-call rotation, and how soon after starting?
Why ask it
Some teams wait until you have shipped to the systems you would be paged for, and others add you within weeks. Ask whether you shadow someone first and who you can call when you do not recognize the alert.
What was the last page that came in overnight, and did it need a person?
Why ask it
One real page tells you more than a description of the rota. A full disk or a job that could have retried without help points to noisy alerts and broken nights. A real outage that was handled and then written up is the job working as intended.
How many pages are for something the team itself can fix?
Why ask it
Alerts that start in another team's service or with a flaky vendor wake you up without giving you anything to do. If that share is high, ask who owns getting it down.
How do you usually find out something is wrong in production: an alert, a dashboard, or a customer?
Why ask it
If the honest answer is that customers write in, monitoring is thin and on-call will involve guessing. A team with alerts it trusts can usually tell you which one fired last.
Which incident does the team still talk about, and what changed because of it?
Why ask it
The age of the story matters as much as the story. An incident from years back that ended in a new alert or a removed manual step means lessons stick here. If the telling centres on who did it, expect people to be careful about what they admit.
What do people get for being on call?
Why ask it
Practice differs by employer and by country: a stipend, paid hours, time off after a bad night, or nothing. Being told that on-call is usually quiet is not an answer to this question, so it is fair to ask it again.
Outside of on-call, are people expected to answer messages in the evening?
Why ask it
Keep this answer separate from the on-call one. A push before a launch now and then is one thing, and a standing expectation of evening replies with no rota behind it is on-call without the name. The last weekend the interviewer worked is a better guide than the stated policy.
Team
Who would I report to, and how do they like to work with their engineers?
Why ask it
If the manager is the one in the room, this becomes a question about their style: how hands-on they are, how they want to hear bad news, how often they expect an update. Ask how many people report to them as well. A dozen direct reports leaves little time for each one, however good the intentions.
How many engineers are on the team, and what is the mix of senior and junior?
Why ask it
A team of juniors under one stretched senior tends to learn slowly, and a team of all seniors may have nobody to hand the routine work to but you. Where you would sit in that mix decides which of those is your problem.
How would you describe the engineering culture here?
Why ask it
Asked cold, this gets adjectives: collaborative, fast, pragmatic. Ask for one recent decision that shows it, such as a launch held back for quality or a junior engineer whose objection changed the plan. When two interviewers reach for the same story, the description is probably real.
How does the team decide what to build next, and who sets the priorities?
Why ask it
Find out where a piece of work starts: a product manager's roadmap, a customer's request, an engineer's proposal, or a founder's message late at night. Then ask what share of last quarter's work was on the plan when the quarter began. A low share is not a fault in itself, but it tells you how often your week will be rearranged.
How long have the people on this team been here?
Why ask it
Tenure is a fact rather than an opinion, so it is hard to dress up. If almost nobody has stayed long, ask whether the team itself is new. If it is not, ask where the people who left went, and notice how much detail comes back.
Does the person who manages me also set the technical direction?
Why ask it
When one person does both, a technical disagreement becomes a disagreement with your boss. When the jobs are split, ask who wins when the manager's deadline and the tech lead's design pull in different directions.
How do technical decisions get settled when two engineers disagree?
Why ask it
Listen for a mechanism: a design document, a named decision maker, a tech lead who breaks ties. "We talk it through" is fine until the day talking does not settle it, and that day is the one to hear about.
Before a large piece of work starts, what gets written down, and who reads it?
Why ask it
A short design document that people comment on catches bad ideas while they are cheap to drop. The test is whether the last one changed anything: a plan that came out of review the same as it went in was a formality.
When did an engineer last talk the team out of building something?
Why ask it
This tests whether engineers here are expected to use judgment or to work through tickets. If nobody can remember a requirement being challenged and dropped, the role is closer to delivery than to design, which is worth knowing whichever one you want.
Who sets the deadlines, and what happened the last time one was missed?
Why ask it
A date set by the engineers who did the estimating slips differently from a date promised to a customer before anyone looked at the work. The telling part is whether scope was cut, the date moved, or people worked weekends.
How do engineering, product, and design work together week to week?
Why ask it
Ask who writes the ticket an engineer picks up, and how often it changes after work has started. Every handoff between those three is a place where work gets redone, so fewer of them usually means more uninterrupted time.
Which other teams does this one depend on, and how well does that work?
Why ask it
A dependency on a platform or infrastructure team decides how often you are blocked by a queue you cannot influence. Notice whether the other team is described by name and with some warmth, or simply as 'them'.
How do people ask for help here: in an open channel, by direct message, or at someone's desk?
Why ask it
Questions asked in the open get answered once and can be found later, while questions asked privately get answered again and again. On a remote team it also tells you whether you could be stuck for a day without anyone noticing.
What is work-life balance like on this team?
Why ask it
Asked that plainly it tends to get a plain 'good', so follow with something countable: what time people log off, how much leave the interviewer took last year, when the last crunch was and how long it ran. Rules on leave and overtime differ by employer and country, so ask how they work there.
Where does this team actually work from, and has that changed in the past year?
Why ask it
Ask about the team in practice instead of the policy: who comes in on which days, and whether decisions get made in the room on days you would not be there. If the arrangement changed recently, ask who decided and how much notice people had.
Is the team spread across time zones, and which hours overlap?
Why ask it
A few shared hours is workable. A team split across opposite sides of the world can mean a review takes a day each way and somebody's meetings are always at night, so ask whose night it usually is.
If I get an offer, could I talk to an engineer who was not on the interview panel?
Why ask it
A panel is the set of people the company chose to put in front of you. An unscored call with someone else on the team is a second sample, and the blunt questions about deploys and on-call are easier to ask there. A company that hesitates has told you something too.
Growth
What level is this role, and what does the next level expect that this one does not?
Why ask it
Titles do not travel between companies: a senior engineer at one can be mid-level at another. Get the level's name or number, then ask what someone one step up does in a normal month that you would not be asked to do, such as leading a project across teams or owning a system's design. That gap is the work you would need to be seen doing.
How did the last promotion on this team happen?
Why ask it
The published career ladder says what should happen, and one promotion shows what does: who put the case together, how long it took, and what the person had done. If nobody on this team has been promoted, ask how long the team has existed before reading anything into it.
What goes into a performance review here, and who writes it?
Why ask it
The inputs might be peer feedback, a document you write yourself, a list of shipped projects, or your manager's memory of the year. The more it leans on memory, the more your review depends on how well your manager argues for you in a room you are not in.
How often would I have a one-to-one with my manager, and what does it usually cover?
Why ask it
A regular slot that covers your growth as well as project status is a good sign. If one-to-ones are often cancelled, or are only a walk through the tickets, feedback tends to arrive late, often at review time.
Is there someone more senior on the team I would learn from, and how much time do they have?
Why ask it
A senior engineer who is booked solid with meetings will not be reviewing your designs. Ask how the last person who joined at your level actually spent time with them.
How many new graduates has this team taken on before, and where are they now?
Why ask it
A team that has brought juniors along before tends to have the habits for it: small first tasks, patient review, someone who notices when you are stuck. If you would be the first, ask who has agreed to look after you, and listen for a name.
If this is an internship or a graduate scheme, what happens when it ends?
Why ask it
Ask how the decision on a permanent offer is made, who makes it, and how far ahead of the end date you would hear. Schemes differ by employer, so ask how it works there and what the last intake went on to do.
Can I keep growing here as an engineer, or do the senior levels mean managing people?
Why ask it
Ask whether anyone currently holds a staff or principal title and what they do all day. A technical ladder that exists on a wiki page with nobody on its upper rungs is not a path yet.
Do engineers move between teams here, and how does that happen?
Why ask it
An internal move is how you change your work without changing your employer. If it needs your manager's permission and a waiting period, ask how the last person who tried it got on.
Is there time or budget for learning, such as conferences, courses, or trying things out?
Why ask it
The budget matters less than whether anyone spent it last year. A conference someone attended or a course someone finished is a real answer, and 'we encourage it' with no example is not.
What have you learned here that you would not have learned somewhere else?
Why ask it
One for a peer engineer rather than a manager. A quick, specific answer, such as running a system under real load or working with a particular person, tells you what this place teaches. If they have to think for a long while, that is worth noticing.
Company
How does this team's work connect to how the company makes money?
Why ask it
A team that can trace its work to revenue in a sentence usually finds it easier to argue for people and time. Platform and internal tools teams can be just as secure, so for those ask who their customer is inside the company and how that customer says what it needs.
How much runway does the company have, and what is the plan for the next round?
Why ask it
A startup question, and a fair one, since you are being asked to bet your salary on the answer. A straight figure in months also shows how openly numbers are shared with staff. At a public or long-established company, ask instead whether this team's headcount grew or shrank over the past year.
What is the plan for the next year, and what could knock it off course?
Why ask it
You are checking that a plan exists and that the person in front of you knows it. The second half matters more: reliance on one customer, a funding round or a pending reorganization is something you would rather hear about now.
Who speaks for engineering when the company sets its plans?
Why ask it
A CTO or head of engineering in the room where plans are made can trade scope against time before a date is fixed. Where engineering reports up through product or sales, dates tend to arrive already promised. The quick version is who the most senior engineer reports to.
Has the team been through layoffs or a reorganization recently, and what changed afterwards?
Why ask it
A fair thing to ask, and worth asking of more than one person. The detail that matters is what happened to the work of the people who left: whether it was dropped, or quietly handed to those who stayed.
How do users' problems reach engineers: do you see support tickets or talk to customers?
Why ask it
Where engineers read the tickets or sit in on customer calls, problems reach you in the user's own words. Where everything arrives through several layers, ask who decides which complaints become work, and how long one usually takes to reach the team.
How do you know whether something the team shipped was worth building?
Why ask it
Look for a metric, an experiment, or at least a conversation after launch. A team that ships and moves on has no way to learn which of its work mattered, and that makes it hard for you to show results at review time.
What made you join, and what has kept you here?
Why ask it
The joining story is usually polished, and the staying story is where the information is. If every reason for staying is about the people and none is about the work, or the other way round, you have learned which half is weaker.
What would you change about working here if you could?
Why ask it
The friendlier form of asking for the worst thing about the place, and people do answer it. A small gripe, like slow laptops or one meeting too many, is usually reassuring. Take note when the same complaint comes from two different interviewers, or when someone insists there is nothing at all.
What do you wish you had known before you joined?
Why ask it
Best asked of someone who joined in the last year or two, while the surprise is still fresh. It tends to bring out the unwritten things: how long access requests take, which team really decides, which part of the codebase nobody likes to touch. Ask what they would do differently in their first month and you leave with advice you can use.
What rounds are left in the process: more coding, system design, or meeting the team?
Why ask it
Tech interview loops vary from one company to the next, and a recruiter will usually tell you the format when asked. Knowing a system design round is coming gives you something to prepare, and it is fair to ask what each round is looking for.
What are the next steps, and when should I expect to hear back?
Why ask it
Save it for the last minute of the last conversation of the day. If a recruiter is running the process they will know the dates better than an engineer on the panel, so ask them instead. Once you have a date, you can follow up the day after it passes without wondering whether it is too soon.
Using your questions well in a software engineering interview
Practical guidance for the conversation itself
Match the question to who is in the room
- The hiring manager is the person for scope, on-call, promotions, and who left.
- Engineers on the team are usually more candid than a manager about review queues, deploy pain and technical debt, so save the Code questions for them.
- A recruiter can usually answer pay bands, process and dates, and usually cannot answer anything technical, so do not spend that call on architecture.
- A director or skip-level is the right person for funding, roadmap, and where this team sits in the company.
At the end of a coding interview
- Questions about the problem itself belong at the start of the round. The ones on this page are for afterwards, when the interviewer asks whether you have any of your own.
- A coding round often leaves only a few minutes, and the person opposite is a working engineer who has just watched you solve something. One Code question and one about their own week fits the time.
- A system design round is often run by someone more senior, so the questions about architecture, scale and who settles technical decisions land better there.
- If the round ran over and nothing is left, say you have questions and ask who to send them to. A recruiter can usually pass them on.
Working from a long list
- The groups run from the job itself (Role) through Code, On-call, Team and Growth to Company. Choose from the groups the person in front of you can actually answer. The first five in Role are safe with anyone in the loop.
- For a web developer interview, add the Code questions on browsers, design handoff, accessibility and page speed, and the Role question on the front end and back end split.
- Before the first round, mark the two or three answers that would make you turn the job down, and ask those early. The rest can wait.
- Spread the questions across rounds instead of repeating the same few. The exception is a question you ask twice on purpose, to compare the answers.
- Once you have an offer you can ask for one more conversation. Many of the Growth and Company questions are easier to ask then, when you are no longer being scored.
Asking without sounding like an audit
- Pick three or four questions per conversation rather than working through a list. One answer followed properly beats ten collected.
- Attach each question to something they already said. It reads as attention rather than interrogation.
- Ask for the last time something happened instead of the general policy. Specific instances are hard to answer with a slogan.
- Leave pay and vacation with the recruiter unless the interviewer raises them, and then be direct rather than coy. Next steps are fair to ask the last person you see that day.
Reading the answers
- Note where two interviewers contradict each other and ask the next person about it. That gap is where the real information sits.
- Enthusiasm about the product is not evidence about the team. Ask the same team question to three people and compare.
- If a routine question produces visible discomfort, that is data. One gentle follow-up is fair; a second is not.
- If an interviewer says they cannot share something, such as runway, revenue or why someone left, take that as the answer and move on.
- Write your notes immediately after each round. By the fifth conversation the answers will have merged in your memory.
Signals worth taking seriously
- Nobody in the loop can say what the last person in the role did, or what a normal week on the team looks like.
- Deploys are described as scary, or happen on a fixed monthly date for a product that lives on the web.
- There is nobody senior on the team, and the unstated plan is for you to be that person without the title or the pay.
- Every process question is answered with we are working on that, and no owner or date is attached to any of it.
- None of these settles the matter alone. Each is a reason to put the same question to one more person.