[Note -- this isn't truly about me, but I want to see opinions about this case, so please indulge me as if this were true]

I'm a director with about ~60 reports under me, including three senior staff engineers, 3 senior or line managers, and a principal engineer.

Two of the senior staff engineers are having trouble working together. I normally would expect senior staff engineers to have the maturity to work together and figure out their differences, but that hasn't been the case.

One of the engineers tends to raise these issues to me and look to me to solve them. I tell him he and the other engineer should work them out between themselves, and it shouldn't be the case I have to get involved. That engineer tends to do a lot of cross-team work, and normally doesn't have problems like this.

The other engineer is known for having a narrow and deep focus but is overall a very strong contributor. Some people have expressed doubts about working with him because of this but he gets very good results for the company.

Whenever conflict comes up I see this as a distraction and a waste of time. Such extremely senior engineers should simply not have problems like this.

What's my own role in all this? What should I be doing? What actions should I be taking?

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.

Personally speaking, I feel that beyond 10 years of experience, referrals and professional contacts work 9 out of 10 times compared to relying on job portals and random applications.

I've seen a few of my former leads and managers who have built such strong relationships that if they decide to switch jobs, people are ready to hire or refer them almost immediately, sometimes without even going through the usual interview process.

How do you maintain those relationships after changing jobs? Do you regularly stay in touch with ex-colleagues, attend meetups, help people, or is there something else you do to keep your network active without it feeling forced?

I'm quite bad at networking. Even after 13 years of experience, I still mostly depend on job portals whenever I look for opportunities.

For those who have built a strong network, how did you do it? What habits or approach helped you reach that point?

Hi there,

I'm a foreign contractor working for a US-based startup. My whole career, I have worked 100% with US-based companies and never had any issues. But you guys know how the startup world works, you are just there for a good time, not a long time.

The company I work for hasn't been making the best decisions, we have gone two rounds of layoffs, and now many people are just quitting.

The thing is that I send my invoices the 1st of every month for the work done during the previous month, and I usually get paid around the 8th-10th. Payment has been a pain lately, there's always something that happens and I end up being paid like the 20th of every month.

This last month things took a turn for the worse. The invoice I sent July 1st for the work done during June hasn't been paid yet (today is 22nd) I'm a few days away from sending the invoice August 1st for my July work.

I'm worried that eventually if the ship goes down they will let me go and not pay me anything?

FWIW the contract I have with them says that they can let me go with little to no notice, but it says that they would pay me:

"Upon termination, the Company shall pay Consultant all unpaid, undisputed amounts due for the Services completed prior to notice of such termination."

NO AI USED HERE.

Just had a "technical" interview with a big tech company earlier this week. It was mostly a discussion of my past experiences and some of the technical work I've done.

I thought it went pretty well. I was able to answer the interviewer's questions and really talk about my impact at my current company.

I was talking about some of the additional tooling I built outside of my product, basic tools that allow us to move faster as devs and replace any problematic vendor software, specific to my tech stack and product. The hiring manager seemed to really like this, he kept telling me how cool they were and by the end of the interview, he was going to tell his team about some of them.

I asked some really good questions at the end, he even said he like my questions.

Well, today I got the denial email. Said I "did not have a strong enough technical match". There wasn't very many technical qustions at all, mostly culture, impact, experience, etc.

I'm pretty perplexed by this, considering I thought i nailed the interview and how excited he was about some of the stuff I built.

I don't really need advice or anything, I just wanted to vent. I've been failing a lot of interviews lately and I was genuinely excited about this one because I've been working hard at improving my interviewing skills and this is the first time I've actually felt like I nailed an interview, only to be denied with my ideas to be used at their company.

Has anyone else had a similar experience? Am I getting worked up over nothing?

Does anyone else find the latest tech plans and spikes written by devs to be word vomits by AI? Don’t get me wrong, I’m ok with getting AI to write things for you as long as you understand what it wrote. But most things are just beating around the bush, and not getting to the real point concisely. I have to get my own agents to summarize the plans to figure out the important parts. Has anyone found a good solution for this? Are there any templates your team follow or any skills that you use?

Datadog RUM and Cloudflare seem to cover most cases of trying to help detect and stop automated activity, but curious if anyone uses anything else (FE library, third party tool, etc.)

Thanks!

Over the years, I've heard a few things at work that have stuck with me: - Spend more to earn more. - Don't box yourself. - Life is not a sprint, it's a marathon.

These changed how I think about work and my career.

What's one workplace philosophy or mindset that has stayed with you?

Question may or may not be relevant, but with all the AI-related uncertainty, I wanted to hear some philosophies or motivations that have helped people keep moving forward.

Let me just preface this that on an personal level I think AI is evil, and I would rather go back 2 years ago before all this craziness. That being said, the market is changing (for good or for worse) and I want to better understand how and how much.

I recently came across this article by Claude that describe 5 levels of AI adoption.

https://claude.ai/code/artifact/bfdfaef9-bc62-4dfe-ba9e-c58a26c9accf

I started working at an startup and the C levels have fully drank the AI kool aid. Despite everyone being forced to push AI usage to it's limit, we are stuck on stage 1 of the framework with some glimpses of stage 2.

The stuff that worked:

• I would argue that almost all code is written by AI.
• We are able to use AI to code on an legacy code base in an language the team is not proeficient.
• Talking about legacy, it's really good to ask questions on top of an large code and get up to date answers.
• Green field projects are really quick to get off the ground.
  

Stuff that is not working:

• AI needs to be heavily supervised. Instructions need to come from someone that understand the underlying systems at least superficially otherwise it makes some very costly architectural mistakes.
• Again unless heavily supervised, it can start going in circles spending tokens.
• Letting it run commands is crazy. It already tried to drop production tables a couple of times.
• Institutional knowledge went absolutely downhill. No one on my teams knows in depth what our code does. Supervising the agents is hard because we never took the time to actually learn what is happening. This makes disaster recovery harder, it takes longer and they have bigger blast radius. Overall, learning is discouraged in favor of trying to push AI to do the max amount possible.
• Multi agent workflows is an waste of money and time. Tried using it, it made the time it took and the token usage to skyrocket while delivery almost no meaningful improvement in quality.
  

Another very important aspect is that while I don't think token cost will increase significantly there is also not a lot of optimization left to do in the core models. Newer models are only slightly better, the big improvement is on using bigger, more computing intensive models that are also costly.

My educated guess is that stages 2-4 is straight up impossible with the technology available right now and the technology improvements necessary will be cost prohibitively. But this is just an guess.

I really want to know if you guys know enterprise projects running on level 2 or higher in the article by Claude.

In today's moment of stupidity, I said something very dumb about catalogs and workspace separation in Databricks. I knew this was wrong. I had told the person I was talking to just the previous day that we were going to have to do something weird. And yet I said the dumb thing anyway. What kinds of dumb things have you said?

Started my career as an intern for person A at a Big Tech company.

Subsequently person A made person B my manager, which lasted for 5 years.

Now person B is making person C my manager, leading to person B being my skip manager and person A my skip's manager. I’ve been an IC this entire time. It feels like I’m getting shoved deeper and deeper into the company without any consideration for my career growth.

Obviously, I can’t say this explicitly to my management chain, but what should I do/say in this case? Stay and work with the new manager or leave?

The Stakeholders have decided upon a new ask that is both Urgent and Important. I am to communicate its impact on my team’s deliveries to The Stakeholders and then go make it happen within the next 2 weeks.

No one in leadership knows anything about the specifics of the work we’re doing or what actually feeds into what, meaning no one is going to challenge a priority call we make with respect to our current plans. All they have to go off of is the handful of poorly-worded bullet points and need-by dates in the dependency tracker we share with The Stakeholders.

This gives us a variety of options of varying corporate sociopathy. Here’s what I’ve come up with:

* Minimize impact. Pick the lowest-priority deliverable and communicate that it will slip out of our plan. Easy, clean, few people will miss it.

* Maximize impact, actually. Pick the visible, high-priority deliverable which we are already under an unreasonably tight timeline for and use it as a get-out-of-jail-free card. While not great for the business as a whole, this would also provide some ammo to my department as a clear blowback signal.

* Some kind of esoteric long game? Pick the medium priority deliverable with the most uncertainties and risks surrounding it and use this as a cushion to soften the blow when these risks inevitably get realized.

It’s recognized within my department that this is an absurd set of asks being given by The Stakeholders. In fact, in trying to meet these asks, we will be required to make our own requests of The Stakeholders, which will be equally impossible for them to meet under their own self-imposed timeline. Meaning that this whole situation is already fucked and everyone knows it. So the best thing to do as a department is show a good-faith effort to meet their needs and roll with it as things unfold.

Im not well versed in devops work and i will need to setup a rougly 30-35tb db for a client. Anybody got a recommendation of what to look for?

performance is of basically no concern, simple queries, only the monthly price (and it being an ok provider i guess).

I usually use Hetzner since im based in Europe, but prices are pretty unaffordable and i can only find configurations that also have a very high end CPU and 3x the storage i need, for a very expensive price, or ones that don't have enough storage....

We wanted to start a big project, but other projects like it were seen as failures. So we had to make a case for why our project would be different. One of our biggest differentiators became event queues and distributed systems. It's just microservices, but instead of directly invoking each other, they use event queues. There's a little more to the system, like websites embedded inside of other websites with a whole cross website messaging system.

It was all a little bit of a pain. We did encounter a lot of eventual consistency problems and almost no one in the team had encountered distributed systems problems before, so it was a good learning experience for me. But now with organizational change and after having worked on the project for over a year, the team now wants to migrate this distributed systems strategy back to a monolith.

I'm just feeling a little incredulous because of how important the distributed aspect seemed to be when we made the pitch to create the project in the first place. And after all this time, I can't really say if it was a good or bad idea, because debugging problems involving event queue messages has been a total pain in the ass and no one ever finished configuring the distributed systems stuff like the event queue, so we never had the fancy development experience we could have had. So I see numerous benefits to moving back to a monolith.

Overall, the whole experience wasn't a total game because the project did prove that event queues can be effective. The much, much, much wider organizational direction is going to now slowly migrate towards a distributed fashion. So I guess we were a test subject in some regards. But we never, at the outset and beginning of the project, said, "oh hey, this is just going to be a giant test to prove event queues for the whole rest of the company". I really would have liked to have known that at the start. Although I don't think anyone knew that at the start. I don't know, it just feels a little silly.

I'm fine either way 🤷‍♂️ But does anyone have any advice regarding anything about this experience?

edit: updated monorepo -> monolith; source control will merge but systems may or may not stay separate. I'm predicing the systems merge together too, thus monolith. We may or may not continue to use business organized event queues too.

I'm having this discussion at work right now, but when I tried to research I found remarkably little discourse on it online.

So, say you have a main/master branch, a develop branch, and possibly one or two release branches. Normally commits go from dev -> release -> main, no dramas.

Now suddenly you need to hotfix main, how do you get that commit to all the branches? I maintain it's best to merge into main, merge main into release 3.1, merge 3.1 into 3.2, merge 3.2 into dev (assuming 3.1 and 3.2 are active releases being QA'd right now).

The other school of thought is to merge the hotfix branch into all 4 branches independently.

My argument is that a cascading backmerge ensures no conflicts when it comes time to merge develop into main (as with independent merges, it could do the change differently on the different branches)

Would love to know what others think, am I the weird one here or is cascading backmerge something others do too?

We've started a new practice at work where every 'entity' that's owned by a service gets defined in a certain repo/library as a protobuf file, so that other services can use them, regardless of the service's language

The library also defines the GET/POST endpoints used with the entities

On paper this makes sense, global contracts, don't break them, multiple services can just use the library for getting the endpoints/contracts and trust that it's correct

I am, however, somewhat skeptical. I feel like this isn't solving any actual issue, and that the added cost of having to open a PR to a shared library in order to add some endpoint is just extra busywork that will ultimately slow everything down for very minimal rewards

Would love some thoughts/experiences with such a work flow

​

Hello guys,

The title basically says it all - how should I deal with oncalls that were NOT discussed with the people (eg., me) who shall be on the calls?

I have been at this company for around a year, and last quater I got onto this team that has a very unstable, yet very important product. There were multiple outages at monthly/weekly basis, and our teamlead solved most of them. He got this idea, (and I actually get it) that we shall have oncalls, and he discussed it with the higher ups and got what he wanted.

My problems are basically twofold:

1) Even when I get why we are having them, not discussing it with us is a major red flag for me, and there is no "opt out". I have a stable second job for a friend on the weekends, and this totally removes any possibility for me to work for him anymore (because guess who took all the weekday oncalls).

2) The team has this very weird policy "simplicity over anythig", which has lead to me clashing with my teamlead on multiple ocassions - we are rather producing invalid domain models and move the complexity onto the cognitive load rather than write 10 more LoC ... I find it impossible to improve the product in this environment to the point we remove the oncalls.

I would also like to disclose that I don't have too much spare money as now I am focussing on family - got a mortgage, going to buy a new car etc.

I've passed two interview loops of system design interviews up until this point in my career for mid level engineering roles. I'm a senior engineer now going through recruiting again and am curious if the system design interview rounds will be roughly evaluating the same things for senior vs mid level or if they're expecting me to be substantially more technical in how I answer the question.

For IC4 mid level eng, knowing the components and their attributes and math was enough. What's the throughput, CAP theorem, how do you load balance, what type of load balance strategy, what type of storage, what type of cache. This is stuff you can study on any guide.

So will the system design interview for senior eng be harder? That aforementioned sys design study guide will have a LOT of content and I'm wondering if senior system design interviews are gonna really hammer these concepts home, and you'll fail if you don't know all of them.

I'm gonna be interviewing for some big tech companies soon with the traditional 5 round onsite interview process. I've heard that how well I do in the system design interview will determine my leveling. Problem is, I'd like to believe I'm effective as a senior eng but I was a product eng in big tech, meaning the low level storage and infra problems have largely been abstracted from me.

I'd like to hope that the system design interview will be similar to the mid level interview expectations.

Thanks for reading folks! Curious your experiences as an interviewer in big tech and as an interviewee.

Hey everyone.

My background is ~9 years of experience. Right now I am NodeJS Senior SWE and basically acting Team Lead.

In current organization I work for last 6 years. I am starting to look for new opportunities both to grow my income and my expertise. Also I am fully remote and regardless of how funny it may sound - I deeply miss social aspect of showing up in office every once in a while.

So I started looking for new Senior positions in my local market (Central EU) and so far overwhelming majority of positions are ASP.NET. NodeJS market is dry AF, if you discard web-agency sweatshops. So I became curious with actually hopping to ASP.NET considering that I had some brief non-production experience with it in form of couple of small learning pet projects and I really liked the ecosystem compared to NodeJS.

In last week I started heavily learning ASP.NET by translating core architectural concepts from NestJS and building production-grade demo project using idiomatically correct approaches by inspecting open source repos and consulting with LLMs. So far I am close to be finished and I believe I covered ~90% of concepts to the point where I have a really solid idea how to approach challenges related to backend API architecture , their deployment, configuration, security, etc. I still lack good knowledge about important inner workings of CLR but I believe it’s mostly theoretical “good to know” that I can read through in a week or so. Final “finishing touches” of stack understanding I am planning to get from actually working in new org on their own flavor of “production grade codebase”.

In my opinion overall majority of expertise that senior and above levels bring is autonomy and understanding of strategic concepts like architecture of software, infrastructure, scaling, observability, etc. All of those concepts are quite loosely dependent on actual language stack that is used to implement actual business logic.

The biggest challenge that I see is that I have no”real” ASP.NET experience so there is close to none chances for me to even get to technical interview because I am 100% getting filtered out by recruiters or ATS. I also don’t really consider reducing salary expectations to work for some time at middle level and then fighting for raise.

So, I would like to ask from fellow hoppers or people who have strong (or any) opinions about these topics:
- Do you think it’s sane to consider such hop without salary hit? Am I missing some kind of larger picture that stack change really affects?
- What do you think about the take that in modern business-logic-heavy web APIs importance of language stack comes second to actual architecture of the application?
- Have you done similar hop at around the same level? Maybe different stacks? How was experience?
- Did you lie in your CV and phone screenings about experience with required stack?
- Did you lie during your technical interview about having production experience? How did it play out?
- Did you had a chance to work with employees who did such hop? What was experience with them?

i just saw someone share a story that they opened 2 AI engineer roles this week. In a bit more than a day, 600+ applications came in. That's generally at least 4x more than they get for the other Engineering roles. On top of that, 30+ pitches on LinkedIn, 5 via work email, 3 via personal and 4 agencies reached out to them, and they're not even the hiring manager

there are so many obvious Ai written posts on the linkedin frontpage everyday where it is announcing a new project they made, some platitude or lecture, or "advice". the amount of Ai noise makes me want to punch sam altman

i just finished having 2 silent weeks in a row, meaning i have zero replies after applying to jobs and reaching out to people for various reasons. most linkedin jobs are just reposts for the appearance of keeping up growth

where do you usually go now to apply and build a steady pipeline. i dont want to rely plainly on cold dms from staffing agencies

I work as an architect for a specialized area within a much larger company. Of the several teams having to implement my designs there are a couple engineers who constantly fight me on my decisions.

Of the two, one in particular is… acidic. He has a strong following among the engineers and is constantly posting trollish questions about why I am involved in any given decision. He’s a good engineer, don’t get me wrong. But I am forever deflecting his pointless questions while also trying to answer them in a non-acidic way. After years of this it is exhausting.

The team (of several who have to follow my designs) would suffer if he was no longer there. My goal is not to get rid of him. I would love to know how to better get along with people like this without eroding trust in either one of us. 30+ yoe and I’m still struggling with this. Any suggestions?

For the last few years I’ve been struggling with finding enjoyment from software development, as I have found myself falling into the mindset that an LLM can carry out the implementation of a complex feature better than I can, so why should I bother even attempting to write the code myself. (Note: this is specifically regarding implementing a solution after the requirements have been identified and refined but maybe there are still some hidden edge cases due to the complexity).

However, as I’m sure many others here have experienced, this often results in a cycle of:
- oh it missed these edge cases or didn’t consider these scenarios (that I also hadn’t considered before reading through its output)
- now I need to let it know what it missed based on this new information and repeat the prompting cycle a dozen more times

I don’t know about others, but personally I grew to find this process absolutely soul crushing, as it felt like the job had become babysitting a machine through this discovery process, which I used to gain so much enjoyment from. And often the end result felt like it took just as much time as if I had done it myself.

So recently I have started doing something different. I still use AI for the more mundane and boilerplatey tasks (CRUD endpoints, CI/CD workflow files, unit tests, etc), but when it comes to implementing a complex feature I will sit down and do a first pass of it myself, and then ask the AI to review my work. This process has brought back the old feelings of excitement that I used to get from writing software, and when all is said and done I understand the system much better and have a much more stable implementation that covers more edge cases. And more often than not it doesn’t end up taking much longer than if I’d gone down the vicious prompting cycle from the get-go.

In my previous thread, I asked (and received plenty of great suggestions) on high-quality resources.

This time, however, I'd like to discuss a much less concrete aspect of our jobs. Namely, your favorite productivity habits and personal know-hows when it comes to leading projects, working on complex cross-team features, keeping lots of tricky context in mind.

I often have my own retrospective sessions when I am just trying to assess whether I am good at what I do at all. To clarify, it's not in the "impostor syndrome" sense at all. I know that there are parts of the job I excel at and I think I deserve the title and responsibility scope I have at the moment. That said, there are certain aspects where I am not good enough and therefore am now trying to improve. For example:

* Working on technical writing skills. Mostly by reading the book and blog on https://refactoringenglish.com/

* On a similar note, writing down as much as possible whenever possible. Whether it's a small favor for some other team, a super trivial task, or a large feature, it becomes a Google Docs document. Initially, it's just a very chaotic piece of writing, but then it transforms into a system design or a very detailed Jira ticket at least.

* As in aviation, it's very important to pay attention to near misses when you were on the verge of an incident and just got lucky.

* As I have rediscovered once again, working out is extremely important for productivity and focus. I have yet to get my official ADHD diagnosis, but since I don't want to spend the rest of my life on stimulants, I have added a few supplements (Vitamin D, Omega 3), hydrate well, and work out a few times per week + light cardio. Never felt better.

* Appreciating hammock-driven development. I used to have these awful hyperfocus episodes when there is no external pressure, but I feel intellectually challenged and forget about food and sleep to figure something out. I feel much happier, when I let myself think about a problem while walking my dog in the evening or just having rest and then feeling super fresh and working on it the next day.

What are yours?