A few things concern me here

- title inflated senior roles - this is not the best sign
- is there any way for you to verify that they are working for the company they claim to work for? 
- I do understand if the recruiters are employees of different companies but they end up being 'vendors/contingent/contractors' for the parent company (best acid test - company email ID). But it does worry me if they are just 'headhunters' so to say.

On the flip side, it's probably a recruiting model that tech teams in finance use. I do see some evidence of this - <https://www.linkedin.com/pulse/why-fintech-recruiters-essential-growing-hedge-funds-radley-james-ajz8e/>\
\
My strategy would be as follows 

- depending on how many interviews you get, I'd just give these interviews to a- get the experience, b- make sure the interviewers are employees of the company
- after getting the offers, maybe use them for leverage/negotiation and thoroughly verify that they are from the companies they claim to be

Mid-Level Software Engineer at Walmart

Karthik Gurunathan

I think this may be a classic case of imposter syndrome. First off, you got into the startup, which, in itself, is quite significant given how you had to pass multiple rounds of interviews. 

If it is a fast-paced startup, they'd expect you to start contributing as soon as possible, given that you're probably in a team of &lt; 10 people. I have seen interns in teams that I have worked at (in a startup and elsewhere) who contribute quite significantly to the team. As for new grads, once again, spending time to understand the code base, asking questions and formulating your own solutions are essential skills in startups and outside too. And you've been selected only because you passed that bar, so cherish it!\
\
If you think you could probably spend time learning/scouring through the tech stack before you join, that would give you a great head start. Trust me, I have been there. Endlessly doubting my skills, being very resistant to opening up about 'getting stuck', and not asking any questions to other folks in the firm. \
\
It's a wave and once you ride it, you're going to get better at coding!

I entirely hate the idea of [formation.dev](http://formation.dev) teaching you how to ace LC. It's 5k $ too much. Taro is a fraction of that fee and you get accountability + community + job recommendations.

As for failing recruiter calls, I think strength in number is a great way to go. More interviews = more rejections, potentially more offers. Once you are ready, you should probably try to dip your feet into a Microsoft/Meta/Amazon interview just to assess how difficult/easy it is!

First off, congratulations. That is no mean achievement in this economy.\
If you're looking to start up, then in all likelihood your first few months (and even perhaps years) will necessitate that you have a great understanding of the business you plan to run. So, in that case, it is a question of just getting your feet wet if and when you want to.

Alternatively, if you prefer to move to a TPM role, here are my two cents.\
\
I think a good TPM has a combination of three offerings - \
1\. good technical skills (plain-speak - has written code in the past) \
2\. great people skills (high empathy for engineers, good understanding of business requirements and an even better translation of business needs into the coding world)\
3\. supreme prescience (being able to have the right pulses to 'know' the future direction of every single initiative)

You probably have the first skill above. If you're still new to the tech world, a few months in a fast-paced unicorn will help you polish your tech skills. Be sure to check this course out - <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/what-actually-makes-code-good/>. It is probably the best lottery ticket out there to learn how to code 'better'.

The second skill is highly experiential. The more time you spend talking to engineers and people with business needs, the better. Much of communication is also about asking questions, collating information, and having a 0-&gt;1 understanding of every system you work with.

The third skill is the toughest in my opinion. Two resources come to mind. A - This essay by Paul Graham - <https://paulgraham.com/greatwork.html> and this remarkable video by @Alex - <https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/finding-the-best-things-to-work-on/>. Be sure to check out the matrix that he refers to. Doing great work helps you know what is important. And knowing what is important enables you to predict future direction better!\
\
As for timelines, I do think you should do it at a time when your manager thinks you have contributed sufficiently and you have learnt enough of the above three skills to move.

With the meteoric rise of ChatGPT, ML and AI are on software engineers' minds more than even before. How can we leverage AI to boost our workflow? Is it worth it pivoting to MLE? Use the resources here to find out.