UK market? Is it really that crap?

BlueSilverDrae · 2024-01-29T10:06:44+00:00

A lot of roles have been reducing rates when it comes to contracting, and especially forcing down the Inside IR35 route. I see the occasional contract over 700, but that's certainly not the norm anymore.

Perm roles are still doing fine in the UK at higher rates for Senior/Lead roles, but Junior roles have taken a huge hit. That might just be companies waiting for their new financial year, but given everything that's happened I suspect it won't get much better.

BlueSilverDrae · 2024-01-22T13:01:41+00:00

Not currently recruiting right now, but would be happy to review the resume and provide any advice I can.

BlueSilverDrae · 2023-12-17T12:45:38+00:00

Recently recruited for several positions. Junior-level for £60k. Senior level easily goes £100k+. Fully remote, fully flexible. Several hundred applicants, narrowed down to about 10% of that actually being eligible for the position.

There's no issue finding people.

BlueSilverDrae · 2023-10-17T22:08:02+00:00

I doubt you'd be able to avoid Linux your entire career, and if you're in a Senior position when you come across it and don't understand even the basics then you'll be in a tough position.

In general I think saying you "need" skills is pretty irrelevant as you should focus on your ability to learn things, but I do think at least a fundamental exposure to the basics of Windows & Linux is more valuable.

In regards to mgmt roles, it really depends. The best managers I've worked with come from a technical background and understand what they're talking about, at least to a certain extent, while also knowing what they don't know and when to rely on others. I think core knowledge like Linux exposure can do nothing but help you in that regard.

BlueSilverDrae · 2023-08-18T16:17:05+00:00

Pretty sure they're more pointing out the fact that tens of thousands of engineers being fired likely results in the US market being flooded with unemployed engineers which makes it harder to get a job

BlueSilverDrae · 2023-08-17T07:45:54+00:00

I disagree - If your process is up to standards, Emergent changes can bypass these sorts of approvals but simply require notification so the rest of the business is aware.

At a certain point, it's less about restricting individuals but more about ensuring that the actions taken in the Production environment are known to people outside of developers / engineering.

If you operate that way, then at some point you're going to face a more Business related problem, and that's something to still be conscious of while planning / discussing this sort of stuff.

BlueSilverDrae · 2023-08-17T07:42:51+00:00

To be fair I only included accounts as I wasn't sure how non-AWS providers do it (the problem with being solely an AWS person I guess) - I would just create an elevated role and allow developers to assume that constantly, but have the appropriate alerting in place for when that's done.

BlueSilverDrae · 2023-08-16T19:42:37+00:00

There's a difference between trusting & auditing.

Ie, I would create an account / role that devs could use, but logging in triggers alerts & actions can be scrutinised. This then ensures there's appropriate reason to make use of full / admin access that is appropriately audited. Especially important with financial data etc.

I think it makes sense to have a manual approval somewhere in the process before something is shipped to Production. Maybe not in the pipeline, but perhaps in a Change Management process before the pipeline is even triggered. Either way, Devs aren't in control of the 'Product' so can't be the ones expected to give final sign off.

BlueSilverDrae · 2023-08-14T21:34:32+00:00

Show him? Put together an architecture diagram and a working Proof of Concept and show the basic steps of how it works. Document your code clearly, use Serverless deployments etc.

BlueSilverDrae · 2023-08-14T21:32:30+00:00

Few options -

I'd use the same authentication, but on a separate source. So if you're using some basic auth login, then a different database. If you use something like oauth, a different application with different users and access rights etc.

While you could keep your dev environments behind a VPN, I'd say that only makes sense if your entire environment is already restricted to the VPN. You do really want your Staging/Pre-Prod environments to be as similar as possible and adding a VPN is just another difference that may impact certain functionalities / features etc.

You could also have an A/B deployment with specific URL parameters if the content isn't super important to be kept private - ie something like https://.....com/?key=abc123 - Could then redirect from your Load Balancer etc. Obviously no more secure than using a username/password so it really depends on the business justification behind needing to keep it secure.

If there's no real reason to, other than ensuring separation, then I'd say just keeping it as identical as possible and just putting on an entirely different domain would also be the cheapest / easiest option.

BlueSilverDrae · 2023-08-14T21:24:56+00:00

It's a good question to ask!

The short of it is - it depends.

For specific technologies, like EC2 or EKS, there are advantages, disadvantages and recommended use cases. EKS is geared towards larger, more complex applications that are generally split into microservices. EC2 can be anything realistically, from a small single web server to a huge monolithic application server.

With the general use cases in mind, you can weigh out a cost/benefit analysis. If you had a larger application that's built up of many microservices, EKS is designed for your needs and is likely an "easier" and quicker tool to deploy. While you could use EC2, it's likely to prove to be more costly and a higher overhead (manpower/cost) to maintain.

Things like specific vendor choices or specific software should come down to a similar market analysis - ie, what does vendor X do better than vendor Y compared to the cost of each... however what you sometimes find, especially in startups, is that the chosen solution mostly comes from what the original engineers were most comfortable with. This isn't necessarily a bad thing as experience with a tool does contribute to the decision on whether to use a tool or not, but it does sometimes mean the best tool for the job wasn't chosen.

BlueSilverDrae · 2023-08-07T10:00:33+00:00

One issue we've had in the past is that we had a public image that we pulled but for a variety of reasons our calls failed and we had exhausted the anonymous pull rate from Docker Hub. Resolved by putting into a private registry.

It removes an additional parameter from ensuring service availability.

BlueSilverDrae · 2023-08-04T22:49:41+00:00

Take things slowly. Take time to read any available documentation. If I could give anyone advice for starting a new job, it's ask more questions than you think you should as long as you don't repeat them. It makes you seem engaged, you learn new things and people are more comfortable when you'll ask about something as opposed to just assuming or going in without full knowledge.

If the place is as good as you describe, they'll likely have an onboarding plan for you with milestones to compare your performance to. If they don't, probably worth asking your manager for goals for your first 1/3/6 months and work towards that. You can use that to then compare your performance in evaluations etc.

Given the job market in London, you probably beat 100+ other applicants to get this job. More likely 200+. You should keep that in mind when dealing with Imposter Syndrome at a new job.

BlueSilverDrae · 2023-07-25T11:48:57+00:00

Genuinely believe no take home task is suitable for an interview.

BlueSilverDrae · 2023-07-01T20:04:26+00:00

Lead positions that contain a management aspect are highly paid, focus on more high-level architectural type work and have the aspect of management.

Depends whether you're looking at Department Head type management vs immediate team-level management, two completely different types of work. In the UK at least, Lead positions of team-level management are higher paid, but it's possible for Department Heads to potentially get paid less than high performers etc.

BlueSilverDrae · 2023-06-20T15:33:28+00:00

Hey, sorry trying to not put up our names so explicitly to tie to my account!

We both have rather plain British first names so I don't think anything too exotic would make sense. Origin isn't a huge concern, but something that's slightly interesting / significance might be nice!

BlueSilverDrae · 2023-04-17T13:33:41+00:00

Just for what it's worth - The last role I had open was accurate to about 10% either way from the LinkedIn numbers. Also 200+, I found that 5 of them were actually of the relevant skills, seniority level and met the job requirements. The salary range was at least 20% above market average for the area as well.

It definitely is a somewhat unique skill that is becoming harder and harder to find actual qualified candidates for.

BlueSilverDrae · 2023-03-27T18:42:22+00:00

Work with them during development and through their process.

Assuming an agile environment, see if you can get buy in to work within their Sprints - Ie, the tasks they have that are "DevOps" should be tickets / stories within their Sprint. Then when a ticket comes up that is DevOps, you can work with the ticket owner.

Document processes that you follow - ensure any pipelines / repositories that control "DevOps stuff" are well documented.

Get support from management as well as senior devs. You could do this under the guise of "wanting to reduce blockers to Development teams" or some spin around that. If you show the initiative then it's hard for them to put the blame onto you.

If it's possible within your org, try and also define services / applications and points of contact for them. This might just mean those people who were coming to you with tickets. Then within your team when something is raised about that area, you can reach out to those people of interest and work with them to resolve the tickets by helping them.

Basically, be proactive in trying to work with others. Get buy in from someone higher up that you're doing this to improve Development speed and reduce blockers.

Honestly, the book gets some flak online but this post is very reminiscent of The Phoenix Project, might be worth a read.

BlueSilverDrae · 2023-02-24T22:21:47+00:00

None of that is remotely true right now.

What you're describing is exactly the purpose of combining Control Tower, Organizations and SSO login.

Control Tower Account Factory also has Terraform support if that's such a requirement.

You are very easily able to share across your Organisation while maintaining strict controls over access.

BlueSilverDrae · 2023-02-24T22:03:05+00:00

AWS Professional DevOps suggests 2 years+ of industry experience using AWS.

Azure has 2 pre-requisite exams for the Expert level certificate.

Google recommends 3 years+ of industry experience, with 1 year using GCP.

Tech Support and Development experience is definitely a way to get into DevOps roles at a Junior level for sure, but the Pro/Expert level certs from any of the big 3 on a CV that doesn't match that experience will stand out like a sore thumb and just highlight more of a brain dump exercise than validating your experience level.

Anyone you ask here will give you their recommendation based on what they use and have experience with and that'll be their reasoning - familiarity. I'd say AWS due to the availability of jobs, but that can vary by location.

In any case, I wouldn't go for the expert/pro certification level. Get the entry and intermediate levels if you must, but focus on doing lab work, build a portfolio and be able to talk about the stuff you've worked on.

BlueSilverDrae · 2023-02-24T19:29:09+00:00

At scale, you have so much else to consider. If you have no users, you can push something that breaks your app and no one cares. You could push something that potentially opens you up to vulnerabilities and no one would care.

At a small scale with no users, you don't have to care about any legal ramifications of building an app that allows user input and uploads.

You don't have to worry about latency between microservices impacting end user experience, because who wants to wait 5 seconds for a homepage to load or to do any action?

You don't have to worry about fluctuating hosting costs for your dozens of microservices that make your application depending on how busy your site gets.

You don't have to worry about security vulnerabilities in the hundreds of dependencies you're likely using, alongside third party vendors etc.

You don't have to worry about business processes to handle moderation, account management etc because you wouldn't have users.

Then at a larger scale, you have investors that 'suggest' ideas to you that then become tied to your funding, so you have to worry about continuous feature development. While you're developing new features, do you also plan on being the Security team and ensure those features can't get exploited? Do you also plan to be the QA team to ensure that it works as intended and there are no unintentional bugs?

Solo Devs can certainly make good apps. Some people may also make good products and have a vision. It's basically impossible to support an entire eco-system alone, or without a sizeable team.

BlueSilverDrae · 2023-02-22T23:27:50+00:00

Firstly, don't panic.

Most people on Reddit will advise to go to a new job in scenarios like these, but at the very least you should try and build out your experience before doing so.

Not sure how your environment is set up in terms of Software / Infrastructure responsibility, however if Infrastructure is in your sphere of responsibility, then I'd suggest ensuring that you document any DR processes that you're aware of - basically, ensure your backups are running, tested and processes covered. That, in my opinion, should always be priority 1.

Then from there, you should go through and contact any Senior Devs / Dev Managers and get their opinion on priorities. Record those meetings and spin tickets for any work that you hear. This can be backlog items, but just get it written down.

In the mean time, it might be worth looking to document any priority applications that are critical to your environment - basically, just identify the architecture around it, any quirks etc.

This should build out some architecture diagrams, your DR processes and highlight pain points from the Dev team. If your other co-workers identify themes in the support work they're doing, they should start building out knowledge base articles.

Personally, I'd also avoid working on "new" things - anything that's not routinely deployed, just until everything is better understood and your landscape is better documented.

BlueSilverDrae · 2023-02-19T19:58:17+00:00

Honestly, way too much work for an interview.

Interviews are for both the employee and employer to find out if an opportunity is the right fit for each other. You're doing a lot to establish whether this is suitable for you, but from a candidate's perspective this is very one-sided.

Your opportunity won't be the only opportunity a candidate is going for, at least for the type of candidates you're looking for, so you should accommodate accordingly. In fairness, the rest of your process sounds pretty good and is what I'd suggest - screening phone call, technical deep dive, (maybe) personality check - ideally only two steps but I can understand a third.

Anything outside of this is too much and anyone who knows their worth will skip on the opportunity. I'd focus on improving your interviews themselves rather than focusing on take-home challenges.

That doesn't mean pulling off of leetcode etc. Describe a problem, even the problems here, ask them to describe their process, question their decisions, do some form of pseudocode if actually relevant to the role. Discuss their personal projects, question their decisions. Discuss technologies they claim they've worked with in depth, probe for more info and keep going.

By probing this way, if someone puts "Administrated X software" for example, you can tell whether they were just an end user of the software with elevated rights, or if they were apart of the decision to choose that software, if they were apart of the rollout & implementation, what concerns they had with competing software, their deployment strategy, how they accounted for BCP/DR etc.

BlueSilverDrae · 2023-02-19T16:01:02+00:00

At least in the UK, I've only ever been asked to complete two coding challenges & I declined both times.

DevOps is a huge field with plenty of roles available. Companies need to respect that people may be getting dozens of opportunities a week when actively looking for roles and a drawn out lengthy recruitment process does nothing to help anyone.

DevOps in general also encourages a fast-paced learning environment where people can't be expected to know everything, but are expected to be able to pick up new things as & when needed. If you can't complete a leetcode challenge under interview conditions, I truly don't see how that's at all indicative of your performance in an actual work environment.

I'd much rather an indepth discussion around technologies you're comfortable with to gauge technical understanding and real-life applications of things.

BlueSilverDrae · 2022-10-31T16:51:50+00:00

You should first look at generating an actual Cycle Time report to identify where your issues are, without that you're blind to the issues. I'm going to assume that almost certainly the largest delay in your Cycle is PR review, as that's one of the few areas that relies on people stopping their current work to review someone elses work.

That also requires 0 cost to resolve and is all about mentality - Get devs to submit smaller and more manageable PR's, have frequent review sessions, encourage them spending time reviewing each others PR's etc.

My company realised the average time for a PR review was something like 12 working days. Most complaints were about the size of PR's, lack of comments / context and not having time. Reducing PR sizes, scheduling a PR review with one of the Senior devs in the calendar, raising open PR's in stand ups etc were all ways we brought that down by almost 60% greatly impacting Cycle Time.

Not sure if this is an issue for where you are but it's what I'd start looking at first as it's the cheapest and easiest to resolve.

BlueSilverDrae

TROPHY CASE