Skip to main content

Questions you might want 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're signing up for building a product that has no impact, and the prospects for you gaining professional growth are little at best.

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".

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? 
  • How are the interfaces going to look like?

"... 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 challanges.

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?


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


Popular posts from this blog

Sending out Storm metrics

There are a few posts talking about Storm's metrics mechanism, among which you can find Michael Noll's postJason Trost's post and the storm-metrics-statsd github project, and last but not least (or is it?)  Storm's documentation.

While all of the above provide a decent amount of information, and one is definitely encouraged to read them all before proceeding, it feels like in order to get the full picture one needs to combine them all, and even then a few bits and pieces are left missing. It is these missing bits I'll be rambling about in this post.

Dependency Injection - The good, the bad and the ugly

The Good
Dependency injection (DI, a.k.a IoC - inversion of control) is a well known technique to increase software modularity by reducing coupling between modules. To provide the benefits of DI, numerous DI frameworks have arisen (Spring, Guice, Castle Windsor, etc.) all of which essentially give you "DI capabilities" right out of the box (these frameworks tend to provide a whole lot more than just "DI capabilities", but that's not really relevant to the point I'm about to make). Now, to remove the quotes around "DI capabilities", let's define it as a DI container - a sack of objects you can manipulate using a provided API in order to wire these objects together into an object graph that makes up your application.

I've worked on quite a few projects employing Spring, so it will be my framework of reference throughout the rest of the post, but the principles and morals apply just the same.