274 karma · joined June 21, 2012
There's certainly SOME PEs that go deep in some areas but the majority I've worked with are broad owners of technology in large organizations. The difference between the two roles often has to do with what balance of time you want to spend influencing others for broad goals vs. building up jr. folks to accomplish your team's goal.
In either case your authority is derived from whether people "under" you want to work with you. People who can't get a set of people to go a certain direction won't last long in either role.
If there are tickets, read and understand all the tickets, organize them in a way you can manage day-to-day.
If you're working off some other spec, start breaking it up into individual tasks that can be managed on a spreadsheet or in a ticketing system.
If you're working off general guidelines without documentation (and you can't run!), start by writing out all the tasks that need to be accomplished to finish the project. Even if they are brief.
Now take the list of tasks and organize them into 2 "types"
Stories: Tasks that deliver value to the end user
Tasks: Tasks that are required or nice to have to enable 1 (Tasks or Chores)
Now prioritize those into different buckets
1. MVP: if we don't ship this, the project will fail
2. Nice to Have: Someone _really_ wants this but it's not MVP
3. Phase 2
The more scope you can put into bucket 3 the more likely you'll be able to deliver _a_ working, functional project on time. You will get more credit for delivering something _good_ than failing to deliver the perfect project.
Your team will also thank you for taking significant stress off their plate and for making them a success.
1. he misspoke and meant "80%" of the AWS capacity, which I agree seems implausible. 2. Amazon does not run on AWS because Amazon is 80x more than all of AWS infrastructure. This also seems implausible because of Netflix. In fact, there's an article out there that said AWS exceeded Amazon's capacity within 1 quarter!
I still don't understand what that has to do with autoscaling exactly
OR there wasn't backpressure on a cascading failover so as services failed they increasingly failed to more and more overloaded systems
OR there WAS backpressure and it was the luck of the draw whether you were queued into an error page or got good data
OR the autoscaling couldn't keep up with the onsale window. This used to happen in ticketing a lot. Ticketmaster has a talk somewhere where they talk about warming the scaling load and server cache in anticipation of big ticketing onsales. The time it took to autoscale was just too long.
I think to count we have 34 SaaS products of which something like half of them contain our customers PII.
Is the regulation state that we must guarantee right to erasure or that we must make a reasonable effort to erase customer data on request?
Are people generally automating this fractal process or manually deleting from systems that only offer a manual process (such as Google Analytics)?
Edit: I added the specific examples of each item that I gave the candidate but decided to remove them so as not to expose them publicly should this candidate read hacker news.
People can PM me if they'd like to know more information about the way this particular candidate could have benefited from the above.
> It's not you: The first thing I told him was that 80% of whether you get hired at a company is nothing you can do anything about. It depends on the company, your skills, their needs gap, the timing, the manager, so if you're batting .200, that's pretty good.
The second thing was that there were some really basic stuff to make sure you're doing every time you interview that you CAN control to narrow that gap further:
> Dress: wear dark jeans, nice shoes, a button down dress shirt. This outfit is almost never "too fancy" or "too casual". If the company requires more fancy than that, might want to question if you're a good fit (unless you like wearing a suit shudder)
> Give Specific Examples: Always try to start your answer with a summary, then give a specific example then abstract it into a generalized theory. Don't start with the generalized theory and never give specifics
> Know your stuff: If you list something on your resume, especially in a recent job, make sure you can not only explain it but that you have an opinion about it and that you've considered other opinions.
Edit: the outfit above applies mainly to men, I'm less versed in what the equivalent would be for women. If someone wants to add that, I am sure it would be helpful.
I tend to want to either design or review all data design, either relational or other, partly because of my background in data engineering and partly because I have business awareness that the devs don't have. It's just not possible to convey every nuance of a constantly evolving business to each dev on the team without it being distracting.
How would you like your manager to handle being involved in data modeling? Develop a spec and then review? pair modeling?