What kind of position did you apply to? Front- and backend?
I won't "learn along the way" if I'm only making hobby side projects with less than 5 users.
Heavily depends on what you try to achieve and what you want to be. I'd personally value more fleshed out solutions over sheer amount. Quality over quantity. Anyone being able to plan and execute a more complex project (even without active users) can most likely adapt/learn new things easier than someone who keeps getting distracted by that new shiny thing and just doing the absolute minimum to get the product running.
Fullstack. It's unlikely someone trying to build one or two projects will learn everything they need to know about these topics unless they're actively researching stuff beyond the scope of their project.
What kind of scope are you thinking about for a project?
As a fullstack you should be really comfortable with databases and their design. What helped a lot for me was to draw the database layout on a whiteboard/paper/online. I still do it before touching any new database, just to see the bigger picture and potentially notice errors early.
When I quote "just make something", I mean people who literally mean it that way to encourage people to build some weeklong template project. Look, I've worked with NoSQL in both work and personal projects now, so I've completely forgotten denormalization was a thing when I was asked on the spot about read optimization.
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
I’d strongly argue that that depends on how proactively you are designing your project. Just because you don’t expect to have millions of users doesn’t mean you shouldn’t design a system that can handle that many users.
Brings to mind one of my friends looking at me like I was crazy when I told him that I was rewriting the Discord bot I had just finished implementing in Python in Elixir. The Python code worked for my use case, but because of the limitations of Python and the bot framework itself quite simply could not be made reasonably scalable, so I chose to rebuild in a language that I could make more scalable than the Python code was with almost zero effort, and can easily make exponentially more scalable by putting in a bit more work. Yes, the scalability from this rewrite is overkill for my usage, but it’s also good practice for writing scalable systems.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What kind of position did you apply to? Front- and backend?
Heavily depends on what you try to achieve and what you want to be. I'd personally value more fleshed out solutions over sheer amount. Quality over quantity. Anyone being able to plan and execute a more complex project (even without active users) can most likely adapt/learn new things easier than someone who keeps getting distracted by that new shiny thing and just doing the absolute minimum to get the product running.
Fullstack. It's unlikely someone trying to build one or two projects will learn everything they need to know about these topics unless they're actively researching stuff beyond the scope of their project.
What kind of scope are you thinking about for a project?
As a fullstack you should be really comfortable with databases and their design. What helped a lot for me was to draw the database layout on a whiteboard/paper/online. I still do it before touching any new database, just to see the bigger picture and potentially notice errors early.
When I quote "just make something", I mean people who literally mean it that way to encourage people to build some weeklong template project. Look, I've worked with NoSQL in both work and personal projects now, so I've completely forgotten denormalization was a thing when I was asked on the spot about read optimization.
I’d strongly argue that that depends on how proactively you are designing your project. Just because you don’t expect to have millions of users doesn’t mean you shouldn’t design a system that can handle that many users.
Brings to mind one of my friends looking at me like I was crazy when I told him that I was rewriting the Discord bot I had just finished implementing in Python in Elixir. The Python code worked for my use case, but because of the limitations of Python and the bot framework itself quite simply could not be made reasonably scalable, so I chose to rebuild in a language that I could make more scalable than the Python code was with almost zero effort, and can easily make exponentially more scalable by putting in a bit more work. Yes, the scalability from this rewrite is overkill for my usage, but it’s also good practice for writing scalable systems.