This worries me too. Within my company I have a pretty good reputation due to experience but I am not famous in the industry so I don't think any leverage I have my with my current company will translate into finding jobs at other companies.
That's a pattern I actually see quite often. People go very high in one company, but when something happens and they leave that company due to layoffs or other reasons they often find jobs only several levels lower and have to work themselves up again.
I've decided to adopt the attitude: Enjoy it while it lasts, but don't count on it lasting forever. Live a lifestyle consistent with your market value, and squirrel the rest away. I'm also conscious about keeping my tech skills up to date.
I'm reminded of an old saying among people in the entertainment business: Think about how you treat people on your way up, because you will meet them again on the way down.
Same here. Its kinda easy to be fooled into feeling complacent when you get compensated very well and are respected for what you do and have done so far. But it will never be enough to keep you around forever; there are so many failure modes that you have to think about the possibility of being on the job market again.
Which is another reason why (apart from plain old human decency) I do make it a point to reply to most of the recruiters that try to recruit me with a polite explanation that I'm happy where I am currently but please lets stay in touch so in the future if things change we can try again.
That’s an incredible saying. It really encapsulates the “fall from grace” that a lot of celebrities experience. Never saw it put in a way that would relate it to my life. Thanks for sharing!
Lesson learned : make a conscious and focused effort to acquire + maintain general skills and keep a visible portfolio updated!
But I feel more and more that growing in this company may be a trap.
Meaning, it's easier to create a new project using x,y,z new tech. But to transform a company and bring business value from old tech, is more difficult.
Part of being at the principal/staff level is the ability to effect corporate change for the good of the business goals.
If that isn't happening, you need to ask some very hard questions as to why.
Anyone worth their salt should realize that the long-term value of technical leadership far eclipses the short-term value of knowing what happened that one time we tried switching from Technology A to Technology B. (And unless you've completely purged your engineering department, such institutional knowledge is there to be queried.)
At the companies I have worked at, hiring people directly into principal roles hasn't worked well. Invariably, they struggle to fulfill that role because they don't have enough knowledge about the inner workings, code base, etc.
It usually takes them at least a year before they contribute at their level.
Any ideas for doing this other having a lot of public visibility? I may have answered the question already but there may be other ways .
Another thing I don’t see enough in this thread is emphasizing software you managed to avoid writing. That’s the real secret of being a 10x engineer: telling your organization when building something expensive is not necessary, either because you don’t really need it, can use something simpler, or can adopt something that already exists.
This is important for any level job. Java to Go by itself is really only interesting for a low level position. 8MM revenue growth is a person that will almost always get another look. In general, using exact numbers that can be backed up is better because they tell the why.
Using the Java to Go example. Sure, the work was done but why was it a good idea? What did the company receive out of the change? How did the interviewee think about and mitigate the risks?
In addition to what pm90 already said, if you can't quantify the value to the business on some level, then why are you doing the work?
My comment also said to back up the numbers. If I said I wrote a little utility and it saved the company 8B/year I better be able to explain how.
Also, the numbers do not have to necessarily go directly to revenue. Less bugs, faster feature development, less server resources, lower costs, better estimates, etc... are all quantifiable on some level. Is this an exact science? No, but this is what any engineer above junior (even they should be asking why are they doing something), should be asking themselves about every single engineering task. Because something is new and shiny is generally not a good answer, yet these types of migrations still happen in companies and waste large amounts of money.
e.g. it could simply be how much client data is processed by your system everyday, how many clients use it, what is the ultimate value the pipeline generates (even if that may be the cumulative value generated by the entire software pipeline)
Also, yes, don’t have the numbers be BS or fail to include other useful narrative in your resume. But I so often see none of this, and leaving it all out is a sign someone hasn’t had to justify their decisions at that level.
Do you improve the skills of the people around you? Do you identify and help resolve barriers faced by your peers? (This doesn't always mean fixing things yourself!) Do you improve the environment and culture where you work? Can you work collaboratively to establish a vision for change? How do you gain the buy-in of your peers when it comes time to implement change?
Internalizing these answers will prepare you to steer the conversation onto the skills that you know are important for the role.
> Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills.
To be clear I was let go because the company ended up having financial difficulties. It is a strange story to tell and sometimes I wonder if people think I am weaving it as I go. I'm not. It did leave me severely burnt out and I find the question "what was your biggest accomplishment?" to be a frustrating one during interviews because I did so much for that previous company that I almost don't remember any of the subtle details. I thought that the numbers would speak for themselves but nobody seems to care. I find it bizarre.
The other thing that might be fascinating is that the technical portion of interviews seem to be where things stall out for me. I would never claim to be an incredible programmer, but my previous companies system was not a trivial piece of software. I am probably going to give my one and only job offer a try and see how that goes. shrugs
Finally when I say build I mean to say that there was a PKI api + c library for interfacing that layer when I started. The website, the inbound/outbound email processing, the ES portion of the service etc were all built by me. So the parts that brought the actual customers were built by me.
I've kept a daily work log at my last few jobs -- just a line about each significant thing I made progress on, so usually one sentence a day (and often the same sentence for several days). This could be helpful.
I keep a daily log of outstanding and completed tasks. It includes everything from high level sprint stories or tasks to setup meeting with such and such for some project or write status report for z.
The interview process filters for coming up with solutions quickly. My strength has always been that I worked through a situation even after the initial or obvious approach(es) didn’t work. A lot of people give up quickly but I keep going and solve it. You sound similar.
Unfortunately the interview process doesn’t filter for that.
I guess there are certain folks who find this enjoyable. Personally I find it a massive waste of really good talent and perhaps the single biggest reason why I enjoy the dynamism of the SV startup ecosystem even if I don't directly participate in it.
You are right. Even if you are at FAANG, it doesn't really translate to a new environment, unless you are a direct pick by a CTO (you have to be famous in some way) or use your networking, which I consider unethical and don't do it.
Please don't shoot yourself in the foot. There is nothing unethical about this.
Perhaps you think it's a way for people to create and then exploit their connections in order to get a job that they're clearly unqualified for. I will agree that's unethical.
But that's not typically what networking is about, almost no one wants to recommend someone for a job if that person turns out to be an unqualified idiot. Networking is more about finding people/companies you have something in common with and once they know about you it's a lot easier to get hired or referred.
It's not really about some form of nepotism or cronyism.
I don't understand the sentiment. Interviews are a proxy for how good you are. The companies hiring are very limited by what kind of information they can turn up about a candidate just through that process and for higher leveled positions like staff+ that might rarely be enough. Your network can speak much better about who you are and what value you can bring to a company. I don't understand how giving a hiring company better signal about your value is unethical.
So says you. This can also be thought of more charitably that someone hires people they know because there is much less risk. I've been working in software for ~20 years. I have a decent list of people who I would work with again, know what they bring to the table, and their strengths and weaknesses. If I had to build a new team tomorrow, you can bet I would be calling the people I know first.
Humans are a social species, you can't avoid this if you want to get far.
Have you worked with people who you would work with again and vice versa? Congratulations, you are using your networking.