My Skills

My primary learning direction is full-stack engineering with probably a frontend focus – I enjoy the complexity of full-stack applications.

Software engineering (in contrast to many other kinds of engineering) contains a widespread array of technologies that change extremely quickly. Hence, self-learning is very important and I believe that over a certain level of experience, one should know what they don’t know. Let’s see a rough assessment of what I learned so far in each area.

If you are curious, too, head over to some roadmap site like and assess yourself – I’d be interested to know how your knowledge progressed over time. 🙂

Frontend engineering


90% – will write pixel-perfect HTML for food

Everybody mentions these when it comes to frontend development. I can write and easily navigate vanilla HTML/JS/CSS, with or without frameworks, even if it’s not really needed today. I love latest CSS stuff such as flexbox and grid, but haven’t used many CSS preprocessors and mostly don’t get why they are often being asked about in job interviews since they are not complicated to learn.

I try to write semantic, accessible HTML at all times if possible, even if using some framework to abstract away the details. For JS, I mostly use and prefer Typescript for added type safety, but personally dislike its class syntax.

Next up: just keeping up with the latest JS language improvements. Each year the web is getting farther and farther away from vanilla HTML/JS/CSS.

Frontend frameworks

80% – I know the ‘big 3’

I can use and have had projects in Vue, React and Angular, probably in this order of preference. I see the similarities and the core differences between these frameworks and could teach how to use them to any developer.

State stores are preferred by me if app complexity reaches a certain (not so high) threshold – I have used Ngrx, Vuex and Redux. I also occasionally use some simpler templating libraries like handlebars.

Uncharted: I lack experience with mobile app development such as React Native.

Next up: keep up with new frameworks and keep an eye on truly new ideas like Svelte (which promise faster apps and better development flows but are not quite yet ready for larger-scale apps). IMHO the functional syntax of React hooks (and probably the upcoming Vue 3.0 composition API) will stick with us for a while.

Frontend architecture

70% – will have a good attempt at building your app

I know how a frontend app is built up and can bootstrap it quickly with some tooling like CRA or Yeoman. I could even configure Webpack but like most sane people, I don’t want to.

I can architect small to midsize apps with relative confidence, including API use, authentication, services and even some Websocket.

Tests are useful, and I enjoy using Jest for component unit/integration tests and Puppeteer or Cypress for end-to-end testing.

Next up: I don’t have much hands-on experience with SSR or GRaphQL yet, but it’s just one learning step away from my current knowledge level. These are more like niches that are good to learn but not used everywhere.

Backend engineering

This is an interesting part, especially that there is no ‘definitive’ backend framework or language like the HTML/JS/CSS trinity for frontend. Instead we have a lot of languages, ecosystems and even more custom architectures. So rather, we should approach this assessment from a domain perspective.

OS/runtime environment basics

70% – will hack anything with a terminal, but get stuck in MS world

I’m a *NIX guy. 🙂 Adept at using Linux systems, terminals, services, SSH tunnels, scripting shell if needed. I don’t have much Windows experience though.

Uncharted: for me, Windows is a peculiar OS necessary to be used when playing some recent games. I could maybe learn some WSL or Powershell but don’t really feel inclined to do so.


60% – hire a database engineer if it’s more than using Redis/SQL

I only have PostgreSQL experience, quite much of that. Basically, I understand basic ACID principles and can do a lot of stuff that a software engineer needs to do in their everyday life: write some schemas, queries, SQL scripts, migrations, even PL/SQL functions. If performance issues arise I can look at logs and execution plans and maybe come up with some optimization ideas such as better indexing.

Next up: this is cool, but far from being properly trained in this area. Also, I could get some noSQL and in-memory DB (Redis) experience.

Backend architecture & patterns, APIs

60% – will probably have a good shot at solving most problems, but I still don’t know what I don’t know

I know what backends do and have seen some architectures from dead simple to ultra-scalable enterprise-grade stuff. There’s a lot of buzzwords, philosophies, languages, technologies and architectures out there.

Even more than for frontend, which may be chaotic and overhyped at times, but ultimately it’s mostly for presenting stuff – so it’s easy to see if something works fine or not. For backend though… It’s hard to cut through the noise of hype and corporate b*llshit language to see real value. (On the contrary, these technologies tend to change slower.)

Some systems I’ve worked with were doing their job quite fine, some were awful legacy code or over-engineered spaghetti based on custom frameworks solving problems that shouldn’t exist in the first place. But at least they created jobs. I digress.

Today, everything revolves around REST APIs and microservices – they often work great with web apps. I could architect less complex CRUD-like backend systems but still lack the experience to eg. optimize performance scaling or mitigation strategies in complex enterprise architectures myself.

I don’t believe in buzzword systems selling universal truths like XP, TDD, Scrum, Agile, SOLID or whatever. But I believe in producing readable (‘clean’), performant and maintainable code and good engineering processes.

Uncharted: I got into the game too late (or in the wrong place) to deal with XML & SOAP APIs. Did I miss something?

Next up: get into the right position to work with more complex architectures and learn as much as possible from more experienced software architects. Learn more about message queues, why not.

Backend languages

60% – adept NodeJS, intermediate Java

I know that experience with languages matter, but just as I don’t believe in buzzwords or frameworks, I don’t believe in languages. I know only a few backend languages and frameworks, but know what they are supposed to do so I can get up to speed relatively quick.

  • Java: getting experience with Spring, and some experience with the language itself.
  • Javascript: I have used Node.JS extensively, without any more complicated framework, just Express & Koa. The rest was custom code.
  • Others: I can script in Python and worked with Ruby to some extent. I also admired the beauty of functional languages like Racket and ML.

Next up: get more Java experience. Or learn Kotlin or C# or whatever. I unfortunately don’t care so much about languages unless they contain fun stuff like type pattern matching, immutability or expressive functional syntax. Most don’t.

Devops, version control, build pipelines, CI/CD, metrics

50% – not a devops engineer and will probably not write your Jenkins pipeline.

But I can write a Dockerfile, set up a Git repo with some nice workflow, configure Docker-compose or even set up a metrics collection system like Prometheus or Bosun with Grafana dashboards. I’m totally OK to interact with Linux-based devops systems, can modify HTTP server or proxy config etc.

Uncharted: AWS. I touched some S3 APIs but haven’t used AWS per se.

Next up: maybe get some more Kubernetes experience. Or maybe not?

Other domains

Computer science

50% – will optimize your algorithm, but don’t make me write your shiny new custom compiler 😜

Well, I started out as a different kind of engineer (mechatronics). So I actually have good formal education in certain aspects of maths, physics, control systems, mechanical, electrical & simulations engineering… all slowly becoming obsolete in my head. But we did learn some about ML, neural networks, image processing, analog & digital electronics and certainly quite a bit about robotics & embedded engineering.

Since I started software engineering, I have picked up some theory on programming languages, algorithms and computer security. It’s great to be able to assess algorithmic complexity and bottlenecks of business logic, and be able to see behind the curtains of programming languages.

Uncharted: ML/AI.

Next up: there’s still quite much to discover here. Look at some lambda calculus because it might enlighten me?


40% – aspiring but lacking hands-on experience

I of course know about stuff like OWASP top 10 vulnerabilities or JWT, oAuth and other authentication methods. I can setup some protections like CSP and HSTS. But cybersecurity is more than that: it’s about being able to design and implement usable and secure applications, not merely just about assessing vulnerabilities.

I’m not there yet to be a security engineer.

Next up: finish the Cybersecurity specialization on Coursera and get more training.

Wrap up

That’s a long list and it was great to contemplate on my engineering journey so far. It seems that I have progressed a lot. Companies call me a ‘senior engineer’, but I also don’t believe in titles 🙂 since they are… just titles.

For me, seniority as an arbitrary level of competence mostly means that I kind of know what I don’t know.

In fact, if I went to a job interview today, anyone can make me look like a total failure if they asked the right questions. Of course they would learn what I don’t know instead of learning anything about what I do know.

Problems rarely need to be solved in five minutes at an interview setting or at a whiteboard. Have I said that I also don’t believe in job interviews? 😉 But that’s another topic!

See you next time!

Share this post