Just from pure introspection, you might be able to glean an answer by thinking about these questions:
— Are you capable of distinguishing opinion from fact? Are you capable of distinguishing _your own_ opinion from fact?
— Any project will have easy bits and hard bits. How accurate are your predictions of which bits are easy and which bits are hard, for projects within your domain of expertise?
— When you think about your software, how good an idea do you have of what's "cheap" to achieve, and what's "expensive" (e.g. which endpoints or queries are fast and which are slow)? What's easy, what's hard? Do you understand how the people who consume your software use it? Do you know whether common operations for them are cheap and/or easy? Do you understand why (or why not)?
— Turn the previous question around — do you understand the design behind the software that you consume? Are your own common operations things that are cheap and/or easy to achieve using that software? Do you know why (not)?
— When you think of technical choices, do you tend to think in terms of absolute right and wrong, or do you prefer thinking in terms of tradeoffs? If the latter, how capable are you of articulating why a given tradeoff makes sense in one situation but not another? Are the tradeoffs you consider limited to technical matters, or do you consider "softer" aspects in your analysis (such as recruiting costs, time to market)?
— How well do you know your tech stack of choice? How well do you understand your own limitations within that stack? How does your stack of choice measure up against the alternatives? Where is it better, where is it worse?
— And, finally — why does any of this matter? Do you genuinely want to work on the sort of project that _actually_ requires so-called "rockstar" engineers, or are you happy working on projects where good enough really is good enough? How much effort would it take to actually become a rockstar? What would it cost you? (you might want to go over the bit on tradeoffs above again)
— Are you capable of distinguishing opinion from fact? Are you capable of distinguishing _your own_ opinion from fact?
— Any project will have easy bits and hard bits. How accurate are your predictions of which bits are easy and which bits are hard, for projects within your domain of expertise?
— When you think about your software, how good an idea do you have of what's "cheap" to achieve, and what's "expensive" (e.g. which endpoints or queries are fast and which are slow)? What's easy, what's hard? Do you understand how the people who consume your software use it? Do you know whether common operations for them are cheap and/or easy? Do you understand why (or why not)?
— Turn the previous question around — do you understand the design behind the software that you consume? Are your own common operations things that are cheap and/or easy to achieve using that software? Do you know why (not)?
— When you think of technical choices, do you tend to think in terms of absolute right and wrong, or do you prefer thinking in terms of tradeoffs? If the latter, how capable are you of articulating why a given tradeoff makes sense in one situation but not another? Are the tradeoffs you consider limited to technical matters, or do you consider "softer" aspects in your analysis (such as recruiting costs, time to market)?
— How well do you know your tech stack of choice? How well do you understand your own limitations within that stack? How does your stack of choice measure up against the alternatives? Where is it better, where is it worse?
— And, finally — why does any of this matter? Do you genuinely want to work on the sort of project that _actually_ requires so-called "rockstar" engineers, or are you happy working on projects where good enough really is good enough? How much effort would it take to actually become a rockstar? What would it cost you? (you might want to go over the bit on tradeoffs above again)