Hi all,

I'm a 7 YOE hardware/embedded engineer who's working in a product oriented corporation with limited room for growth and I'm thinking to move to an adjacent field which is close to hardware : compilers & AI inference.

For this purpose, I planned to:

• brush up my DSA & machine learning fundamentals

• showing know-how through personnal projects (even if LLM can redo most of it).

• contribute to open-sources project such as LLVM/MLIR in order to gain expertise in the targeted stack.

The main purpose of this post is to ask engineers who did a career switch (not only related to this specific field) what would be their advice on:

• How to manage the "marathon" of catching up the needed know-how with daily workload ?

• How do you compensate the lack of professional experience during interviews or even application ?

• How to stay consistent in terms of interview preparation (Leetcode, system design) when no interview is lined up ?

Thanks a lot for your attention

I had an interview earlier this week with a tech company(not FAANG but adjacent) and the initial part involved discussion around system design. I feel like I nailed it with the coding part in the later half where I was able to successfully find the inefficiencies in what looked like AI generated code, optimise it and make it thread safe but the system design part didn't go that well. At my current company we don't deal with the same level of scale as big tech companies so I have never had to solve or design anything keeping that kind of scale in mind. I have read a bunch of material to prepare for questions like these like DDIA, papers describing origin and design of popular systems like Kafka, Dynamodb, etc. so I am familiar with general concepts around handling scale but the interviewer asked pretty specific questions that would show that a person has actually dealt with these problems and I couldn't answer those.

What else can I do other than reading these resources? People who were able to clear these interviews without having prior big tech experience, how did you guys prepare?

Edit: re-post after adding flair

Hey all,

I'm curious if anyone has thoughts on how they've helped build a culture of security-focused engineering in the age of AI.

I'm currently helping to scale an engineering team at an early stage, fast-paced startup. With especially the advent of AI tooling, you can ship faster than ever, and basically anybody can contribute code these days. That doesn't mean that everyone has the same level of technical understanding, or is aware of best practices security-wise.

How have you helped your teams mature and to not treat security as an afterthought? Red-teaming exercises? Phishing training? Presentations or demos?

What have you found to be the most effective way to help people take it seriously, and to ensure that there is both 1) the culture in place and 2) the technical resources necessary? I'm not just talking about the engineering team, but across the entire company.

This thread is specifically for sharing "wins". I.e. the opposite of our Tuesday venting thread.

Took a Senior SWE job earlier this year as a W2 Contractor. The duration is long term, and a lot of people in the company are also W2 contractors that have been here for 2+ years now. It's a very large org. Overall it's not bad, the pay is good, and I do get benefits via the company I am contracted out from. We don't have PTO, but the hourly rate makes up for it and we are paid for company holidays.

So no complaints really about benefits or pay, but I kinda don't like it. I feel weird working at a company being a contractor. There are a lot of us here, probably more than regular FT employees, and we're all treated as if we are FTE. But there is just something I cannot put my finger on about it. I guess I just like being officially part of a company, I don't know. I find it hard to give a shit about anything going on internally. When I worked at past companies as a FTE, I felt more invested in things and felt like I was a part of it all.

Another thing is the stuff my team is doing is so basic and simple. If you were a Junior or Midlevel you would definitely not be getting good experience here. I am used to working on more complex systems and apps than this, so it just makes me feel braindead a bit too.

Maybe I just need some perspective, or maybe others too feel this way. I am also in the middle of finishing my B.S. and won't be done until March of next year. Which is why I took this job, because juggling more interviews and my school work was just too much at the time.

Something I repeatedly see is that the limiting factor for developers to implement features and fix bugs is not their technical, but rather their domain knowledge of the software they are developing. Personally I think companies spend way too little time on this and vast amounts of efforts are wasted as a result.

How do you personally think domain knowledge training should be set up within a company? Do you think its the job of development to train this themselves or do you think other parts of the company should do it? What do you think the most effective way of training is? Do you prefer learning sessions or written learning paths? Any other thoughts on the subject are also welcome.

Maybe a UK/EU thing but wondered what people's thoughts are on the Otta/Welcometothejungle switchover? I don't know if they have switched over for everyone but they have today for me. For background on the switch see this post on this sub from a month ago.

My take is that it's absolutely terrible. It now feels like a totally generic listings sites that anyone could put together in an afternoon. I'm being pushed listings that have been up for several months and ones that I was advised of recently are gone. Really no different to a hundred other absolutely generic and barely distinguishable 'vacancy listing' sites.

I find a lot of people in the tech industry get angry easily and are not able to communicate directly or assume the worst of others or try to build rapport by venting or gossiping. 

It may be something you realize is the case as soon as you join, but when you are in this kind of environment, it is an uphill battle and you can’t easily find a job elsewhere. Even if I try to focus on my work or treat others with consideration or respect, I often feel that other people pick on me unless I get them to see me as a human being in some way. And if I’m too nice, they’ll snap at me.

If professional courtesy isn't enough, then what do you do? Appease the other people even though they're being completely unreasonable? This is the same kind of environment where people will get angry if you interview elsewhere or if they suspect that's what you doing. All it takes is one toxic person with too much credibility and influence in my experience.

Hey everyone, I work in a team with mostly junior engineers and I’ve hard time to get them to care more about the code design/architecture. I usually find myself getting into multiple calls with team mates during code review because what they’ve built is overly complex, is obscure, and hard to maintain; where I’m able to suggest a simpler solution.

I think I understand where most the problem stems from

- our code base is very old and the code quality has degraded significantly over the years. It’s like a badly implemented version of DDD/Clean Code, so many indirections, so many tiny classes/structs, strategy pattern everywhere… it’s a pain. The team mates haven’t really worked with a well written code base so they don’t really have anything to refer to or learn from. Every new feature is like patch work on top of it

- I feel like AI “assisted” coding has become a disservice to these juniors because they only care about getting things working. The inputs given the agents are about the business requirement, never about how the code should be structured, never about how the code could be refactored. Since most of the coding is done by AI they’re not really wrangling with the complexities of the existing code base and therefore not trying to simplify it.

I am looking for solutions/suggestions on how to work here. I want to get better at guiding them and we need to refactor our services as we’re dealing with a lot of outages now and building any feature takes a painstaking amount of time

Earlier, technologies and tech stacks would remain relevant for 5–10 years. Developers had enough time to build deep expertise.

Now, every few months, there's a new database, framework or technology, and suddenly the existing stack is considered unsuitable.

The bigger challenge is that companies expect prior hands-on experience with these new technologies rather than giving experienced developers an opportunity to upskill.

I'm seeing this in my team as well. They want AI engineers for new use cases, but instead of giving experienced backend and data engineers an opportunity to transition, they prefer hiring people with 1–2 years of experience in newer AI stacks.

How do experienced developers keep up with this pace? How do you decide what to learn, and how do you make sure your existing experience doesn't become irrelevant just because you haven't worked with the latest tech stack?

Is it normal in your team/company? Could you tolerate this or you would try to find another job?

I might be controversial here, but I think tech as we knew it died this year. Back end, Front End, Full Stack, C#, Java, Rust, Typslescript, who cares? AI writes the code now. AI reviews the code. Mostly the humans in the loop are directing and sense checking. If your company isn't like this... well the company I'm working with is. And while I hate to admit it, the output is good. Good enough to pass automated security checks and external pen tests. Good enough that clients are happy. And that's really all that matters.

What I'm also seeing though is other knowledge workers just don't get it yet. They use AI like Google. They dont realise it can read their emails, get that spreadsheet, analyse it, produce a pretty dashboard and stick it in a company branded PowerPoint for the boss.

So I feel like a grab bag of skills are still desirable for building software, something like:

- Communication skills: as always, being able to talk to people and understand what they need is critical.

- Product mindset: understanding the domain, and why we are doing what we are doing. Directing the agents according to what is important for them to build.

- Systems thinking: where does the data come from and where does it go. What can we connect to?

- Architecture skills: where are the seams in the code so that it's in discrete, testable chunks which dont break context windows.

- QA from the start: thinking about how to build validation systems in so that the agents can't go off piste.

- Infrastructure thinking: where will it be hosted, how will it scale etc.

It's basically a hands on Technical Architect role.

I also suspect that there will be an emerging role for "The AI guy". Like we had back in the early 2000s with "The IT guy" who had a grab bag of office skills and helped offices digitise, I think knowledge work companies will need an "AI guy" who helps them build up a set of AI connected systems in house.

Failing us having to weld steel plates to our cars and spray paint our teeth silver, what are others thinking the future looks like?

YAID (yet another ai doompost 😄 I am very clever today)

Hi I am Tibor, a hungarian software engineer with ~14yoe, and I am watching this paradigm shift with great concern for the last 1.5 year, and I have been mulling over a concern for a couple of days by now.

The loss of innovation.
Will there be new frameworks, new patterns, new techniques or the current level of software engineering will be the plateau? LLMs have been and being trained on already existing codes but if there is no new, innovative code in abundance to train LLMs they will get stuck in the current state. Since software engineers do not create new stuff anymore in the sense of new solutions, we just reuse the existing ones, there is no new stuff to train the models. Will this lead to stagnation in software development?
Could Rust born today in this era of AI?
Innovation is driven by necessity but AI removes the necessity. Javascript and the new javascript frameworks which pooped up seemingly month-by-month was the butt of the joke, but they were innovation. Maybe they were very little innovative or straight unnecessary but still innovation. AI can write raw javascript, get the job done and do not care at all, so it do not needs a new innovative framework.

From this a realization happened in me. We are no longer masters of software, but we have become users of a software. It is hard to use, clumsy, needs a lot of manual setup. Currently, but it can become more advanced. Maybe the IDE of the future will be a prompt window with a model wired in, built in harnesses, all the bells and whistles. Then a software developer will be a simple user.

I am curious what are your thoughts on this.

AI disclaimer: no AI have touched this post!

I have been interviewing engineers over the past few years for various roles, but especially recently, I find myself frustrated at the end of interviews with some candidates.

Every time I interview a candidate, I really want them to succeed. It's in my best interest, it's in their best interest, I go into the interview wanting it to be a success. More importantly, all of the hires that I have made in the past that were great engineers are very engaging to talk with.

More and more, though, I meet engineers who look like absolute rockstars on paper but are frustrating to talk to. The most common reasons are:

• Not entertaining any ideas other than their own.

• Refusing to explain why they chose a certain technology or approach.

• Being unable to say why they’d be a good fit for what we’re looking for (this is a freebie IMO!).

Our technical round and behavioral rounds are very lenient, some would say too lenient. Yet, every time we resume hiring, I find it harder and harder to find engineers.

I apologize if this comes off as a vent and is against the rules, but I'm disheartened. Interviews are taking a lot out of me, as I really care deeply about the people I interview, and I want to see them succeed. So I personally end up taking a lot of that home and feel defeated on their behalf when it doesn't work out.

Anyone else experience this? If so, how do you prep yourself mentally to not feel so drained post-interviewing?

TLDR: It's a mistake to let agents impersonate us.

At work, it's not obvious who-or-what I'm interacting with. Some of my teammates have review automations, and others have auto fix. As a result, there's a lot of churn going on for reasons no human considered or agreed to - sometimes an automated review suggestion is technically valid, but not worth doubling the scope of the PR to correct. AI attribution footers help, but they don't tell me to what degree my teammate is applying oversight to actions taken by their agent. Admittedly, this is as much of a social and team culture issue as a technical concern.

Personally, I am very cautious. I like to think my name next to a comment or an approval means something, and I think it's a mistake to let my agent represent me without oversight. I've spent a decade building rapport and trust with my peers, so I instruct my agent to show me what it will do as me before it does it. Then I read it, correct mistakes, and remove concerns I don't agree with. It works. But it makes my attention a blocker.

When a colleague comments on a PR or Jira ticket, I strive to be considerate and provide a thoughtful reply. When I can tell it was an un-reviewed, autonomous message, my standards change. I might skim it, push back harder, or just fix the thing and move on. When I can’t tell, I have to either give everything my full human attention, or risk being curt with a person because I assumed it was their agent - in both cases, my reply hits the human's notifications.

What I imagine as the direction we as an industry should move: a platform-integrated mechanism for a well-behaved agent to flag what it does, shown next to the human's name, in tools where an agent acts on a human's behalf. This goes beyond comments - there are some circumstances where I want my agent to make a decision (like approving a trivial PR), and that shouldn't hold as much weight as my human approval, and some actions don't have an accompanying place to leave context.

I was screwing around last night and built a demo for the GitHub case to illustrate, if anyone is interested: https://mweberxyz.github.io/a-simple-request/

Does anyone else even care?

Bit puzzled by what I'm seeing on the job market in London. I've recently seen several 'Principal' positions being advertised at different places and in different sectors wanting people 3 days/week in the office. Yes we all know about title inflation, but from what I can see these actually are principal level positions - duties, pay, hands-on, etc. I'm just confused by the degree of on-site sought for roles that are primarily IC. Whenever I go into the office I can pretty much count on it being purely a social exercise rather than getting anything productive done. 1 day, perhaps 2, I might get, but 3 days every week? For new hires? When exactly do these employers expect the successful candidate to do any of the IC work they list? What am I missing?

Update: Thanks for all the commenters posting variations on 'how can you help and mentor people if you're not in the office'. That point of view has come through now and doesn't really need repeating further. I guess in that case remote first businesses shouldn't or can't have principal engineers? Kinda curious how e.g. [GitLab](https://handbook.gitlab.com/job-description-library/engineering/development/management/principal-engineer/), canonical, paddle ,manage

I went to university around the early 2010s for software engineering. They really drilled us on the technical design and diagram part of things.

One lecturer even mentioned “you need to be able to draw airtight state machine diagrams, because in 5 years everything (programming) will be offshored to India” whatever that meant. Anyway, I digress.

In my career, which spans 10 years, I have rarely seen UML diagrams. Granted:
\- I work on mobile apps which is technically front end, while my university focused on enterprise software
\- I have seen diagrams, but they’re almost never UML and usually only from an architecture perspective. I haven’t seen a class diagram since university, but I have seen a handful of poorly executed sequence diagrams
\- I have never professionally worked in waterfall, and I get the general impression that design is often glossed over in agile

It seems though, that people are more inclined to make diagrams now that AI can help. Was it just a matter of effort before?

I’m curious about you guys, do you work with diagrams and specially UML ones recently?

Now that I've been working as an SDE/Data Engineer for around 8-9 years, I sometimes wonder how much I've actually grown since my early days as an engineer.

My company is going to be looking for a new Sr. Developer to fill a hole on our team, and this is the first time I'm going to be on the other side of the table in interviews. I'm planning on giving out a take home project for our candidates to do.

What are your thoughts on being given a take home project, and how long should the project take to finish to be respectful of your time. What kind of things should I avoid doing?

Tech stack will be Java API server with a React TypeScript SPA (our team's standard stack)

This thread is specifically for sharing "wins". I.e. the opposite of our Tuesday venting thread.

I applied for and interviewed for a Senior Software Engineer role. The job posting and my application both listed that title, and I was verbally told I got the job after 4-5 interviews.

The recruiter told me they well email me the job offer by EOD. Afterward, the recruiter asked me to resubmit my application as they have included an additional screening question.

Except the new title is Senior DevOps Engineer. They said that the opportunity and scope haven’t changed. However, this title was never mentioned during the interview process. I have reached out to them and still waiting to hear back.

Has anyone experienced something similar? Changing the title only after offering me the job feels like a bait and switch and I'm not sure how to feel about this. Would you consider this a red flag?

Producing code with agents is relatively cheap at the moment.

Reviewing their code is not.

This also applies if we also want to have a full agentic review workflow.

Any decent agentic review will have a big cost multiplier relative to the cost of generating the code that is being reviewed.

Anything less means risking costly issues in PROD.

The bottleneck is reviewing code regardless of who does it.

Future smarter agents may lessen the problem but will it be enough?

How are you dealing with it right now?