In my experience, things you can ask include:

What's the history of this first project I've been assigned to?

Who are the most important customers, or types of customers?

What's the risk tolerance (unless you've been told Move Fast Break Things)?

Things you usually can't ask directly, but need to learn quickly:

Is this a meritocracy? If not, what other factors matter?

What types of actions are perceived as throwing a co-worker under the bus?

Is most of my job to figure out what my job is (i.e., exploring how I can contribute most effectively)?

* How is the team/project internally structured? Where are the projects internal leaders?

* Is there task specialization or expertise on the project? How is that identified or assigned?

* What certifications or other external qualifiers are important for this team/project beyond the minimum required?

* How is product quality defined in writing. How is it enforced?

* Does the team set arbitrary definitions and measures or does the team make determinations according to multiple factors? This question is deceptive. It’s almost always better to have things defined in writing, even if wrong, than to frequently defer to ad hoc qualifiers.

* If after fully onboarding I have a tremendous amount of availability where would you like to see that time invested?

* If this is a consultancy how do I identify the principal stakeholders at the client and what are their success criteria? It’s often not about making the client happy but accelerating the client towards some goal not immediately clear within the consultancy.

* What are their success criteria currently technical constraints on the team that determines velocity? Almost always this is a people problem rebranded as a technology or training problem and this question should cause panic alarms in your brain.

Where you ask is as important as what. You will learn things at a coffee break, a smoke break or at the bar that you would never know otherwise, especially if managers aren't within earshot.

I use one question to suss out these sorts of things. It's only valuable when talking to the devs that work there, not when talking to managers.

The question is "what is your workday like?" The direct answer to that question isn't as important as the conversation that it starts. Ask two or three people and you'll get a good idea of how things really work there.

Sure! Here are five 5-word content suggestions for the keyword "What should you ask to understand a new team and company?":

Questions to understand team dynamics.

Key company culture inquiry tips.

Understand team goals through questions.

Ask this joining new company.

New team integration questions guide.

For more info you can visit this blog.

Visit: https://www.octalsoftware.com/blog/team-task-management-app

"What's the process to receive a change request/defect report/whatever from the customers, develop it, and deploy it? For some small but non-trivial change, and how long would it take?"

Follow up with the same regarding a trivial change.

Adjust to fit the company and the nature of their work.