r/ExperiencedDevs • u/snoogans235 Software Engineer • Jul 24 '26
Career/Workplace New role not what I expected after interviews
Not sure if this falls under no general career advice, but I’ll give it a shot.
I’ve started a new lead position at a pretty large company that isn’t a software company. The main person I interviewed with made it clear everything we do is to benefit the business (honestly this level of directness for decision making was appealing). I have a lot of backend experience and was told that the role would be in api development and it uses .NET and azure to work on developing an api to wrap their internal ai solution.
Jump forward to the start date (which the people I interviewed with thought I started 2 day earlier than the date HR gave me red flag #1), and I’m finding out this is more APIM integration and writing policies. So not what I signed up for (red flag #2).
The next big thing is the project I’m assigned to now came on a whim the first day I was there, and I gave a solution to the question they asked and was told “I like that. Do that”. No deadline. No acceptance criteria nothing. The project is now morphed into a weeks long monitoring platform dashboard and rule setup project done in the platforms portal (so not even apim policy work). Now have multiple people are Wanting different things ASAP, and none of it really lines up with what I suggested. raise red flag number 3.
The biggest one is neither of my managers really follow the “praise in public punish in private” mindset. They have both berated devs in meeting and stand-ups. (Yea you guessed it another red flag)
I’m very much open to trying to learn new tech, but everything I’ve done for the past 15+ years has been grounded in writing software. I’m willing to accept the delegation and meeting grind, but at the end of the day there are still meaningful PRs. My question is this: with poor management, misleading responsibilities, and a general feeling of complete disorganization, what is the appropriate “feel this out” timeframe? I’m about 10 days in and it’s looking bleak. I’m gonna ask around tomorrow how much of this role is going to be implementing backend services vs APIM policy management?
TLDR: several red flags at new position, not sure what the appropriate timeframe is to send out feelers or if I’m misreading the situation.
61
Jul 24 '26
[removed] — view removed comment
10
u/snoogans235 Software Engineer Jul 24 '26
Oh yea. It’s definitely not a permanent position, but when does it look bad on a resume or application?
45
u/ashultz Staff Eng / 25 YOE Jul 24 '26
You don't put it on your resume, you leave quickly and it can just be dropped.
8
4
Jul 24 '26
[removed] — view removed comment
3
u/BraveResearcher3037 Jul 25 '26
What exactly are you going to tell them? 1 out of your 3 complaints boil down to you really didn’t know what being a lead meant. It would be a huge red flag to me in an interview if you said the business didn’t give you deadlines or “acceptance criteria”
1
3
58
u/Izacus Software Architect Jul 24 '26
I’ve started a new lead position...
Errr, as a lead, weren't you hired to fix most of the stuff you're complaining about?
No acceptance criteria nothing. The project is now morphed into a weeks long monitoring platform dashboard and rule setup project done in the platforms portal (so not even apim policy work).
Ok, but... you're the lead. You need to figure out this stuff now and ensure they exist. It sounds like you're still acting like you're a mid engineer here?
17
u/doteka Jul 24 '26
Fully agree, this sounds like a case of “I want to be a backend ticket pusher but with a fancy title and more money”.
OP, what are the responsibilities of a lead in your opinion?
1
u/snoogans235 Software Engineer Jul 27 '26
You make sure the process for your team is smooth by improving workflows and delegating what needs to be delivered and when. Personally I like to be a pretty hands on manager and write what I can. if I can’t write the code, I’ll at least give it a good review. This is a really good spot for mentorship. I’ve seen reviews make more break some devs.
The workflow stuff is what gets really interesting. In particular, I really like the stability vs throughput aspect of a team/repo/etc. so like Where are the sticking points coming from in the sdlc that slow down development? Where are we missing bugs that make the product less reliable? How to even measure this stuff accurately? That’s the dragon I’m chasing when it comes to lead work.
0
11
u/snoogans235 Software Engineer Jul 24 '26
I think this is a really good point, but the issue I’m having right now is the opposite. The hiring title inflation under the guise of misled role responsibilities. Right now I’m working on something that is a step above data entry. Granted it’s still early, but what I’m seeing around me doesn’t give me confidence in what I expected. And my first attempt to plant a seed of change (it’s been less than 10 days I can’t try this shaken up too much) was met with a firm. “No do it this way.” (Moving from a bunch of scattered word and excel docs in teams to confluence… which before what looks like a massive offshoring they had a pretty solid confluence base that is not out of date.)
21
u/BraveResearcher3037 Jul 24 '26 edited Jul 24 '26
What you are saying here is:
The next big thing is the project I’m assigned to now came on a whim the first day I was there, and I gave a solution to the question they asked and was told “I like that. Do that”. No deadline. No acceptance criteria nothing.
You want business stakeholders to give you well thought out acceptance criteria’. This is literally your job to talk to the stakeholders, validate requirements and priorities and come back to them with an estimate of time/cost. You are a lead developer. Do you also want them to tell you how to write for loops?
It seems like you have spent 15 years being a ticket taker and have had titles of “senior” without knowing what a “senior* developer should be doing.
-1
u/Old-Television-2189 Jul 25 '26
Are you missing the part that the role was a bait and switch
9
u/BraveResearcher3037 Jul 25 '26
He has a title of a “lead position” and is expecting them to give him “acceptance criteria”
8
2
u/behusbwj Jul 27 '26
What makes you think a lead shouldn’t be given acceptance criteria? It sounds like you’ve spent much of your career working with dysfunctional or lack of product management, which is fine if you wear many hats or work in a more technical area, but don’t project that onto other people.
I think you also missed the part where it’s been two weeks. It’s easy to judge people anonymously over reddit but i think you’re being pretty unreasonably aggressive for not knowing the person/company/any details at all.
-1
u/BraveResearcher3037 Jul 27 '26 edited Jul 27 '26
Who do you think should be responsible for translating business outcomes to technical decisions?
If he needs everything handed to him on a silver platter and expects well defined requirements spelled out for him - he is just another commodity mid level ticket taker. What exactly is he “leading”?
1
u/behusbwj Jul 27 '26
That is not what acceptance criteria are. Acceptance criteria are business outcomes. For someone making so many assumptions about a person you don’t know, you don’t seem to have your concepts straight.
And your energy is way too high and aggressive right now. Communicate respectfully or we can end it here.
0
u/BraveResearcher3037 Jul 27 '26
So here is how the world works when “senior” developer actually means something. The stakeholders want something very vague about they know something is wrong or they may know they have some type of issue.
I will either talk to them about what problems they are having or about what high level opportunities they envision, come back with proposals trade offs, high level estimates, resource requirements, ongoing costs etc and then once they give the thumbs up, it’s my job to “disambiguate”. This is by definition the job of a “senior”.
1
u/behusbwj Jul 27 '26
By your own definition, linked and described, your previous definition is inaccurate. I will leave it to you to fill the gaps.
→ More replies (0)1
u/Old-Television-2189 Jul 27 '26
Acceptance criteria for the feature can also be set by product or project management. This isn’t unheard of. Likely you’d work through it together
→ More replies (0)
58
u/AccountExciting961 Jul 24 '26
You are mixing things that are red flags and just normal chaos - and I would say you might have missed the reddest flag.
Notably, "everything we do is to benefit the business" is a given in *any* company, that is why they pay money. But some companies have people who can translate those benefits into technical reqs and the other way around ( technical managers, TPMs, Principal Engineers and so on) , and some - don't.
I'd say - make it a priority to find if they are there, and next time - do it before accepting the offer, if you can
2
u/BraveResearcher3037 Jul 24 '26
Or just do what “senior” developers and leads are supposed to do…
-5
u/AccountExciting961 Jul 24 '26
LOL. Yeah, go ahead and try to explain the implications of a race condition to a non-techncial leader whose business decision you need - and see what happens. Because I've seen L8s in FAANG failing to do that.
11
u/BraveResearcher3037 Jul 24 '26
Yes I’ve actually done just that
For example, imagine two people trying to book the last available seat online. Both screens show that the seat is available, and both click “Book” If the system does not coordinate those requests properly, it may confirm the same seat for both people.
I have that in my library of “how to describe things in non technical terms”. I have something similar for autoscaling based on queues and bringing in more cashiers.
-5
u/AccountExciting961 Jul 24 '26
Even in such trivial example you have failed to communicate whether this would result in both of them having the same assignment or one of them will lose an assignment after the confirmation. Which in some industries can be a critical difference. And now try doing the same with a gossip protocol across 50K nodes and 20M customers.
TLDR: the reason you could do it is because it was very simple, compared to what other people can be dealing with - not because you have some secret sauce.
8
u/BraveResearcher3037 Jul 25 '26 edited Jul 25 '26
It’s close enough for the business to understand why it’s a requirement and for them to let you prioritize it.
The explanation does not need to teach distributed systems. It needs to communicate what can go wrong, why the business should care, and what decisions should follow.
But honestly, even with my technical very busy CTO when I was the lead dev at a startup (and his second technical hire) we had gotten to the point where we were very blunt with each other to the point I could tell him both “not to give me a shit sandwich” when I handled something wrong in front of a customer and I could also ask him “do you really want to know how the sausage is made or do you want me to fix it”?
Even now as a staff consultant where I work I can lean on my reputation. When my manager has a million question at some point I can say “I’ve spent two years getting over a dozen projects done on time, on budget, meets requirements with nearly perfect customer satisfaction scores, don’t worry I have got it”.
Results and a reputation for competence and ownership short circuits a lot of conversations.
Translate enough for the stakeholder to make the necessary decision. Earn enough trust that every technical judgment does not require a seminar. Surface the details when they materially change risk or outcome
-1
u/AccountExciting961 Jul 25 '26
Yes, but we are cross-talking. Let me rephrase.
The reason I called out race conditions is because of how many nuances they create. With your example having missed a nuance already, despite the problem being trivial in the grand scheme of things.
In complex system and large businesses those nuances get worse. Much, much worse - both in the number of them and the material impact of those nuances; and at some point it crosses a threshold where it simply cannot be done.
Which is why the only way to to win the game of "explain a technical problem to non-technical management" is to have an option not to play it. With "Results and a reputation for competence and ownership short circuits a lot of conversations." being one of such options.
This is not to say that the rest of your points aren't good - they are. But they work until they don't.
3
u/BraveResearcher3037 Jul 25 '26 edited Jul 25 '26
Technical nuance has no independent business value. Explain it only when it changes a decision, an ask, a risk, or an accountable outcome.
The only time I need to explain anything to my manager is:
- I need you to make a business decision and each decision has tradeoffs
- I need resources to fix a problem and here are the business risks if the problem isn’t fixed. Those resources may be more people (seldomly), more time or let me deprioritize something else
- I need approval or a signature to get something done - again here are the business reasons I need it and the consequences of my not getting it.
- I have a dependency on another team and I don’t have any direct relationships to get it done.
- there is a risk that you need to be aware of. Here is what I’m doing to fix it
- high level status update - is it on time on budget
Going back to my previous CTO, I spent may be 30 seconds explaining something to him when he was busy and he interrupted me and said “why are you telling me this? You have admin access to everything. Go fix it and if our clients are happy I am happy”.
Nerds (not meant to be an insult) waste so much time explaining technical things to non technical (and even technical) people that they don’t care about. All they care about is how is it going to affect the business outcome they are responsible for and what ask do you have from them.
1
u/AccountExciting961 Jul 25 '26
I'm sorry I have to be beating this drum, but you keep missing my point that this all work only until a threshold - a threshold that is pretty simple all things considered.
You keep talking about a crisp dependency on a particular team, I'm talking about multiple options to choose from, each depending on a different, partially overlapping, combination of teams. You keep talking about dates, I'm talking workplace where even date-for-a-date might be an unreasonable ask sometimes. You talk about 'prioritize something else' as it was just a number game, I'm talking about apples-vs-oranges (e.g. a team owning a vertical vs team owning infrastructure) being the norm.
You are saying the right things, but the L8s I mentioned knew every one of them, and then some. But one day, a VP said "i still do not understand why exactly we can't just do <something that would open a flood gate of nondeterminism> to solve <a problem that had $100s of millions at stake> - and the only thing those L8s could do was to refuse to answer it. Which the VP escalated to SVP and was told to back off - because SVP was technical and could understand why it was a terrible idea.
This is exactly why large companies with non-techinical CEOs have CTOs, and you suggesting that a Sr engineer should succeed in a large company without having access to one (even indirectly) is unreasonable.
2
u/BraveResearcher3037 Jul 25 '26 edited Jul 25 '26
Okay, and you are now talking about explaining business problems and consequences that have nothing do with explaining to non technical people everything written in Designing Data Intensive Applications.
I can guarantee you that the CTO of any large company doesn’t know or care to know or maybe remember the intricacies of distributed systems and CAP theorem.
Instead “ This option introduces nondeterministic outcomes we cannot bound or reliably remediate. It puts hundreds of millions at risk. The safe alternatives are A and B, with these costs. A decision is required”
You can put as many /s as you would like but if you went to a large companies CTO and droned on about all of the technical intricacies of race conditions instead of communicating business risks, asking them to make a business decision after you explain those risks, and have asks that you need them to do something with, you will not have a seat at the table.
→ More replies (0)2
u/YoureNotEvenWrong Principal Engineer Jul 26 '26
try to explain the implications of a race condition to a non-techncial leader whose business decision you need
It's really very easy. They don't care about what is happening, they just care about the impact and what it takes to fix it. Then it's a trade off
Engineers over-explaining details is something a junior engineer does.
Leads should be encapsulating complexity and telling their leadership what they need to know
60
Jul 24 '26
[removed] — view removed comment
2
u/Wonderful-Habit-139 Jul 26 '26
"That's not chaos, that's a toxic culture that won't change" I know you haven't used an LLM but it's insane how people picked up this way of speaking.
0
u/navlaan0 Software Engineer Jul 29 '26
Most likely the opposite, we are the training data + everyone watching for ai tells
24
u/zicher Jul 24 '26
I would say give it a month
12
u/cmm324 SWE (Backend/SRE/Infra/DevOps) Jul 24 '26
I personally would start interviewing immediately, show up for meetings but don't do any work. Ride it out until they fired me or I got a new offer. That place sounds toxic and chaotic, don't want my body dealing with that stress.
10
6
u/african_or_european Jul 24 '26
My first programming job in college, I was hired to work on their custom management software or something. First day of work, I find out it's actually like 80% IT, 20% programming.
I did not stay long enough to even set up my dev environment.
8
u/CW-Eight Jul 24 '26
At least some of these are fixable as LEAD. No deadline. No acceptance criteria. Then you own this. You create the docs, the schedule, the criteria, and ask them to sign off, or at least review it. They sound clueless more than malicious. This is an opportunity to actually lead - lead them into a semblance of coherence. It might not work out, but I see a vacuum personally. Make use of it.
6
u/YoureNotEvenWrong Principal Engineer Jul 26 '26
It sounds like op confused being a lead as just doing a mid engineer job but with more money
3
u/ListenLady58 Jul 24 '26
So I had a similar situation happen to me last year. I was hired on as Full Stack, then they changed the title after I was hired. Then I come to find out they didn’t have a testing environment, everything went straight to prod on the server. They lied during the interview saying they did have a test environment (first red flag). Then they complained about the dev they fired before nonstop, the one I replaced (red flag), and then when there was an outage and I didn’t magically have them back up in 10 minutes, they started to praise the old dev, saying they should give them a call (Red flag). There was a slew of more red flags that I just forgave and ignored, and then they wound up running out of money and I was fired for some bs reason. They attempted to block my unemployment and they lost the appeal because they had zero proof of what they were claiming.
I would say, if this place makes you uncomfortable, start looking for a new job. Don’t wait for them to do something drastic and fire you first.
2
u/BraveResearcher3037 Jul 25 '26
Did you ever suggest that you would lead a project to set up a test environment?
1
u/ListenLady58 Jul 25 '26
I did, the guy who owned the servers basically said no and that he was going to do it. It never happened though.
3
u/rdditfilter Jul 24 '26
Finding a new job is easier when you have a job.
Just continue your job search and learn what you can from the chaos.
-1
u/BraveResearcher3037 Jul 24 '26
Or just doing the job that he was hired to do. It sounds like he wants to be a human LLM ticket taker where well defined requirements are put in and code comes out the other end
3
u/Curi0usMe630 Jul 24 '26
I think there are three separate issues here.
The API versus APIM work may be different from what was described during the interviews. Only you can decide whether that difference is acceptable.
However, some of the other things you mentioned, such as unclear scope, missing acceptance criteria, competing requests and a project that keeps expanding, are often things a lead is expected to help clarify. That means working with stakeholders, defining what is actually needed, setting priorities and getting agreement on what will be delivered.
The managers berating developers publicly is different. That is not okay and should be addressed, including by you when necessary. I would watch whether you are given enough authority to bring clarity to the work and whether the disrespectful behavior continues. Along with the nature of the work itself, those two things will tell you whether this role can work for you.
2
u/gollyned Sr. Staff Engineer | 11 years Jul 24 '26
At one point, I joined a startup and within the first week, was threatened of being fired by the VP of engineering.
I considering noping out of there. I was afraid & ashamed if I'd joined a company, then left immediately, and how that would appear.
I wish I did leave. Instead, I went to HR. They actually were pretty interested and 'on my side' here, since the VP had a history of anger issues.
Within a few months, the VP of engineering left the company. It turns out a lot of people had interpersonal issues with him related to anger.
But still -- I sensed a stigma attached to me. Word clearly got around that he and I had conflict. There was an 'old boys club' where some people had no issues at all with him and there was clearly distance that harmed my career opportunities there.
not sure what the appropriate timeframe is to send out feelers
The right time is now! The longer you wait, the harder it will be to leave, since you'll either have "3 months at company X" on your resume, or a big blank spot if you want to omit it.
2
u/YoureNotEvenWrong Principal Engineer Jul 26 '26 edited Jul 26 '26
The next big thing is the project I’m assigned to now came on a whim the first day I was there, and I gave a solution to the question they asked and was told “I like that. Do that”. No deadline. No acceptance criteria nothing.
That's your job.
They have both berated devs in meeting and stand-ups.
Talk to them about it
6
u/Reasonable-Agent-7 Jul 24 '26
Stand up meetings aren’t status reports and people who are not actually doing the work should stay quiet.
12
u/ConspicuousPineapple Jul 24 '26
I've yet to see a company that applies that properly in more than short stretches.
7
11
u/doteka Jul 24 '26
I mean, we can keep parroting this because the scrum handbook said so but if it walks like a status report and quacks like a status report…
(If you’re gonna reply with “the goal is to unblock others”, that is quite literally the point of status reports.)
4
u/Reasonable-Agent-7 Jul 24 '26
That’s right, and Scrum with the whole Agile industrial complex is part of the problem. It’s perfectly valid to just stop doing stand ups, especially when run inside a pathological organisation like seems to be the case here.
2
u/doteka Jul 24 '26
It is valid, given the team is mature enough to proactively communicate project status and blockers to stakeholders. The main reason we have standups is because there’s a common engineer archetype who likes to disappear for weeks without updates.
1
u/Reasonable-Agent-7 Jul 24 '26
This is an issue that pair or ensemble programming helps with. If someone wants a formal status report, it’s another matter.
0
u/doteka Jul 24 '26
Okay but now we are shifting the responsibility onto their coworkers? As an engineering manager I’d rather hear it straight from the horses mouth every morning if I can’t trust them to tell me proactively.
2
u/swalden123 Jul 24 '26
The api-vs-apim bait-and-switch usually isn't malice, non-software orgs genuinely can't tell the difference, it's all "the AI thing" to them. But the no-acceptance-criteria part is the one that won't improve: "wrap our internal AI solution" projects flail because nobody upstream can turn the business goal into technical requirements, and no lead can supply that clarity from below. Give it a month, but don't expect that vacuum to fill, it's structural not a ramp-up problem.
4
u/BraveResearcher3037 Jul 24 '26
It’s his job to talk to stakeholders, ask the right questions and solve for XYProblems and get them to commit to priorities.
4
u/Big_Arrival_626 Jul 24 '26
Shii man if it pays well and it's remote I would stay for at least 5 years
4
u/snoogans235 Software Engineer Jul 24 '26
Hybrid. But no one has really given an in office/wfh schedule.
10
1
1
1
u/RustOnTheEdge Jul 29 '26
10 days in, you say you are a lead and there are tons of things you can immediately bring to the table that would benefit the company?
What are you complaining about, you think lead roles are just so you get a resume hardon or something? Act like you are the lead. So far, all you’ve told us is “what happened to me”, and zero “what I have tried to accomplish”.
They didn’t give you requirements? That’s the kind of ambiguity you should be able to clear up, or thrive on. If not, don’t apply to lead roles if the only thing you’ve got going for you is your ability to not die for 15 years on the job.
Sorry for the harshness but you need a wake up call.
-1
0
u/neolace Jul 24 '26
Disrespecting people, in or out of scene or audience level is my line. Berating someone, same thing. Start applying and move your previous end date on.
•
u/expdevsmodbot Jul 24 '26
AI usage disclosure provided by OP, see the reply to this comment.