As someone who is a Sr. Software Engineer at this point in my life, I started in mechanical engineering. I've been on both sides of the table for both positions and the differences between how candidates are evaluated is vastly different.
Mechanical engineers from my experience essentially go through talks with their future boss and coworkers to evaluate if the person would be a good fit on the team, with technical ability coming up very rarely as it's ON THE RESUME.
Software engineers on the otherhand are treated as if they do not have past experience in industry and are subjected to college tutoring whiteboard sessions (I was also a tutor in college). From my experience, the interviews rarely even introduce you to the team, or even talk about the toolings required for the job.
The hands down best software interview I've been through, unsurprisingly was not at a "tech" company, but rather Alaska Airlines. Talked about the project with the manager and how I would be able to contribute, met the team, did an actual coding exercise RELATED to the actual project that lasted 5 minutes and landed the job.
I second this heavily. I've implemented a 3d scene renderer for 3D CAM software in the past and have been wanting to get back into some 3D things to practice math as I've been feeling a bit behind where I used to be.
I spent a while getting an OpenGL environment setup in VisualStudio and got frustrated with the tooling as I've also been spending much of the last 3 years doing trivial web development. I ran across shadertoy and was able to whip up much of the core of the pathtracer there and very easily move it over to it's own project supper easily utilising REGL (https://github.com/regl-project/regl) in ~100 lines that included a camera, dynamic shader compilation based on a scene, etc...
But don't conflate tough with what frustrates people. I spent 2-3 years designing and building 3D CAM software that presented MANY challenging problems from abstracting platform API's to optimzing toolpaths for cost effective manufaturing.
Not once did I get frustrated with the learning or implemention process. The frustration in a sr devs life (in my experience) usually comes from uper management putting "really cool" features on the back-burner to never be seen again.
Legacy code is always frustrating. I had to pick up Delphi at one point to fix a bug in an application who's only job was to relay specific windows messages (essentially a broker).
5 sold days getting the environment setup (every dependency had to be in the PATH), 20 min to make the change then another 3 days getting the installer build environment setup.
I walk away if they won't compensate me. Not worth my time or the time of any engineer.
Usually the tasks are remedial like "visualize this api using x tech with y library". Things that you have 10+ github projects posted that could easily be used as a reference.
The interview process has not once proceeded when I refused a task on the basis of already having an example of the requested posted. If that isn't a sign of things to come to you, I don't know what would be.
Us car enthusiasts are pretty upset we are not getting the next Focus/Fiesta ST's. First time with a true mechanical differential and twin-scroll turbos. What a shame.
We dont even use Razor internally. Just learn the API controller side of ASP.net core 2.0 while using a modern frontend stack like Svelte/React as hot reloading is a thing that exists.
Management, it's almost always management. It's quite horrifying to watch the rest of that companies software department either leave or be driven out by the single problematic person.
Short answer: No. Shitty people will be shitty people.
Longer answer: No 30 minute exercise is going to instill in someone that the behavior they have had normalized throughout their entire life by those around them is flawed. I mean have you ever tried to tell a C developer there are alternatives?
When I first started my adventure into deep learning I became convinced that even a simple dense network could be used for storing and generating variations of 3D content.
I never took it beyond a simple dense network for a blade of grass, but I'd like to re-approach this using Tensorflow.JS. You can see the stupid simple POC at: https://jacob-ebey.github.io/gen-3d/ if you're interested.
Having experience working in CAD/CAM software, I have a feeling that the struggle in an approach like this will be maintaining meaningful output topology when adjusting parameters.
The simple approach in the grass POC was to have a single network input that was between 0 and 1 for each grass model. If we had 4 grass models, the training batch would have 4 entries with the first input being 0, the second being 0.25, etc... Then to generate a "grass" model, you could feed in any value between 0 and 1 to get a new model.
The catch here is that to maintain a meaningful output, the input models must have the same "shape". I.e the same number of vertices and indices as the indices from a base model are mapped to the new vertex values spat out by the network.
If you don't know anything about vectors, start with some game programming. If you are talking things more along the lines of Hilbert Spaces or advanced physics, there's no alternative to a good book IMO.