You probably also booted it to run the disc formatting software.

But yes, the manual was very good, also the magazines with their type-ins.

They really are trying to separate the chaff from the wheat.

There's a difference between Graduate, Junior, Mid-level and Senior developer. Never mind technical specialisations and architecture roles above those.

If you have three years experience, you cannot apply for senior developer roles in the current market, and this test will detect that you are not ready. People are having difficulty with the tasks because they don't have the breadth of knowledge required for the roles.

"OK, we're going to build a To Do List app right now" - I'm going to assume a Java job. C# is equally simple.

Gather requirements verbally, it will turn out they are trivial, see below.
Create new Spring Boot Project with Maven/Gradle - the IDE should do this for you, or do it at spring.io
Create a Domain Model for the ToDos - a few model classes, maybe even just one to model a todo item
Annotate with JPA (or create some JDBC in your own DAO)
Create a controller to Add/Mark Complete/Delete ToDos
Add some integration tests using SpringBootTest (if you're clever you'll do some TDD)
Test using Postman.

I'd prefer to be given this as a task to do at home and then explain in the interview, but it's not the worst thing.

3 hours seems about right. Now if they wanted a front end as well, well, that's idiotic.

Note if you have ADHD or similar neurodiverse traits - then just remembering stuff is not very reliable. It's not great having a brain hardwired with 'out of sight, out of mind'. Also you never remember this when you are being told of something to remember, grr - or if you do and you go to make a note on your phone or notepad, the other person gets offended you are doing something else apart from devoting everything to what they are saying - so you learn from experience to not take notes when you should, then later you get moaned at for not doing it.

And paper lists are the solution. Digital lists, apps, etc, simply don't work. Because you have to open them up. And they're out of sight when they're not opened.

Appointments are actually something that devices do help with, because of the alerting functionality.

Also garbage day might be a fixed day, but alternating weeks are recycling or household waste, and that's never easy to remember. But you have a waste collection calendar from the council on the pinboard (a giant pinboard is a great investment) to check. Not an app.

Europe was always a good market for EV adoption anyway.

Far shorter commutes, and people don't feel they need a 500 mile range because they rarely drive it, whereas in America it appears to be part of the American dream to do long road trips.

Tesla sell well, but there are lots of other EV manufacturers on the streets - European and Asian, not American. VW id.3 and id.4 (id.2 and id.7 coming out soon, to widen the market) whirr around a lot - they seem to be what the VW Golf (and Polo for the id.2) owners like to migrate to. Hyundai are common too.

The thing that is not helping EVs over here is price-gauging commercial recharge stations. But some EVs are soon coming with solar roof options, which could work well for short-range drivers who often WfH. Cities over here have parking issues (lots of on-street parking) that limit home recharge options, and stop EV uptake, but it's the cities mandating low emission rules first...

Thousands of well spaced turbines are hard to target. Take a few out, sure, but that's not going to change anything.

No, there's the lead Java Minecraft implementation still. That's what PC users will use to play.

The C++ Bedrock version for mobile/console/windows is developed in lockstep, mostly.

Given that most enterprise software is written in Java, it is not an 'academic exercise' language and it just shows that you don't know what you are talking about.

Game libraries have been around for decades - lwjgt for example.

Serial? Sure, java.comm is deprecated, then there's RxTx library, and also jSerialComm library. You might say "but that's third party" but that's not an issue in the real world. 99% of java devs don't need this, so don't mandate it.

Noddy examples rarely make for a good comparison. The language optimised for the noddy example will look better.

As soon as your Java console application uses even a mildly complex data structure, that BASIC application is going to descend into DIM hell.

To be honest a Java developer from 20 years ago would probably fail to recognise a lot of a modern Java 17 SpringBoot application as being Java from a glance in an IDE that already hides the verby stuff.

Lombok was great. Now there are records (finally!).

I did some Clojure programming a few years ago. The apps were compact and highly functional. The repl was great. But it ran on the same in-house JVM infrastructure.
Now? Unmaintainable for new devs, because most people don't know lisp, and it never really took off in a big way.

You shouldn't be writing classes that big in the first place. It sounds like they are doing too many things, keep things simple, each class should care about a minimal set of related functions. I appreciate that if this is a GUI application it can be difficult, and that it's easy to argue that the hard linking of Java class name to file name, and package name to filesystem path was not a great idea as well.

Your processing classes don't need to be instantiated and destroyed all the time. Instantiate them at startup and leave them be, or if they are rarely needed, just have a factory class to create it once on demand, and re-use it afterwards. Obviously it depends on your application, so ymmv but long classes are usually a red flag to a poor underlying design.

@SpringBootApplication is what a lot of people use for their enterprise Java application. No main needed, because the framework isn't dumb (there's a main somewhere in the framework of course)

For plain old Java, adding (eg) @JavaMain to a class that just created a main method that called the constructor on that class with the args (perhaps pre-parsed by a decent args parsing library) would be fine.

But really, this is a worth-nearly-nothing suggestion, because whilst main is verby boilerplate, it occurs once in an application. Java has removed a lot of other historical wordy stuff though, so if it can be done safely then why not.

"They would come with ... a lower salary"

Nope.

That's not how contracting works.

Underfunded schools explains all of the declining figures, these are things that good schools can teach to students. Additionally parents need time to be with their children, but they have to work more and more to make ends meet.

Playing computer games explains the rise in spatial reasoning scores.

Let's see the results broken down by social standing, access to private schools, parental work load and stress, and so on.

Yeah, "Just Egg" is clearly mislabelling. "Not Egg" or "Plegg" or similar would probably be fine. I guess it's chickpea based?

But this was clear - "Milk" is Cow Milk. "Almond Milk" is its own thing, same with "Soy Milk". Nobody is confused, and they're in common usage. Time to move on and stop getting offended that language evolves.