I avoid any company that requires a software test before the interview.

I worked for a company that introduced them after I joined, I collected evidence all of the companies top performers wouldn't have joined since we all had multiple offers and having to do the test would put people off applying. The scores from it didn't correlate with interview results so it was being ignored by everyone. Still took 2 years to get rid of it.

The best place used STAR (Situation Task Action Result) based interviews. The goal was to ask questions until you got 2 stars.

I thought these were great because it was more varied and conversational but there was a comparable consistency accross interviewers.

You would inevitably get references to past work and you switch to asking a few questions about that. Since it was around a situation you would get more complete technical explanations (e.g. on that project I wrote an X and Y was really challenging because of Z).

I loved asking "Tell me about something your really proud off". Even a nervous junior would start opening up after that question.

After an hour interview you would end up with enough information you could compare them against the company gradings (junior, senior, etc..).

This was important because it changed the attitude of the interview. It wasn't a case of if the candidate would be a good senior dev for project X, but an assessment of the candidate. If they came out as a lead and we had a lead role, lets offer them that.

Similar to most navies.

Engineering's workload won't really change, they'll do certain types of maintenance.

Most navies don't have command staff on the bridge full time. There would be a watch officer who is fairly junior learning how to operate the ship so the down time is an opportunity for them to grow and learn.

Most navies seperate the captain and first officer, with the first officer involved in running the ship and the captain running the big picture.

So you would expect the first officer to spend the time checking on every department to ensure they are up to standard.

That would mean department heads would be running drills or bringing equipment down for maintenance so its ready.

The captain would likely be planning and thinking through the encounter.

For any free time senior officers have there is probably a mountain of reports (personnel, ship, intelligence, etc..) to read and keep tabs on.

Years ago there was no way to share IDE settings between developers.

You ended up with some developers choosing a tab width of 2 spaces, some choosing 4 spaces and as there was no linting enforcement some people using 2-4 spaces depending on their IDE settings.

This resulted in an unreadable mess as stuff was idented to all sorts of random levels.

It doesn't matter if you use tabs or spaces as long as only one type is consistently used within a project.

Spaces tends to win because inevitably there are times you need to use spaces and so its difficult to ensure a project only uses tabs for identation.

IDE's support converting tabs into spaces based on tab width and code formatting will ensure correct indentation. You can now have centralised IDE settings so everyone gets the same setup.

Honestly 99% of people don't care about formatting (they only care when consistency isn't enforced and code is hard to read), there is always one person who wants a 60 charracter line width or only tabs or double new lined parathensis. Who then sucks up huge amounts of the team time arguing their thing is a must while they code in emacs, unlike the rest of the team using an actual ide.

The linux kernel is very old school in how it is run and originally a big part of the DevSecOps movement was removing a lot of manual overhead.

Moving on to something like Gitea (codeberg) would give you a better diff view and is quicker/easier than posting a patch to a mailing list.

The branching model of the kernel is something people write up on paper that looks great (much like Gitflow) but is really time consuming to manage. Moving to feature branch workflow and creating a release branches as part of the release process allows a ton of things to be automated and simplified.

Similarly file systems aren't really device specific, so you could build system tests for them for benchmarking and standard use cases.

Setting up a CI to perform smoke testing and linting, is fairly standard.

Its really easy to setup a CI to trigger when a new branch/pr is created/updated, this means review becomes reduced to checking business logic which makes reviews really quick and easy.

Similarly moving on to a decent issue tracker, Jira's support for Epic's/stories/tasks/capabilities and its linking ability is a huge simplifier for long term planning.

You can do things like define OKR's and then attach Epics to them and Stories/tasks to epics which lets you track progress to goals.

You can use issues the way the linux community currently uses mailing lists.

Combined with a Kanban board for tracking, progress of tickets. You remove a ton of pain.

Although open source issue trackers are missing the key productivity enablers of Jira, which makes these improvements hard to realise.

The issue is people, the linux kernel maintainers have been working one way for decades. Getting them to adopt new tools will be heavily resisted, same with changing how they work.

Its like everyone outside, knows a breaking the ABI definition from the sub system implementation would create a far more stable ABI which would solve a bunch of issues and allow change when needed, except no one in the kernel will entertain the idea.

As an admin, how do kbin moderation tools compare?

Also does lemmy.world have the spare cash to offer cash for features?

I have a Mac book Pro for work.There is just a lot of random weirdness.

There is no right click, your supposed to do a light two finger touch for right click.If you click too hard it opens the dictionary.

If you plug in a mouse you can get right click, but it isn't consistent in working.

By default scroll is inverted (up is down, down is up), also windows can have scroll bars but they aren't clickable, you have to do a scroll gesture.

Almost every Left control + Button action is now Meta key + button. But not everything, its annoyingly inconsistent also new random shortcuts.

For example lock screen isn't Meta key + l like on Linux or Windows. Its Meta + Shift + Q, shut down is Meta +Left Control + Q.

The keyboard doesn't match the your countries layout, so keys move around and is missing traditional keys like print screen. To do that you press Meta + Shift + 4 to switch the mouse to a screen cut tool and select the area you cut.

I could go on and on, none of it is obvious and I wouldn't say any of it is an improvement at best its just different.

One of the reasons for the #DevOps movement is developers see building and packaging as #notmyjob.

The task would historically fall on the most junior member of the team, who would make a pigs ear out of it due to complete lack of experience.

This is compounded by the issue that most C/C++ build systems don't really include dependency management.

Linux distributions have all tried to work out those dependency trees but they came up with slightly different solutions. This is why there are a few "root" distributions everything branches from.

That means developers have to learn about a few root distributions to design a deb/rpm/aur package systems to base their release around.

That is a considerable amount of learning in a subject most aren't interested in.

The real question is why don't package maintainers upstream a packaging solution?

No, UK beaches were increasingly becoming the cleanest in Europe.

However that stopped around 13 years ago and the water companies keep emergency dumping waste water.

If your goal is to advertise the fediverse You should have used 'kbin'.

People can go directly to "lemmy.ml" but the site might disappear due to Mali re-establishing ownership of .ml domains, also its run by a tankie which will upset some people.

"Lemmy" provides 10 google sponsored results and then 'join-lemmy', the join-lemmy website has you 'join a server' and then presents you lots of options.

During the first Mastodon surge one of their issues is people felt overwhelmed by the options and it hurt Mastodon adoption, so a single website does make a lot of sense. Personally I would suggest lemmy.world its a general instance and the admins aren't linked to any extremist views, but you said that would be too long.

If you put 'kbin' into search the top result is kbin.social, that makes it seems like a reddit alternate. It keeps user choice limited and brings them into the fediverse. That means people aren't confronted with the complexity of the fediverse immediately and can learn and understand it at their own pace.

So if your goal is to advertise the fediverse I would push kbin, if your goal is to specifically get people to use a Lemmy based website I don't think you have a good option

I am currently teaching python and JavaScript devs Typescript. Everytime they hit a problem they switch to any

Sigh

Reading the article that isn't the goal.

They are working on controlling access to the wider internet. The goal is to push people off of western services on to ones they control. This is so they can control the information their citizens see

They wouldn't stop Russian bot farms or hacking.

You've just moved the packaging problem from distributions to app developers.

The reason you have issues is historically app developers weren't interested in packaging their application so distributions would figure it out.

If app developers want to package deb, rpm, etc.. packages it would also solve the problem.