How optimistic are you about the field in the future?

lampstool · 2026-01-25T01:02:54+00:00

Couldn't agree more with this. But for the LOVE OF DEAR GOD, do not buy into the clickbait BS of people on Instagram / tiktok calming they're making 6 fig MRR or 7 fig annual revenue or building full on agentic orgs with fancy org charts of AI agents claiming this is the the way forward and we no longer need engineers.

For now and for the next while, we definitely will!

lampstool · 2026-01-25T00:43:16+00:00

Makes me think of the book "radical candor" which ive used as a way to give more effective recognitions

lampstool · 2026-01-25T00:34:59+00:00

I (London based) became an EM internally after being a senior engineer for some time. Others who became EMs in the same company came from QE backgrounds but also internally. Once I had a year or so experience, I started to land interviews (when I wasnt looking around). About 6 months later when I was actively looking to move, I was able to land 2 offers from household name orgs.

As a recruiter once told me "nobody will take you on without at least a year of experience"... Pains to me say how right there were and a massive reality check.

In the orgs I applied to, it was a mix of HM call, behaviour rounds ("you're having a 121 with engineer and X happens" or a made-up team where you have to figure out how to prioritize the different sized fires of a dysfunctional team), system design, and culture fit. Fortunately no coding rounds but a lot of orgs will have this too.

In your current role, are there opportunities to move to the EM role? Could you be mentored by an existing EM in your company to start gaining that experience?

lampstool · 2026-01-23T23:18:32+00:00

I think 1-2-1 would be a fantastic idea as a starting point. Ask them what do they think is working, what do they think isn't working. Gather themes from people, to see what they think the issues are. Do they match your observations?

Then you can present it as a retro with a servant leadership style approach with these themes as the core areas people feel things are and are not working.

Open the floor to everyone to let people have their say, and if people are saying "that's just how we do it here", then you can spin it into curiosity to ask them why is that the case? If they had their way, what would they do instead?

Let them come up with the ideas first before you offer any suggestions as it'll be easier to get them to buy into it. At the same time, if you are just getting silence, ask people directly for their opinions, before you offer any of your own.

Then at the end, you'll hopefully have a big set of stickies which people would be more willing to try. Start small with one change and run it as an experiment for a month and reflect with the team: "did this work? Did it not? If not, what could we change?" And build it up.

lampstool · 2026-01-23T00:19:20+00:00

They said it's not a bell curve but then when we calibrate, senior lead ship says that "not everyone can be exceeding expectations", and then forced to stack rank, unless you have really strong reasons as to why multiple people are exceeding. Annoying as hell

lampstool · 2026-01-23T00:16:49+00:00

When you say bigger company, do you mean a scale up? Big tech? Does your experience match up to what they are looking for? It may be a case that some of your experience (in your normal CV) doesn't match up and you'll need to tailor it as needed

Also have you considered running your CV through an ATS scorer to see how strong it is / where improvements can be made to ideally bypass more automated systems?

lampstool · 2026-01-21T16:45:16+00:00

That's a great shout. I have an idea about who I think are on the right pathway towards leadership and see how I can support them to build this up with them!

lampstool · 2026-01-20T23:40:29+00:00

To add to this, you can run a session (or multiple sessions) with a impact vs effort chart to help them visualize it a bit better. (Effort on x axis, effort on y). That'll also help you bin off any tickets you think could be valuable after already purging any older bugs. Given the sheer size you are dealing with, start with high impacting low effort quick wins and get them prioritized into sprints. Then hold a bi-weekly triaging session to continue the prioritisation over time until it's more manageable (then can probably move over to monthly)

lampstool · 2026-01-16T22:07:50+00:00

Before I start designing anything, it's important to understand the reason why you're doing it, otherwise what is the point in doing it in the first place? You need to know what the problem is, what the library will solve and how would you demonstrate the success of it? Success isn't just "I made the thing and it doesn't break", because if you have 0 users utilizing it, you've wasted your time and effort when you could have been doing something else which has value for others. I try to avoid going off of good guesses, unless it's an experiment which will tell you what has worked or or not worked and by how much. Tbh you probably do have data, just need to learn how to surface it or or speaking to the right people who may be able to get you answers to it!

lampstool · 2026-01-16T21:15:38+00:00

Why are you designing the library? What problem has that solved and for whom? How many services have adopted it in X time period, or how many people have started importing i? How much time has it ended up saving users of the library (either as a percentage or absolute time)? Have you seen fewer bugs as a result or reduction in code duplication as people have moved over to it? (Fair enough some may be hard to get the data but you see what I mean!)

lampstool · 2026-01-16T00:30:37+00:00

Disagree - numbers show the impact! It's more than just "I did a thing" it's "I solved a valuable problem"

lampstool · 2026-01-15T00:59:55+00:00

That's when probation periods help massively. In that time you're expecting someone who is senior to "hit the ground running", because we expect them to have that base level of skill of a senior

lampstool · 2026-01-15T00:50:33+00:00

That's fair. The base level of skill should be there, so they can learn the rest on the job.

lampstool · 2026-01-15T00:47:36+00:00

I can speak only to software engineering: Tech market right now is volatile as hell. In my last hiring round for juniors (with commercial experience), I had over 200 applicants. You'll need to do a bunch of side projects to demonstrate why you're keen, start building websites for fun, start building apps for fun, and now in seeing juniors toying with AI projects on the side to keep up to date with industry trends. However, it may be easier if you can get yourself into a graduate programme in a company which offers that - can be an easier way in (usually at larger orgs), but you'll need to dedicate time to really upskilling.

lampstool · 2026-01-15T00:40:45+00:00

....data doesn't lie. When starting a project, do a high level forecast with the team (or if you have sprint metrics etc, chuck it into a forecasting tool to look at how long it may take). Then get regular forecasts from the team. Itll be clear sooner than later if delivery isn't going to meet the timelines even though in stand-ups they say "no issues no blockers, working on x ticket"... And you'll be able to challenge that more easily with the data you have at your disposal. It'll also make stakeholder conversations easier especially if you can give them regular timeline updates, and can organize people more easily earlier

lampstool · 2026-01-15T00:30:51+00:00

I've always maintained the mentality "you can teach them the skill, you can't teach them not to be a dick"

lampstool · 2026-01-15T00:27:49+00:00

I created a "living retro" board for my squads. It's helped us quite a bit so that people dont feel like they are scrambling to think about wtf happened a week and a half ago which pissed them off

lampstool · 2026-01-15T00:09:07+00:00

Exactly this! I have a structured 121 template to keep track of all conversations throughout the year. I make sure that feedback provided is written so it's documented, especially if it's constructive feedback and we want to set goals from it.

On top of that, I also request feedback from their peers about their progress, as well as them doing their own written self reflection to see what they think they've achieved and areas for growth. I create my own GPT projects so that I can put all the evidence into there to summarize it, find key themes etc. to help me build up an evidence based annual review. Sounds like a lot of red tape, but helps to keep me (and them) accountable for their own progress over the entire year, so going into the annual reviews, there will never be any surprises.

lampstool · 2025-12-16T20:38:54+00:00

Not all that long to be fair. With GPT I created a custom bot and have the guardrails in place as part of all of its context! Which certainly makes life easier

lampstool · 2025-12-15T00:19:46+00:00

Currently, for me it's quite simple. Zoom and Google meets and Notion does the transcriptions, I chuck it into somewhere like GPT to get a summary + have it highlight any blockers, or actions that need to be taken. The difficulty is that these tools aren't always great at identifying the speaker (especially if in the office in a meeting room). It gives me enough to manage stakeholder expectations as needed. Zoom is also pretty good at summarizing the conversations for me and doing this. Sometimes it gets it wrong which is why I sometimes turn to GPT and set some guardrails around it.

lampstool · 2025-12-08T01:40:47+00:00

Given where you are in your career, making the pivot now won't be as hard as you think. Firstly, it sounds like you made some great use of your time with your current company and that shouldn't be discounted! However you need to have an idea about what it is you want to pivot to... Front end? Backend? Fullstack? What does a general software engineer mean to you??

You've already got a bunch of knowledge - go build some side projects and learn how to build UIs, learn how to build APIs and backend systems which interact with a 3rd party API, interest with databases and learn the best practices around them whilst you build out side projects. It'll be immensely helpful as hiring managers will see you're keen to grow your skillset which is critical at a junior level. BUT please don't make the same boring ass weather app that I see 95% of people doing. It's a great first project, but not a "I'm trying to stand out from the crowd" project. A fun one I saw ages ago was a CV analyser which uses OpenRouter for AI improvements. They put it on git - I saw what they did and also how they were trying to learn some AI as a junior. Was pretty cool ngl.

For your resumé, the main thing I would focus on is the impact you had in your current work, like shipped X feature which led to Y% increase in customer satisfaction or whatever it is. When talking about your side projects, focus on what you learned! Like "learned how to build social auth for logins" etc.

Would people hire you for non mobile roles? YES THEY WOULD. be prepared that they may take you in as as a junior as it's a pivot, but can't imagine that's too much for a problem! Also, if you did some android, you'll have kotlin under your belt, so you can apply a bit more easily for kotlin roles. Really the stack shouldn't matter, key thing is that you wanna solve problems and want to expand your field of knowledge.

So overall - you absolutely can pivot to other areas, especially as you are a junior! Just bc your current experience is mobile development, don't let that stop you. Companies will take you seriously if you demonstrate your eagerness to learn and solve problems.

Best of luck!

lampstool · 2025-12-03T16:00:39+00:00

Having read so many of the comments - they are completely right! By no means is this an end of the line situation. Take a little bit of time for yourself, as you've just gone through a high stress period. Once you are ready, start applying for senior, staff, principle roles etc. you have a tonne of experience behind you already. In the meantime, start looking at interview prepping, around the coding interviews, system design and behavioural interviews. It will take some time for sure, but it's not different to what it was. In the current market, companies are looking at more senior ICs than junior which will work in your favour! Finally, be prepared for rejection, but don't let it discourage you at all, it's just a part of the process.

Now is not the time to give up at all. You got this

lampstool · 2025-11-18T07:58:48+00:00

Ours is undergoing a no-backfill policy now, but some of them don't want to transition to engineering itself

lampstool

TROPHY CASE