8 ms·
Thanks for this, I do have some (EDIT: A LOT) other questions around this that I'll be asking. • What is your company's relationship with velocity? • Do you f
by bckr 5y ago
Thanks for this, I do have some (EDIT: A LOT) other questions around this that I'll be asking.
• What is your company's relationship with velocity?
• Do you find yourselves doing more slowing down to be more careful, or speeding up to win a competition?
• What slows you down?
• How do you accelerate?
• What is the expected time scale of a typical initiative?
• How many initiatives does a typical engineer work on simultaneously?
• How was a recent initiative measured for success?
• How do you know when to stop an initiative?
• How do you decide when to start an initiative?
• Describe the company's philosophy about planning work in terms of top down VS bottom up planning.
• In your experience, does the company behave in accordance with its philosophy?
• Describe your approach to on-call shifts?
• How many alerts does an engineer receive on a typical on call shift?
• How do you make sure that engineers are not succumbing to alert fatigue?
• Describe a situation where I am getting an alert as an engineer. What does it look like for me to successfully respond to that alert?
• How do you document the steps necessary to take when responding to alerts?
• How do you decide when to create a new alert?
• Do you have a central list of all alert policies for your system?
• How do you know that everything is working or not working in your system?
• How many subsystems do you have? How do you determine ownership of your subsystems?
• Describe your approach to observability and instrumentation.
• Can you show me your observability system?
• Can we pretend to solve a problem in the system together, using your observability platform?
• How do you do deployments?
• How long does a deployment take, assuming approval?
• How long does it take on average to get approval?
• How do you ensure code quality?
• What's your worst section of code? What makes it bad?
• Can you show me part of your codebase?
• What is your approach to onboarding new engineers? How long does it take to get a dev environment set up?
• What is your current architecture?
• How do you make architectural decisions?
• Where is the architecture going?
• What are the downsides of the current and future architecture?
• How much work is driven by “deep integrations”, in other words how much code supports unique partners?
• What is the onsite culture like? Do coworkers typically become friends?
• How many hours does the average engineer work per week?
• How many weekend days does the average engineer work per month?
• What is the typical cause of after hours work?
• How much time does a typical engineer spend in meetings per week?
• How many days off does a typical engineer take per year?
- codingdave 5y agoThis reads like a list of questions designed to avoid the things you hated about your past job. Which is totally understandable, but this is way too many details - you won't get time to ask all these. I'd try to narrow this list to more general questions that will still give you the answers you desire by letting them talk more about themselves and you taking on the burden of reading between the lines for details. Aside from being more time efficient, it also is better psychologically speaking - helping them to talk about themselves in a positive light makes you look interested and makes them feel valued vs. making you look cynical and wary.
- bckr 5y agoThanks for that feedback! I definitely do not intend to point blank ask all of the questions. Rather, it is a checklist of things that to find out about. > helping them to talk about themselves in a positive light makes you look interested and makes them feel valued I really like this thought. I'll definitely think about how to do that.