That's the optimistic view on it. The pessimistic view is that in all of these interviews I never perceived that the interviewers were greatly better than my own ability. As one example, walking through my take home project one engineer asked me about a kind of React gotcha. I said I wasn't quite sure, and then he admitted that he only just come across that in their own code recently. But I felt like it had already counted against me, even though he himself hadn't known about it. I guess it felt like I should have been the perfect version of who they aren't yet.
The interesting moments were when somebody with less than 3 years professional experience were elevated to management because it’s a startup. They were so lost trying to interview somebody with 20 years experience and prior experience as a corporate director level. I completely stopped talking to start ups.
Eventually I got very lucky and found a company that is awesome with incredible leadership. They were actually looking for a senior to come in and fix some architectural things and in return they would teach me areas of programming I had never done before.
Here are the common danger patterns I observed over and over:
* Most importantly look for strong leadership in the employer first. If it just isn’t there stop talking to them. They are more than happy to waste your time in repeated interviews.
* Determine the level of honesty present in the work culture. Look for brutal honesty up front and don’t be shy about it. If they are timid about honesty in an interview you will spend your employment walking on egg shells and playing politics, the kind of place where shitty brown-nosing people get promoted over you.
* Next evaluate for the quality of work. Do this by asking about writing original code. If they are timid about original code or are horrified at the thought of stepping outside the yellow brick road to produce a superior product I don’t want to work there. There are many people thrilled to work at someplace average building a shitty product so they should hire one of those other people.
* Finally evaluate for retention. Does that employer work extra hard to retain people? If not you need to drill into this immediately.
Don’t be shy about asking tough questions. You will be devoting a block of your life to these people.
Personally, it took me 20 years to reach this understanding. I wouldn't be surprised if other senior engineers, smarter than I, reached it in much less time.
Concept: https://circleci.com/blog/why-we-re-designed-our-engineering...
Matrix: https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhC...
Evaluate yourself critically and honestly within every single row. Learn to convey (market/sell) yourself to an interviewer on those dimensions. Be truthful, people can tell.
In the event these interviewers are actually picking up on something, it may be that the "senior" for them is along a dimension they consider more important than a dimension you think matters.
For good measure, begin to work deliberately on those rows where you aren't as far along as you'd like.
They are just leveling you internally against some internal metric. They might have a lot of well qualified non-senior in title folks. Bringing you into the club may ruffle some feathers. It will depend on how isolated the teams are and the cross communication requirements.
If they say you are not senior ask where on the scale you fall as a non-senior. Then ask for their rubric that describes the levels and the promotion requirements. All of that should be standard and is fair to ask. Say you need it to determine next steps.
That'll give you the information you need to make a decision.
The biggest difference in a senior role is that you need push back if required, and hunt stuff more information if required. Asking the above sort of question would be the first step to getting there.
Edit: why disagree? This topic constantly comes up on here, with no consensus.
Senior is the "career level" for a software engineer - that is, it's the level you would expect most basically competent people to be at after 5-7 years of experience. The key difference between senior engineers and the lower levels is that seniors guide the planning process and technical architecture of the software they work on. They don't just or mainly do individual ticket work. As a senior engineer, I have multiple projects within my team for which I am the lead engineer or "feature owner". That is, I conceive the technical approach, I work with product managers and stakeholders to gather requirements and create and estimate the work. I do investigative engineering work to demonstrate the value and feasibility of the work being requested. I understand our systems to the point where I am comfortable devising high-level, large-scale modifications to their inner workings. I am also a mentor and guide for the other engineers on my team and in my organization.
Essentially, I am a mini-manager (of technology and planning, not people). The difference between me and a staff engineer is that I do this at an intra-team level; I don't do it for a whole business line or working group of multiple teams. I also probably spend a lot more time working on implementation of individual tickets than a staff engineer typically would, and less time monitoring or planning. The skillset is broadly similar, though.
If I am evaluating someone for a senior role, therefore, I am asking:
* Do they have a depth of knowledge which would make them effective doing that kind of technical leadership work?
* Do they have experience leading projects and/or architecting software, not just implementing tickets?
* Could I trust this person - after they've ramped up into our company - to independently do the above?
* Will this person be an effective mentor for other developers who are more junior than them?
* Will this person be able to communicate effectively with management and other stakeholders?
And I want to see examples of all of these things. I think that it's likely that, if you are being turned away for being "not senior enough," it's because you don't have or aren't making visible your experience in these areas.
Also, for what it's worth, when you mention:
> As one example, walking through my take home project one engineer asked me about a kind of React gotcha. I said I wasn't quite sure, and then he admitted that he only just come across that in their own code recently. But I felt like it had already counted against me, even though he himself hadn't known about it. I guess it felt like I should have been the perfect version of who they aren't yet.
If it actually counted against you, it is a yellow to red flag - but I ask these kinds of questions to assess how a candidate thinks about issues. I love it when a candidate says "I haven't experienced that, but the way you describe it suggests X Y so I'd look up Z and do A B C", or otherwise has a conversation about it with me.
Hope this is helpful!