Hi! I was late into the software game, or really I had a career reset. Breath a sigh of relief, your career is not over.
1. Age does not play a factor
2. Resume progression looks cool but practically means nothing. I have hired engineers that have been demoted (maybe adversity yields character.) I'm determining if you can pass my interview, not the last person's.
3. Software Engineers go in and out of relevancy all the time, the only difference is that you're noticing it during interviewing.
Now, as a drop out, I had to learn things on my own. I'll go over what I expect out of a Senior engineer. Keep in mind I work on a team where algorithms and data structures do matter, not all teams are like this. So, think about what you want your next team to be about.
1. Have knowledge of how algorithms work and what data structures work best with them. This is useful when dealing with tasks that must scale incredible loads.
2. Asymptotics. I generally only ask Big O questions, but know what the others are too. Big O is either memorization or a deep understanding, either is fine for Senior. You would need to be able to answer time and space complexity questions in my interview, in the form of, "walk me through the time complexity of what we just did." Sometimes I'll ask about space complexity but only if I see that you allocated memory for reasons I don't understand.
3. Abstract Systems Design is my love-child. Be inventive and take calculated risks. I don't expect you to be perfect, but I do expect a data-informed plan.
4. "Clean code" is a hyped term but it will communicate something about you. Use clearly defined interfaces and keep your concerns/domains separated in code. I'll explain a bit more below.
5. Learn to write tests with definitive outcomes. Usually when I'm helping a SWE with a problem and I'm short on time it's easier to crank out some tests that will keep them within my expectations rather than hold their hand the whole way through.
The whole "clean code" thing is iffy, imo. I learned to write good looking code by attaching linters, formatters, and static analysis tools to my IDE and learning through repetition. Designing good applications was harder, but it dawned on me when I had to write multi-threaded applications or applications that implement concurrency. You will start to naturally separate your code if you start doing this.
Learning asymptotics was iterative for me. Start on one of the Big O cheat sheet pages then Google each data structure/operation to understand why it works out the way it does.
There are lots of tutorials for learning to identify algorithms and data structures. This will be time consuming, but it can also yield benefits in your work depending on what you decide to do next.
1. Age does not play a factor
2. Resume progression looks cool but practically means nothing. I have hired engineers that have been demoted (maybe adversity yields character.) I'm determining if you can pass my interview, not the last person's.
3. Software Engineers go in and out of relevancy all the time, the only difference is that you're noticing it during interviewing.
Now, as a drop out, I had to learn things on my own. I'll go over what I expect out of a Senior engineer. Keep in mind I work on a team where algorithms and data structures do matter, not all teams are like this. So, think about what you want your next team to be about.
1. Have knowledge of how algorithms work and what data structures work best with them. This is useful when dealing with tasks that must scale incredible loads.
2. Asymptotics. I generally only ask Big O questions, but know what the others are too. Big O is either memorization or a deep understanding, either is fine for Senior. You would need to be able to answer time and space complexity questions in my interview, in the form of, "walk me through the time complexity of what we just did." Sometimes I'll ask about space complexity but only if I see that you allocated memory for reasons I don't understand.
3. Abstract Systems Design is my love-child. Be inventive and take calculated risks. I don't expect you to be perfect, but I do expect a data-informed plan.
4. "Clean code" is a hyped term but it will communicate something about you. Use clearly defined interfaces and keep your concerns/domains separated in code. I'll explain a bit more below.
5. Learn to write tests with definitive outcomes. Usually when I'm helping a SWE with a problem and I'm short on time it's easier to crank out some tests that will keep them within my expectations rather than hold their hand the whole way through.
The whole "clean code" thing is iffy, imo. I learned to write good looking code by attaching linters, formatters, and static analysis tools to my IDE and learning through repetition. Designing good applications was harder, but it dawned on me when I had to write multi-threaded applications or applications that implement concurrency. You will start to naturally separate your code if you start doing this.
Learning asymptotics was iterative for me. Start on one of the Big O cheat sheet pages then Google each data structure/operation to understand why it works out the way it does.
There are lots of tutorials for learning to identify algorithms and data structures. This will be time consuming, but it can also yield benefits in your work depending on what you decide to do next.
I hope this helps!