Regarding empowerment/trust: those factors are definitely critical to PMs' success, but I'd also argue that finding folks who can thrive with this independence is itself important. We've had success with defining clear areas of ownership within our product, within which PMs have substantial autonomy.
Regarding project management: I couldn't agree more. But at the same time project management does need to get done, and PMs are often well positioned to help. I generally feel that PMs should be accountable to making sure that effective project management is in place for the teams they work with, whether by partnering with designers/engineers to set up efficient processes or hiring/designating dedicated project managers (but not necessarily directly project managing themselves).
Agreed on your point. I didn't go into a ton of depth about the details of the interview, but fwiw this is always addressed in depth during the course of the product case, and touched upon during phone screens.
A process that I've seen have some success (years ago):
Start with a very, very simple initial phone screen or take-home test, intended to basically verify whether the candidate can write any code, at all. Max 1 hour, weeds out more people than you'd think.
For the first in-house interview, ask the candidate to code up a problem that is representative of your company's work and requires coding a significant amount, ideally 100+ LOC. The problem should not require any major leaps of intuition, dynamic programming, or recursion – all of these are areas where people do way worse when they're nervous, and this is an engineering interview not special forces training. Let them bring their own laptop, give them the prompt, and have them code, although they can ask the interviewer questions at any time. When they're done, go over the question in detail with the expectation that their code compiles and runs, discuss extensions, etc. Max 1 hour. This interview should answer the binary question "can this person promptly produce meaningful working code and discuss it intelligently?"
For the next in-house interview, do a deep dive into a technical project that the candidate worked on that they're proud of. They describe it and you ask questions. Keep asking questions, especially getting at the "why" behind different decisions, for as long as you can – you're trying to get to the borders of their knowledge and intelligence. Look for mastery of the area, thoughtful decisions, and communication skills. Max 1 hour. This interview should answer the question "is this person a thoughtful, effective, smart contributor on a project?" A good answer should make you think "damn, that's really smart, I wonder if I would have thought of that?" at least once.
End with a final behavioral interview, intended to sell the candidate. This is also a last gut check on whether they're insane, dangerous to themselves or others, extremely arrogant, etc. Also use this time to ask the candidate questions about what really matters to them to improve your closing rate. 30 minutes, and can be combined with the step above.
I've liked this system, YMMV. It's a relatively efficient process, doesn't have weird tricks, and based upon a longterm analysis of candidate outcomes was quite effective (this included an analysis of candidates whom we rejected and who rejected us).
If I'm correctly understanding the question, you should get the 83b form asap, as there's no downside to having the choice to exercise your options. As mentioned elsewhere once you exercise you have 30 days to file the 83b with the IRS.
You can (and should) think carefully on whether or not to actually early-exercise your shares, based upon the cost and prospects of the business.
Definitely can be true, although I think that there are a lot of potential paths.
My advice would be to determine what is driving you to want to shift from Engineer => PM. If it's purely money, there are alternatives that don't require leaving coding (job hopping wisely, moving into certain types of management tracks, consulting on the side, switching into industries that pay SWEs ludicrous salaries such as quant finance if you can). Similarly if you're looking for more influence/reputation – all of that can be had as an engineer if you're somewhat thoughtful about your path. However – if you're looking to transition out of coding because you're more interested in the business / sales / working with people (which was my story) then it's a great switch.
Engineering is in higher aggregate demand (there are more open eng roles as the ratio of Engineers:PMs is high, and the minimum qualification bar to be an engineer is higher ie you need to know how to code at a bare minimum. You also generally speaking can always add more engineers to a mature tech product as they can fix bugs, tech debt, etc and help the business overall). As a result, my personal anecdotal observation is that Engineering pays the same or somewhat higher at the more junior / midlevel range where the base of the org chart pyramid is "wider."
However, Product Management is a straighter shot to general management, and becoming a GM/CEO is a path towards some of the highest total comp.
Mileage will vary by company (and probably region).
One of the other issues that I've seen with Untappd and many of the other beer rating companies is that their ratings systems are heavily biased by the nature of their users and/or weird algorithmic quirks. I believe that this has caused some beer rating services to become fairly disconnected from reality: For example, the first 4 beers on Untappd's top beers list are discontinued Goose Island beers, and 7 of the top 10 are from the same two breweries (see https://untappd.com/beer/top_rated).
Disclaimer – I'm pretty biased in this assessment (helped build BrewGene, which provides a similar beer rating + recommendation service). Here's our top 5 for context:
* Trappist 12
* Heady Topper
* Pliny the Elder
* Sip of Sunshine
* Pliny the Younger
Have seen good results from App Academy (in NYC in particular) - they follow the business model that I mentioned above. I don't know the details of all the bootcamp alums on my team, and am also unfamiliar with the tuition structures of different bootcamps. My info is also about 2 years out of date.
IMO these bootcamps are producing a basically undifferentiated product curriculum-wise (which, by the way can be learned via self-teaching on the internet). Only a few have real brand recognition. Drive, curiosity, raw horsepower, etc are a lot more important.
For specific pointers: your cousin should speak to as many recent alumni of various programs as she can to ensure that she has a legit program on her hands. Speaking with hiring managers is a good bet as well; "I've never heard of that place" is bad; "That place is a scam" is worse. She should also ask what the pass/fail rate is for students in the program. High graduation rate + upfront payment is arguably bad (shows they're incentivized to just get you out the door).
My company has hired several coding boot camp alumni; some directly from bootcamps, some after a coding bootcamp + some years of work as a dev. We've had good results and most of the grads I know have had positive experiences.
It's important to note that coding bootcamps are not created remotely equally -- some have stringent application requirements, whereas many are essentially scams / chop shops. I strongly caution against the latter.
In particular, at least one bootcamp that I know of only charges tuition after you get a job as a software engineer, and charges a % of your first year's salary. It's a really great way to align incentives between the bootcamp, students, and employers and I'm a particular fan of this program.
FWIW we've had great experiences hiring bootcamp grads. A few aspects of our software engineering process have helped smooth this transition:
* We're disciplined about code reviewing everything that goes to production.
* We're very careful about having a smooth ramp-up period - managers are expected to carefully curate the first few weeks / months of a new hire's projects to make sure that it follows a smooth learning curve, and we adjust the params as necessary.
* We're gun-shy about hiring.
* Our tech stack happens to share many frameworks / languages with the technologies that are in vogue among bootcamps today (due to random chance).
My experience has actually differed slightly from this post, in that many of the bootcamp grads whom we've hired have actually had excellent project management skills, especially coming from IT or PM roles in tech or tech-related industries. The main challenges that I see are around depth of experience - most bootcamps optimize very heavily for building CRUD apps with a bit of frontend sugar on top, so you need to select really carefully along whatever metrics for potential you find valuable. YMWV though.
Specific plug: despite interviewing candidates from many different bootcamps, one bootcamp in particular, App Academy, has consistently stood out. As of when I last checked, App Academy was the only bootcamp to use a conditional payment system, where tuition is contingent upon finding a fulltime software development job. This aligns incentives well - App Academy is encouraged to maximize training and applicant quality - and we've found their alumni to be very solid. I don't have a horse in this race but they turn out very professional and talented graduates.
I might be ignorant, but if they hit profitability relatively early in their hiring (and meaningfully de-risked themselves as a result), I could see them having the leverage to parcel out lower equity amounts.
Were you expecting a shallower decline in equity grants over time? Definitely curious to hear what others view as an expected employee equity structure.
My understanding is that the valuation per share (at least, the valuation that matters for tax purposes) should depend on the 409A evaluation of the company, which determines the current price of shares in the eyes of the IRS. In some cases, especially if e.g. you're pre-revenue or nearly so, this number will be much lower when compared to the valuation per share that you'd see in an acquisition or subsequent funding round, both of which would presumably price in your potential future growth much more aggressively.
The net result is that generally speaking the number given by your 409A would seem low compared to the "true" price of the shares, and make it a weak recruitment tool.
(If this assessment is wrong I'd definitely be interested to hear to learn more)
As an aside -- unscrupulous companies can always quote inflated per-share prices based on extremely optimistic valuations e.g. "we're at least 10x the last round of funding -- your options are worth $500k!" So generally speaking, watch out.
"you are interested in having a more flexible career, and not just writing code, but also getting more into the "business" side of things"
I'd also recommend that engineers look into career switching to product management.