Become a Fullstack JavaScript Developer, Part 2: The Basics

July 19, 2019 • ☕️ 6 min read

cover

Whether you are going to focus on frontend or backend, these are my curated list of knowledge or technologies you must master.


Become a Fullstack JavaScript Developer is an original series where I explain my process and what I’ve learnt to become a Fullstack Javascript Developer - from motivation to actual building my own product single-handedly.


Data Structures & Algorithms

This topic is somewhat polarizing in the development world because there are developers who don’t think there should be such a heavy focus on computer science topics like tree traversal, sorting, algorithm analysis, matrix manipulation, etc. in web development. However, there are companies like Google that are notorious for asking these types of questions in their interviews.

It’s a must to have decent knowledge and comfortable coding skills on basic data structures (Linked List, Doubly Linked List, Queue, Stack, Hash Table, Heap, Priority Queue), basic algorithms (Sort, Search, Traversal, Hash) and common algorithm paradigms (Brute Force, Greedy, Divide and Conquer, Dynamic Programming, Recursion).

Big O notation is used to classify algorithms according to how their running time or space requirements grow as the input size grows. It’s useful to know how fast an algorithm is and how much space it needs. This allows you to pick the right algorithm for the job.

Advanced data structures (Trie, Tree, Graph, Disjoint Set, Bloom Filter) and algorithms are optional. It depends on your current situations like whether you having a secure job and open to vulnerability, you are actively looking for a job, you are targeting top companies. We all know that most of top companies require decent knowledge on this topic (even daily task doesnt need it). So it’s very useful to practice on LeetCode and GeeksForGeeks couple of months before doing any technical interviews.

Design Patterns

Being good at problem-solving is one thing but to take your career to the next level, one must know how complex software projects are architected. Software design patterns provide templates and tricks used to design and solve recurring software problems and tasks. Applying time-tested patterns result in extensible, maintainable and flexible high-quality code, exhibiting superior craftsmanship of a software engineer.

After years of working as software engineer, you’ll find yourself implementing something over and over again. And you’re not alone, other developers see it too and the community or experts created some common patterns. Choosing design patterns depends on many factors like project status, team level, time constraints and personal favorite.

It’s recommended to know following common creational patterns (Singleton, Builder, Prototype, Factory Method, Abstract Factory), structural patterns (Adapter, Composite, Proxy) and behavioral patterns (Observer, State, Template, Visitor)

You should read this bible Design Patterns: Elements of Reusable Object-Oriented Software written by Gang of Four

System Design

System design questions have become a standard part of the software engineering interview process. Performance in these interviews reflects upon your ability to work with complex systems and translates into the position and salary the interviewing company offers you.

Most engineers struggle with the system design interview (SDI), partly because of their lack of experience in developing large-scale systems and partly because of the unstructured nature of SDIs. Even engineers who’ve some experience building such systems aren’t comfortable with these interviews, mainly due to the open-ended nature of design problems that don’t have a standard answer.

Common system design questions are: a URL shortening service, global video streaming service, global chat service, social network, message board service, global file storage & sharing service, ride sharing service, search engine, API rate limiter.

A good knowledge on Microservices is recommended when it’s becoming a trend nowadays and providing so many benefits: highly maintainable and testable, loosely coupled, independently deployable, organized around business capabilities and owned by a small team.

RESTful API

A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. Also referred to as a RESTful web service, is based on representational state transfer (REST) technology, an architectural style and approach to communications often used in web services development. It’s a must know how it works, design and architecture constraints.

Stateless is the key point of RESTful, each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.

Developers’ experience is the most important metric to measure the quality of the APIs. There are no official guidelines on how to design beautifully crafted APIs. Take great care on following topics when design your own APIs: keep it simple, use nouns and NOT the verbs, use of right HTTP methods, use proper HTTP codes, versioning, pagination, good error messages …

As a full stack developer, you’ll be working with RESTful APIs constantly whether as consumer or creator. It’s extremely recommended to be excellent at this one!

More

Git: It’s hard to find a developer who doesn’t use git these days! You’re not that kind of developer, right? The most important thing is establish a good git workflow in your team.

Bash: Most of developers I know can use terminal basically but never learn bash properly. IMO it’s very productive to learn bash seriously. It’s an extremely powerful but underrated language which can enlighten the life of a full stack developer.

SSH: I guarantee many of you ssh every single day but don’t fully understand how it works. It’s a shame! Learn more at ssh.com

Character Encodings: If you use anything other than the most basic English text, people may not be able to read the content you create unless you say what character encoding you used. Developers need to ensure that the various parts of the system can communicate with each other, understand which character encodings are being used, and support all the necessary encodings and characters. Ideally, you would use UTF-8 throughout, and be spared this trouble.

Semantic Versioning: is a versioning system that has been on the rise over the last few years which has the form Major.Minor.Patch. This knowledge is a must when you’re creating third party libraries or consuming dependencies. It would be a disaster if you’re using it wrong!

Take Away

Transferable and evergreen knowledge: is so important and often skipped. Languages and frameworks come and go, but these basic knowledge will last even when you’re changing the development stack.

Required by almost any technical interviews: top companies focus a lot on data structures and algorithms, sometimes system design. If you are special and have famous products or open source projects, it’s fine not to be good at these because you might get a wildcard job. But if you’re going the normal path through interviews, it’s highly likely that you’ll go through all of this at a very competitive level!

It’s safe to skip if you’re working on your own products: Yes what important is getting things done asap with the right technologies and minimum effort. Fill the gap when you go and focus on what matters most.

Never forget you are a software engineer: Titles don’t matter, your daily tasks change over time, you find yourself switching between companies and frameworks. At the end of the day, trying to become a good software engineer is what matters.

References