Great opportunities for programmers and business people -- not great for business intelligence engineers or analysts - Business Intelligence Engineer Amazon Employee Review

The required skills for the business intelligence roles at Amazon have been, until recently, poorly differentiated. As a result, the skill sets of adjacent roles (e.g. data engineer to business intelligence engineer, business intelligence engineer to data analyst or data scientist) have had a great deal of overlap, which has made it difficult for business-specific roles to know which role to request in order to get someone with a desired skill set. The lack of distinction between duties of business intelligence roles has meant that managers often hire someone as one data role and expect them to do the work of another role (e.g. business analyst being asked to perform the duties of a data engineer by building and tuning Redshift tables and views). The resulting mismatch in expectations makes it easier to move laterally if you have been doing the work of another role, but makes it more difficult to get promoted, since your probability of successfully being promoted depends on adequately performing the duties of your role at the level you are in while also performing some of the duties for your role at the next level for the role. The mismatch in expectations is also a factor in attrition, because it becomes highly possible to do what was asked of you, at a high level, but to not get promoted because of the misalignment between what you were asked to do and what is expected of someone with your title. Much of the misunderstanding is not any manager's fault, but is almost to be expected when your manager fundamentally doesn't understand what you do. It is customary for Software Development Engineers (SDE) at Amazon to work under more-experienced SDEs who participate in code reviews and can provide mentoring in how to advance as an SDE at Amazon. Business Intelligence Engineers and Analysts more often work directly for business managers or customers who have hired them precisely because they can't perform the function themselves at the level need to operate their corner of the business. As a result, an SDE may have the opportunity to work for someone who is better than she is at estimating how long a piece of code will take to write, whereas a business intelligence professional might work for someone who doesn't even know what language they program in or how long it takes to produce a simple snippet of code in it. It is not in the business manager's role description to have to learn how the business intelligence engineer does her job-- only to be able to gauge how "accurate" the results are-- but it means that business intelligence roles have to drive their careers and proactively find their community to get better at their job here. This isn't necessarily a bad thing, but it is something of which you should be aware before you come here. Another disappointing reality of being a business intelligence person at Amazon is that you are largely expected to be a data vending machine-- the product managers or executives need data for decision making and come to you in a panic to produce some data under a deadline that gives them scant time to give you the context you need to understand the request. You are often placed in a situation where you have to cajole the context out of them in a series of curt or cursory email exchanges only to have them take what you have produced and make decisions based on it in a meeting that you are not allowed to attend. From time to time you meet with a requester who is willing to work collaboratively with you so you both gain something from the exchange, but any person can revert back to a vending machine customer based on the deadlines he or she is facing. The result is that the data professional often can't gain a complete view of what makes the business side so special unless switches to working on the business side either entirely or temporarily. Making such a switch can be beneficial if you aren't sure what you want to do, but frustrating if you already know you want to be a data professional. I mentioned that the poor role definition often contributed to attrition, and with attrition comes inherited code-- which is one of the worst parts of being a data professional at Amazon. Most of the time when you start on a team you inherit someone else's Frankensteined code-- pasted together from working snippets that have been handed down over generations of people who have inhabited your role. The output of this code has invariably been incorporated into some essential business function or weekly meeting, so if you choose to stay in the role despite the mismatch in what you have been asked to do and what is in the description for your role, you will need to find in between your regular duties to seamlessly fix the code you inherited and replace it with more efficient code without disrupting the processes that depend upon it. If you have the patience to deal with these problems, at the end of it you will be seasoned, but it is worth setting goals ahead of time as to what you would like to learn so that you can determine when you have had enough, because you are going to lose a level or two in the exchange. Amazon sets your incoming job level based on the assumption that a data role is harder here than a similar role at a smaller company. They are largely correct, but the added difficulty of your role at Amazon is often not due to complexity that is constructive to growth should you leave Amazon, but due to the yoke of proprietary systems that were built to accommodate operational scale, but are useless at a smaller company. Levels largely don't matter, but if you come in at too low a level, you might get stuck doing data vending machine work when you are capable of doing more, even though you can't prove you are ready to do more complex analyses if all you do is vending machine work. It is a bit of a Catch 22: if you slot someone in a role that lower than their skill level, they are precluded from the opportunity to demonstrate they can perform at a higher level.