Questions you might want to ask your potential employer

Today's recruiting managers have become salesmen, and oftentimes will be willing to tell you more than a few "alternative truths" to get you onboard.
During an interview, one of your main goals is therefore to get wind of any such suspicious statements, and try to get to the bottom of them by kindly asking for more information.

If you're told you have a once in a lifetime opportunity to join a new team that is building from scratch a product that's helping millions of users do this and that, take a minute to think things over and consider getting (satisfying) answers to the following questions.

"It's a new team ..."

Joining a new team often associates with using cutting edge technologies and charting new territories. However, the term "new" is subject to abuse and may not always mean what you think it does.
Unless you are going to be the first or second engineer on a team that was formed a couple of months ago, the team is hardly new. Now, if you're going to be joining an existing team, it is crucial to first understand what this team has been up to so far. In particular, what this team has built so far, and how many people are using its product.
If the team you're contemplating joining has been building a product for over a year, and has zero people using it (hence it's referred to as a "new" team), something is definitely wrong.
If no one is using it, you may be signing up for building a product that has no impact. Having neither users nor impact for a prolonged period of time can box you in an environment where you have no actual production going on,  and without real-world production knocking on your door you can only learn so much. This puts your professional growth at risk.

Consider asking:

• How long has this team been around?
• Is this the first iteration of this product?
• How many people/teams/etc. are already using this product?
• How automated is the build & deployment process? 

"... building from scratch ..."

Building new platforms is super exciting. You get to choose the technology stack, the architecture, the design and what not. The new system you're going to build is never going to suck the way that legacy one did back at your old workplace.

The promise of building things from scratch rather than dealing with some horrific legacy system may sound very appealing to engineers looking to make an impact. However, more often than not, the new system will not be deployed in a vacuum, and is likely to be required to integrate with the rest of the organisational ecosystem. When enthusiastic engineers' desire to build a new product meets the organisational ecosystem, there may be quite a few casualties. You need to make sure you're not one of them.

While you're sold on the concept of picking your tech stack, it should be clear that you will probably still be bound by the organisational ecosystem. If you would like to use technology X, which is not currently supported by the organisational stack, you will either be denied, or asked to integrate it with many of the subsystems around, including the kind of legacy systems you are running away from by applying for this job. It is therefore important to get at least some notion of how much integration work is going to be done as part of developing this product "from scratch". It may also be beneficial to ask the recruiting manger for his views on these integrations, particularly on things like ownership and (mid-long term) schedules. If your team will be solely owning all these integrations, due to now + 3 months - proceed with caution.

Consider asking:

• What is the existing organisational technology stack?
• What will it take to add X or Y to this stack?
• How does the build & deployment process in the organisation look like?
• What are the subsystems the team's product will be integrating with? 
• What responsibilities and processes will your team own?

"... helping millions of users do this and that ..."

Scale and (big) data engineering is something people are eager to get experience with. These fields pose a great number of fascinating engineering challenges, and the job market is craving for people capable of dealing these challenges.

Recruiters and recruiting mangers alike will often try to make statements about impacting millions of users, but such statements are best taken with a grain of salt. If you are hired to build a new system, it may be quite a while before you have any users (internal or external), let alone millions of them. Even if the company you're contemplating joining does indeed have millions of users, chances are, your system will be gradually exposed to any of them. Companies are (rightfully) reluctant to risk serving customers with new products that have not been battle tested.

Consider asking:

• What are the business use-cases to be implemented using the product you'll be working on?
• Are the users of the product you'll be building internal or external? How many of them?

Epilogue

Hopefully, asking the right questions will provide candidates with enough information to form an independent point of view of what the position they are offered may involve.
If the recruiting team paints too pretty of a picture, you could be getting salesman'd.