3 ms·

There are a lot of things you can ask for that will red flag an organization as a whole. Are you being given stock. Ask for a cap table and learn to read it.

There are a lot of things you can ask for that will red flag an organization as a whole. Are you being given stock. Ask for a cap table and learn to read it. Tell them your wiling to sign an NDA, and that you want to look at the repository. Tell them that you may need to ask follow up "who is who" questions to pin checkins. Code never lies. Embattled areas of code, and comments are great targets for your search. Ask about recent outages and technical issues. Are they having problems keeping things up and running. Ask about how they were identified and how long to resolve. Do they have documents for requirements? Wireframes, PRD's. Ask to see these as well. If they raise any objection to any of this, just ask for a reason. It might set off an alarm for you. It might be reasonable. Since you have some history with the other team leads, make a personal phone call. Start the call off that way (that its a personal call) and that you want to know the truth/history here because you have concerns. If there is something funny going on in the background one of them might just give you an honest answer.

codingdave 10y ago
But we are talking about interviewing for a leadership position. Judging the health of a place by how its current tech looks might be valid if you are just going to be a coder, but as a leader, you will be expected to identify and fix problems. So it is OK if there are problems. It is much more important to figure out how people communicate, how they are treated, how the other leaders think, what they want their culture to be, etc... If you can believe in a shared future vision, and participate in the process to move towards that vision, then the details of the status quo are far less important.
- mud_dauber 10y ago
  My sense of the problem is that it's not so much a tech stack issue and more of an operational, "keeping the train on the tracks" challenge.
  - HelloNurse 10y ago
    Personal problems, communication failures, and organizational issues are often reflected in code and technical choices. For example: - Something gets rewritten because requirements were lost or misunderstood. - The same error is repeated after being corrected. - A component is revised or eliminated, after having been developed too early based on guesswork and speculation. - Developer A commonly reverts developer B's code changes without explaining the reasons (or with insults). - There has been a messy, error-ridden merge between the clearly independent developments of two sub-teams. - In source code control, commits are allowed to lack a good description; only a few true believers "waste time" with messages nobody reads. - Unit tests for something that is approaching release were last modified, and left about 15% complete, six months ago. - After employee X left the company (or when the project devolved into crunch mode, or some other excuse) automation of builds, tests, releases etc. started to rot.

codingdave 10y ago

But we are talking about interviewing for a leadership position. Judging the health of a place by how its current tech looks might be valid if you are just going to be a coder, but as a leader, you will be expected to identify and fix problems. So it is OK if there are problems. It is much more important to figure out how people communicate, how they are treated, how the other leaders think, what they want their culture to be, etc... If you can believe in a shared future vision, and participate in the process to move towards that vision, then the details of the status quo are far less important.

mud_dauber 10y ago
My sense of the problem is that it's not so much a tech stack issue and more of an operational, "keeping the train on the tracks" challenge.
- HelloNurse 10y ago
  Personal problems, communication failures, and organizational issues are often reflected in code and technical choices. For example: - Something gets rewritten because requirements were lost or misunderstood. - The same error is repeated after being corrected. - A component is revised or eliminated, after having been developed too early based on guesswork and speculation. - Developer A commonly reverts developer B's code changes without explaining the reasons (or with insults). - There has been a messy, error-ridden merge between the clearly independent developments of two sub-teams. - In source code control, commits are allowed to lack a good description; only a few true believers "waste time" with messages nobody reads. - Unit tests for something that is approaching release were last modified, and left about 15% complete, six months ago. - After employee X left the company (or when the project devolved into crunch mode, or some other excuse) automation of builds, tests, releases etc. started to rot.