Is it possible to build XML parser in it?
If answer is yes then i will build XML parser in it.
Solving a problem you know how to solve and solved more than once is a my goto approach in learning languge or frameworks. Translation of already solved problem to the new operational model or semantic exposes a lot internal stuff and marketing double talk.
This is a lot of work and time so can not recommend it for all cases and situations.
I wholeheartedly agree with that. Every version of Excel is massively worse than previous one. Same with the other Office products. Incremental fixes and impovements covered with unneded features and Ribbon design.
The Ribbon interface intoduction is the most obnoxious design decision that was pushed to the keyboard and mouse users. It only helps "touch" or "pen" users and only marginally.
Then OneDrive aka "we holding your data ransom" Drive. This is the only one Drive that is purelly sheit.
Which OOP? Alan Kay meant this:
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.
But there is also various other OOP around. And those really about completly different things.
People hate Java when they are forced to use it. Or when they switch from other language to the Java and expect same semantics and behaviour. Historically Java was quite bad in character/sense ratio this coupled with Enterprise patterns and people who have no idea how to write programs on java resulted in atrocious code bases with nightmare episodes. Currently I am writing non-stop Java for about 15 years. And I am able to tolerate Java quirks, because I know how to side step them. I don't like Java, but given the choice I would pick it as a language that I am willing to code for money out of many others. Java have amazing ecosystem, ci/cd culture and instruments. Dunking on "bad" language is okay especially in the joke context.
In the end there is no ideal language, they are just more or less fitting for a task or role.
And sadly one more font I will never be able to use due to missing support of non-latin characters.
Sadly some features are nice.
Game mods and Advent Of Code did it for me.
I did a small RimWorld mod and a parser for NoManSky internal format.
Creating both of them was a blast. I had fun doing programming stuff again.
Advent Of Code allowed me to try different languages in a small bursts of the different problems. Somehow I really like this format.
This really devolves into "good teams can deploy daily, can raise a small PRs and have small number of rework". And this is like... thank you, but it is obvious. If team is able to do this things constantly it is probably a good team.
DORA says that if your team is able to do same pattern (as they show) it will be "elite/good" team. This really smell like a cargo cult. And managers are already using DORA metrics as good/bad teams metric.
This is clear Goodhart's Law case: ""When a measure becomes a target, it ceases to be a good measure". So either DORA knowingly did nothing to protect against metric gaming or they didn't considered impact they will make. Neither of those is a good in my opinion.
So yeah I don't like DORA in it current iteration.
Same problem with "top 10%".
"DORA guys" came to our org in the past. And sing a song of "all successfully teams do that to, so you should too". One of the my question, that was left unanswered, was did they analyse negative scenarios to check if their suggestions actually works and add too the reducing cycle times and what not?
And most of the time my cycle time is more depends on number of meetings I need to attend through day than on anything even remotely related to the coding.
I understand what DORA tries to do, but what they achieve is just another cargo cult.
Plain Old Human language. Remember comments? Remember moments when things get very complicated and docs and comments become your only help?
That mostly because none of the languages is the best. Some of them better in some places and worst in others.
For example: Java. Amazing library range, enterprise support and feature and community reach. Java also fail in shambles when you need a low level or guaranteed performance. Erlang. Robust distributed and fault tolerant. Now try to create something that is not network, agent oriented and should work locally only.
Every language has a niche. Look at javascript. JS is only exist because of it's niche. It wasn't good as a language, but it was the only one viable solution in it's niche.
Same with assembly. Nobody sane would use assembly if it wasn't that close to the metal.
There are time tested solution in every niche and it is wise to know why they still there and what drives them.
Learn to talk to people and maintain connections. It is most invaluable skillet that will help you both carreer wise and professionally. The more people you know the better it is for your carreer. Learn to present yourself. Visibility matters very much, so it also good to "sell yourself" sometimes. There is really fine balance between making a sell and just bragging, people don't like second, but okay with first. Learn to teach other people and help them. Most troubleshooting experience I get now is from helping other people. They have a completely different way of doing code that I am (as a whole) and I am just getting this free xp by helping them and also adding one more trouble to my personal solution cupboard.
As for technology, pick what you like and master it, but also make a peeks at what is currently "in vogue". For example I really have no depth knowledge in the current frontend space, but I did take a passing looks (and build simple tutorial projects) with react, angular and dart. It didn't really required a much effort from me, but this helped in the long run to be aware.
Just a note by setting up a 30 hours home project you effectively removing "people with lives" from your hiring pool. People who can do a 30 hours either have a lot of freetime currently, or code after the job. And if you really want those people in the team then go ahead, but you are missing on 8 to 5 crowd and that is a very good and diverse talent pool. From my experience 8 to 5 minded people are very good in solving tasks in sustainable manner. They just don't have time to fuck with the system and doing effective "dont-call-me-at-night" solutions.
if you are doing a lot of interviews you need a common set of questions and measures and this take a lot of time and effort to setup.
Personally I would suggest to setup interview as a two parter first ask some theoretical questions and then ask to create a simple code with simple problem related to the questions. This helps to find out if people are really understand what they talking about. This again require a lot of thought to setup an to have small practical tasks relevant to the questions.
For example in most recent interview I asked candidate about algorithm complexity, data structures, garbage collection and then asked them create a simple dictionary to store a hierarchical structure. This helped to see if candidate knows what he is talking about and can use his knowledge in practise. I have seen a lot of people without good theoretical knowledge, but they create a code that is good and working despite their gaps and other way is also correct people have a good theoretical knowledge but fails to apply it in practice.
So figure out who you are searching for. Create an ideal checking solution for their skills and start combing the desert. There is no shortcuts in hiring, sadly.
Tldr; take offer, don't quit engineering yet, you are fine
Don't quit engineering if you enjoy it. If you have better offer and the current ship is leaky as fuck => jump the ship. Saving the leaky ships should be very profitable if it is not => you are being heavily exploited.
I jumped the ship thrice. And one time accepted a lower payed position, just because I was quite burnout.
On the topic not using the progress and not understanding the Intenals. Understanding internal will not make you senior. Understanding what you can apply that you already know can make you senior. I remember being in a situation like yours. I thought I didn't know Jack, but then on a newplace I seen people who were running around like a headless chickens on crack. This has given me a good understanding about what knowledge is and that applicable knowledge is the key.