That's something that really astounds me with this async thing.
Why on earth when they introduced it they didn't add a way to tell the browser the order of execution ? Or may be it exists and I haven't heard about it ?
There is a way: ES6 modules. If you can account for the order of execution (with modules or custom loaders) async is, in almost all cases, the best way to load your scripts. Defer (or body-end) scripts also specify the execution order, but only in a strictly linear fashion which usually has a performance hit.
Idle games are usually not optimized for performance. It's running bigint style operations in a tight loop. Mobile phones are not what you should be playing these games on.
Well, I had no problem in playing Swarm Simulator [1] in my phone other than that incremental games intrinsically need an enough screen to be aware of everything. In the case of the Universal Paperclips, its simulation step is too slow (e.g. its handling of projects is suboptimal) that its internal clock will drift over the time. That's why it reports far less time in the notification than the actual wall clock.
I used to do that (and there are out there many commented lines on old projects that are still active).
Now, I backup the source file somewhere for archive, run multiple tests on the new code, and make an obligation for me to deliver a cleaned source file, with no other comments than the one needed.
It's more clear when you go back to your code to not be distracted by old thoughts.
Then the hiring firm is a group of fools best avoided.
Tools change like fashion. What is "hot" today will be nearly frowned on in 5 years and forgotten in a decade or so. In 20 years the fundamentals still matter, the tools, not so much (Pascal? Powerbuilder? Win32 in C?)
A smart developer can learn any tool. Hire for aptitude, not today's toolset.
I agree. Of course, there is a "spin-up" time and we prefer to select the competent candidate with skill in our tools vs the competent candidate with skill in a different tool; but absolutely a competent developer should be able to adapt to any environment.
Interviews can help accommodate this by allowing the candidate to solve a coding test in a language of their choice, while also inquiring about the candidate's learning plans. (Want to make sure they are willing to adapt to the team's tools and not try to force the team to adapt to them!)
I took a job once where the code base was in a FORTRAN-derivative language. I had never used FORTRAN or anything like it. Not a problem. I studied the code. I studied the docs. I figured it out and did the work. I would expect nothing less of any other competent developer.
Another job had a toolchain based on NodeJS on the server-side. Never used NodeJS. Not a problem. Studied the code. Studied the docs. You know the story.
The key skill is a developer's willingness and ability to learn the tools that are desired for the job at hand, and to accept and learn new tools when the time is right.
Isn't the point of an internship to continue your formation ? How comes companies making the same tests as for recruiting for real jobs ?
"Hi, we are not going to pay you, or not very much, but please be at the same level as senior that are already working for us"
I had interns back in the day I had an office (and not working from home) and I always made them work on basic tasks under my supervision. Once I had one woman who was very good, and she worked on a website that ended in production, but most of the time the purpose was to work on internal projects that can be used even if not perfectly polished. You know, stuff you always say you're going to do some day, but you don't.
The advantages were on both sides. They learned real life cases, under my supervision, and I had the tools I didn't.
Disclaimer : I'm French so maybe my example is not relevant.
>How comes companies making the same tests as for recruiting for real jobs ?
1) Because desirable internships have more candidate applications than available slots. E.g. Google has 40,000 students wanting an internship but only 1500 slots.[1] With that supply & demand ratio, Google can be selective via difficult coding tests.
2) Even though internships are unpaid, companies evaluate interns to potentially offer permanent employment. If so, a company like Google would want to fill those 1500 slots with "the best" rather than randomly pull from 40000 candidates.
That's how it is at the hot tech companies. Maybe other internship programs outside of tech sectors such as Peace Corps think of interns differently.
We give coding challenges to our intern applicants, and most fail. We give different challenges and expect different levels of competency for a senior role.
Code challenges at least have the capability of being very useful. We try and present the type of problems people will have to be solving in that position; if they struggle with it and someone else excels, they have done their job.
Ok, you can die because of religion too, in many, many countries.
But I guess it's not a good thing, no ?