Questions that I would ask during an interview to determine if a given SE department is a good fit for my interests
Many of these questions are sensbile to ask regarding operations work as well.
By design, there is some repetition across questions, the goal being to feel out the full-context to a question. This is consistent with traditional practices surrounding surveys: a series of questions worded slightly differently can help you to attain a more thorough understanding of question responses, and weed out some of the 'baser' thoughts the survey responder may have.
- A healthy codebase that is fairly straightforward to work with. This includes well-structured && fairly-comprehensive testing, minimal cruft, sensibly named methods/classes/modules/arguments, etc.
- The existence and promotion of best-practices/standards such that 1) the codebase may retain its health, 2) SE programming skills are kept sharp.
- Minimal/non-existent after-hours responsibility for minor code breakage.
- Strong interfacing between SE's and story stakeholders.
- Proper distancing between management and story-pointing
- Management-driven promotion of cruft reduction.
- A culture that is strongly driven by good-code principles in such-a-way that these principles compete with speed-to-market concerns.
- Ease-of-use/good-documentation regarding development environment setup.
- Sufficient staffing
- Frequent production incidents
- Frequent after hours on-call problems
- No support from management to eliminate cruft
- Pressure from management to write code quickly rather than well
- Lack of department standards aimed to insure codebase health
- Management-driven story pointing
- Poor interfacing with story stakeholders, manifesting as a) stories that cannot be understood, b) follow-up that is unattainable
- Lack of standardization of development environments
- Lack of proper test discipline
- Compliance responsibilities without clear understanding of compliance expectations.
- Consistently insufficient staffing
- A department culture that avoids knowledge sharing
- A department culture that doesn't really care about "good code"
- A large portion of the codebase that is not human readable: poor naming conventions, mixed responsibilities among classes/modules/methods, tight and/or hidden couplings, etc.
- Minimal/no opportunity to work with different business-concerns/technologies/libraries/languages/etc.