Forem: ΛGΣΣK

Latest Updates on React 18

ΛGΣΣK — Mon, 14 Mar 2022 02:20:48 +0000

This post is intended to summarize React 18 discussions on GitHub. At the time of writing React 18 has hit release candidate version. To try React 18 you need to update to the latest React 18 release with the additional step of switching from ReactDOM.render to ReactDOM.createRoot.

npm install react@rc react-dom@rc

import * as ReactDOMClient from 'react-dom/client'
import App from './App'

const container = document.getElementById('app')
const root = ReactDOMClient.createRoot(container)
root.render(<App />)

React 18 includes out-of-the-box improvements to existing features. It is also the first React release to add support for Concurrent Features, which let you improve the user experience in ways that React didn't allow before.

New Root API

In React, a root is a pointer to the top-level data structure that React uses to track a tree to render. When using legacy ReactDOM.render, the root was opaque to the user because we attached it to the DOM element, and accessed it through the DOM node, never exposing it to the user.

import * as ReactDOM from 'react-dom'
import App from 'App'

const container = document.getElementById('app')

// Initial render.
ReactDOM.render(<App tab="home" />, container)

// During an update, React would access
// the root of the DOM element.
ReactDOM.render(<App tab="profile" />, container)

React 18 introduces new Root API is called with ReactDOM.createRoot which adds all of the improvements of React 18 and allows you to use concurrent features.

import * as ReactDOMClient from 'react-dom/client'
import App from 'App'

const container = document.getElementById('app')

// Create a root.
const root = ReactDOMClient.createRoot(container)

// Initial render: Render an element to the root.
root.render(<App tab="home" />)

// During an update, there's no need to pass the container again.
root.render(<App tab="profile" />)

This change allows React to remove the hydrate method and replace with with an option on the root; and remove the render callback, which does not make sense in a world with partial hydration.

import * as ReactDOMClient from 'react-dom/client'

import App from 'App'

const container = document.getElementById('app')

// Create *and* render a root with hydration.
const root = ReactDOMClient.hydrateRoot(container, <App tab="home" />)
// Unlike with createRoot, you don't need a separate root.render() call here

Automatic Batching

Batching is when React groups multiple state updates into a single re-render for better performance because it avoids unnecessary re-renders.

However, React hasn't been consistent about when it batches updates. React only batched updates during React event handlers. Updates inside of promises, setTimeout, native event handlers, or any other event were not batched in React by default.

React 18 does more batching by default, all updates will be automatically batched, no matter where they originate from.

function handleClick() {
  setCount((c) => c + 1)
  setFlag((f) => !f)
  // React will only re-render once at the end (that's batching!)
}

But remember React only batches updates when it’s generally safe to do. For example, React ensures that for each user-initiated event like a click or a key press, the DOM is fully updated before the next event. This ensures, for example, that a form that disables on submit can’t be submitted twice.

Concurrent Features

React 18 will add new features such as startTransition, useDeferredValue, concurrent Suspense semantics, SuspenseList, and more. To power these features, React added concepts such as cooperative multitasking, priority-based rendering, scheduling, and interruptions.

These features unlock new performance and user experience gains by more intelligently deciding when to render (or stop rendering) subtrees in an app.

startTransition: lets you keep the UI responsive during an expensive state transition.
useDeferredValue: lets you defer updating the less important parts of the screen.
<SuspenseList>: lets you coordinate the order in which the loading indicators appear.
Streaming SSR with selective hydration: lets your app load and become interactive faster.

Support Suspense in SSR

Suspense component lets you wait for some code to load and declaratively specify a loading state (like a spinner) while we’re waiting, but not available on the server.

One problem with SSR today is that it does not allow components to wait for data. With the current API, by the time you render to HTML, you must already have all the data ready for your components on the server.

React 18 offers two major features for SSR by using Suspense component. The improvements themselves are automatic inside React and we expect them to work with the majority of existing React code. This also means that React.lazy just works with SSR now.

Streaming HTML: lets you start emitting HTML as early as you’d like, streaming HTML for additional content together with the <script> tags that put them in the right places.
Selective Hydration: lets you start hydrating your app as early as possible, before the rest of the HTML and the JavaScript code are fully downloaded. It also prioritizes hydrating the parts the user is interacting with, creating an illusion of instant hydration.

There are different levels of support depending on which API you use:

renderToString: Keeps working (with limited Suspense support).
renderToNodeStream: Deprecated (with full Suspense support, but without streaming).
renderToPipeableStream: New and recommended (with full Suspense support and streaming).

Behavioral Changes to Suspense

React added basic support for Suspense since version 16 but it has been limited — it doesn’t support delayed transitions, placeholder throttling, SuspenseList.

Suspense works slightly differently in React 18 than in previous versions. Technically, this is a breaking change, but it won’t impose a significant migration burden on authors migrating their apps.

<Suspense fallback={<Loading />}>
  <ComponentThatSuspends />
  <Sibling />
</Suspense>

The difference is how a suspended components affects the rendering behavior of its siblings:

Previously, the Sibling component is immediately mounted to the DOM and its effects/lifecycles are fired. Then React hides it.
In React 18, the Sibling component is not mounted to the DOM. Its effects/lifecycles are also NOT fired until ComponentThatSuspends resolves, too.

In previous versions of React, there was an implied guarantee that a component that starts rendering will always finish rendering.

In React 18, what React does instead is interrupt the siblings and prevent them from committing. React waits to commit everything inside the Suspense boundary — the suspended component and all its siblings — until the suspended data has resolved.

On Decision of Embracing Utility-First CSS

ΛGΣΣK — Sun, 27 Feb 2022 04:20:37 +0000

Utility-First CSS is trending in 2022. If you hate it, you will feel annoyed seeing people promoting it. If you love it, you'll question why people hate it. If you're still skeptical then there's a high chance you've already read all following articles:

You can't ignore it anymore when it's gaining so much attention and potentially becomes something big that you and your team don't want to miss. Same thing happens to Svelte. It's moving in an unpopular direction, it pushes you to make decision at this point — ignore it, embrace it, or question your current direction:

Is it worth the learning?
Is it considered harmful in long term?
Will it scale well in my team or company?
Does it have same abstraction as web frameworks (React, Vue, Angular)?

If you still couldn't pick a side, then I'm here to help you. This post focuses on the decision of embracing utility-first CSS in general and Tailwind in more specific.

What you really care about

All CSS technologies like CSS frameworks, CSS methodologies, or CSS-in-JS libraries try to fix problems of CSS at scale one way or another. Following are major deciding factors before picking a CSS solution:

Naming classnames: Short, scoped, and collision-free.
Output bundle sizes: The smaller the better, even better if modular
Optimization chances: Removing unused styles, caching extracted CSS files.
Developer experience: Fast development, easy refactoring, linting.
Learning investment: fast to learn, works well between tech stacks.

Different years of experience and project sizes have different expectations on above factors like beginners care more about learning investment and big projects care more about optimization chances.

Be aware of learning something backwards, modern developers often stumbled into trending CSS-like, JavaScript-like, HTML-like and find themselves never actually learn vanilla HTML, CSS, JavaScript which considered harmful picking up new web technologies.

The ideas behind utility-first CSS

The main idea behind utility-first CSS movement is to style everything based on predefined utility classes — developed by yourself or frameworks.

People love it because it promotes rapid prototyping by reusing tons of useful ready-to-use CSS classes at a very strict manner. People hate it because it produces ugly HTML markup with long string of classes.

Tailwind comes prepacked with a lot of options and styles for users to choose from, and it packs all these variations to reduce the tendency to write your own CSS.

Majority of time you don't do that much of customization as you expected, there is a chance that you'll never create any custom CSS in small projects, that's why Tailwind has been gaining so much momentum.

The decision on utility-first CSS

I have a background on mobile development where I always styled components programmatically. When I moved to web development, component-based CSS-in-JS seemed so obvious and future-proof. The transition was right and pleasant in the beginning.

I already experienced utmost dynamic component-based architecture when writing styles, layouts, and logics in one file using general-purpose programming languages. I resist all technologies go against my principles, I may try them, but not going to embrace any of them!

I don't like Angular because it uses HTML templates.
I don't like Vue because it uses template structures in .vue files.
I don't like Svelte because it uses template structures in .svelte files and ugly template APIs.
I don't like utility-first CSS because it promotes heavy uses of predefined classes instead of well-known CSS properties, and obviously ugly classnames in HTML.
I like React and styled-components when it translates very well to mobile apps and desktop apps, I prefer reusable fully-functional components than reusable CSS or HTML alone.

You see the point here, it's not about right or wrong decision. It's all about define principles in your developer career and technologies will fall into the right bucket for you and only you.

Data Structures Used in Competitive Programming

ΛGΣΣK — Wed, 23 Feb 2022 01:41:53 +0000

Understanding data structures is integral to participate in competitive programming, as you will be faced with making decisions on what data structure to utilize to most efficiently solve the problem you are given.

It's important to learn basic data structures inside out, otherwise understanding higher level structures will be difficult.

Beginner

Array: A collection of items of the same variable type that are stored sequentially in memory. It’s one of the most popular and simple data structures and often used to implement other data structures.
Linked List: A linear sequence of nodes that are linked together. Each node contains a value and a pointer to the next node in the list.
Stack: A linear data structure that follows the principle of Last In First Out (LIFO).
Queue: Similar to Stack in that they both are linear data structures with dynamic size. However, queues are FIFO (first-in, first-out) data structures.
Deque (Double Ended Queue): An extension of Queue, elements can be added to or removed from either the front (head) or back (tail).
Priority Queue: An extension of queue, each element is associated with a priority value, element with high priority is served before an element with low priority.
Set: An abstract data type that can store unique values, without any particular order.
Hash Table: A data structure that can map keys to values, uses a hash function to compute an index into an array of buckets from which the desired value can be found.

Intermediate

Heap: A specialized tree-based data structure that has largest root node in Max-Heap or smallest root node in Min-Heap.
Huffman Tree (Huffman Coding Tree): A full binary tree in which each leaf of the tree corresponds to a letter in the given alphabet. The goal is to construct a tree with the minimum external path weight.
Disjoint Set (Union Find): A data structure that stores a collection of disjoint sets, supports union and find operation on subsets.
Trie: A tree data structure used for locating specific keys from within a set. These keys are most often strings, with links between nodes defined not by the entire key, but by individual characters.
Binary Search Tree: A rooted binary tree data structure whose internal nodes each store a key greater than all the keys in the node’s left subtree and less than those in its right subtree.

Proficient

Segment Tree: A data structure that allows answering range queries over an array effectively, while still being flexible enough to allow modifying the array.
Fenwick Tree (Binary Indexed Tree): A data structure that can efficiently update elements and calculate prefix sums in a table of numbers.
Suffix Array: A sorted array of all suffixes of a string, used in full text indices, data compression algorithms, and the field of bibliometrics.
Sparse Table: A data structure that allows answering range queries, especialy range minimum queries in an array.
Range Tree: An ordered tree data structure to hold a list of points. It permits all points within a given range to be efficiently retrieved, and is typically implemented in two or higher dimensions.

Expert

AVL Tree: A self-balancing binary search tree in which each node maintains extra information called a balance factor whose value is either -1, 0 or +1.
Suffix Automaton: A powerful data structure that allows solving many string-related problems like searching for all occurrences of one string in another or counting the amount of different substrings of a given string.
Suffix Tree: A compressed trie containing all the suffixes of the given text as their keys and positions in the text as their values.
Treap (Cartesian Tree): A data structure which combines binary tree and binary heap (hence the name: Tree + Heap = Treap).
K-d Tree: A space-partitioning data structure for organizing points in a k-dimensional space.
Forest: An undirected graph in which any two vertices are connected by at most one path. Equivalently, a forest is an undirected acyclic graph, all of whose connected components are trees; in other words, the graph consists of a disjoint union of trees.
Splay Tree: An efficient implementation of a balanced binary search tree that takes advantage of locality in the keys used in incoming lookup requests.
Palindromic Tree: A tree based data structure that is specifically used to tackle problems involving palindromes of a string and its substrings.
Rope: A data structure composed of smaller strings that is used to efficiently store and manipulate a very long string.
Radix Tree: A data structure that represents a space-optimized trie (prefix tree) in which each node that is the only child is merged with its parent.
Red Black Tree: A self-balancing binary search tree. Each node stores an extra bit representing "color", used to ensure that the tree remains balanced during insertions and deletions.

My First Impressions of Dev Community

ΛGΣΣK — Tue, 22 Feb 2022 01:28:41 +0000

As a fresh user of dev.to for couple of days, I saw some posts about current status of dev.to or is it a victim of its own success? People complained about repetitive cheap curated content ranked at top all the time.

Actually dev.to works as intended, most user-generated content community has a perceived quality driven by hot trending topics.

Same things happens to Twitter and Reddit but they are too big and you just don't see it, they have enough content to build personalized feed. Eventually you'll get sick of people keep tweeting about HTML, CSS, JS but you have the option to follow other topics/people.

Same thing doesn't apply to dev.to because this is a niche community with less than 1M users. If you have worked in software development long enough you'll realize that there're not much new or deep things to write about when mostly already covered in official documents.

High quality articles are expensive to produce, rock-star developers write a handful of them in 10 years, professional bloggers or book writers might cross-post a piece of their work here.

Forget about beginner/intermediate developers writing high quality posts because they don't have enough insights and experiences to elaborate difficult concepts to recognized as quality content. The only good thing they can do are curating content and copy+modify what they know. If they don't do that then dev.to just dead already!

Css-tricks.com has around 10k reasonable good long-form articles and has traffic similar to dev.to. How can dev.to make a break though from here.

The big problem with dev.to is they want to build a highly-interactive with long-form content community. Why is that?

Long form content are limited and hard to mass produce, even with a big userbase.
Highly interactive site is also impossible when number of posts and users are limited.
Showing sorted content is harmful, it creates illusion of the whole site quality, visitors feel like that the only good thing they can find at dev.to. Personalized feed doesn't work because of limited content.

To fix above problem dev.to needs to separate discussions with articles, make it looks like a discussion centric community like Github discussions but also maintain a section of curated topic-wise quality articles as a learning source. Dev.to also should hire more technical writers to write less popular topics.

In the end it's all about perceived impression. What if dev.to wants to keep everything the same? I think it's fine if dev.to team happy with current status and want to pivot new products before dev.to declines. This site already reached its peek.

Each site serves it own unique purpose. Combine geeksforgeeks.org content with dev.to comment section will be dope!

Writing Conventional Git Commit Messages

ΛGΣΣK — Tue, 22 Feb 2022 01:07:29 +0000

When working on personal projects, you can commit with random messy short meaningless messages like wip, done, ok, working, still working on it, really done this time, or i dont care. You're not the only one who has poorly named commits, weird branch merges, or one branch for everything. No one cares about git history of your private repositories!

But public and corporate projects often have very precise rules over how git commit messages should be formatted. This leads to more readable messages that are easy to follow when looking through the project history. Also, we can use the git commit messages to generate the changelog, determine a semantic version bump, or trigger publishing process.

The Conventional Commits

This specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

<type>(<optional scope>): <subject>
<BLANK LINE>
<optional body>
<BLANK LINE>
<optional footer>

A full long commit message will look like this:

fix(middleware): ensure Range headers adhere more closely to RFC 2616

Add one new dependency, use `range-parser` (Express dependency) to compute
range. It is more well-tested in the wild.

Fixes #2310

Most tools only show the first line of the commit message, which is usually enough to know what it is about.

* 8decde6 - (1 months ago) docs(server): update file uploading api
* bee23f9 - (2 months ago) feat(client): add Apple login button
* a8ecd9d - (3 months ago) fix(client): brokenn header in safari
* 7a0f17e - (4 months ago) feat(server): add crud apis
* af61aec - (5 months ago) docs(changelog): update changelog

Type

This spec suggests following types, you can always add more if that suits your projects.

feat: A new feature
fix: A bug fix
docs: Documentation only changes
build: Changes that affect the build system or external dependencies
ci: Changes to our CI configuration files and scripts
perf: A code change that improves performance
refactor: A code change that neither fixes a bug nor adds a feature
style: Changes that do not affect the meaning of the code
test: Adding missing tests or correcting existing tests

Scope

The scope should be the name of the package/module affected (as perceived by the person reading the changelog generated from commit messages. It can be empty (e.g. if the change is a global or difficult to assign to a single component), in which case the parentheses are omitted.

Common scopes are client, server, mobile, core, worker, shared, etc.

Subject

The first line of the commit message should be a short description (50 characters is the soft limit), and should skip the full stop. Its first word is not capitalized unless there is a reason to capitalize it other than because it is the first word in the sentence.

Describe your changes in imperative mood, as if you are giving orders to the codebase to change its behavior (“change” not “changed” or “changes”). Try to make sure your explanation can be understood without external resources. Instead of giving a URL to a mailing list archive, summarize the relevant points of the discussion.

Rather than writing messages that say what you’ve done; consider these messages as the instructions for what applying the commit will do. It feels strange at first but it does make sense and eventually becomes natural.

If the subject starts to get too long, that's a sign that you probably need to split up your commit to finer grained pieces.

Body

The body should provide a meaningful commit message, which:

Explains the problem the change tries to solve, i.e. what is wrong with the current code without the change.
Justifies the way the change solves the problem, i.e. why the result with the change is better.
Alternate solutions considered but discarded, if any.

Footer

All breaking changes have to be mentioned in footer with the description of the change, justification and migration notes.

BREAKING CHANGE:

`port-runner` command line option has changed to `runner-port`, so that it is
consistent with the configuration file syntax.

To migrate your project, change all the commands, where you use `--port-runner`
to `--runner-port`.

Best Practices

If in doubt which identifier to use, run git log --no-merges on the
files you are modifying to see the current conventions.

Don't spoil the git history with multiple same message commits, better use git commit --amend --no-edit --date=now to append same work in progress.

This first line should be a concise summary of the changes introduced by the commit; if there are any technical details that cannot be expressed in these strict size constraints, put them in the body instead.

Remember the Conventional Commits spec is more like a guideline not a mandated rule or something. You are free to modify or adopt it in a way that makes you and your team happy.

State of JS 2021 Survey Results

ΛGΣΣK — Sun, 20 Feb 2022 01:05:31 +0000

State of JS 2021 survey results just came out, looking beautiful as always, now it's a good time to try new shining JavaScripts tools.

A lot happened in 2021. So much in fact that the survey was pushed back all the way to 2022!

I like the idea of library tier list like hero tier list in many games I played. It will help us make faster decision on which ones to invest but also push lower-tier ones to death faster.

This report is a good place to have a big picture of JavaScript ecosystem. What do you think about the results?

Cracking the Frontend Interview, Part 1: Overview

ΛGΣΣK — Fri, 18 Feb 2022 03:23:50 +0000

After having a job at your dream company, you often realise that tackling the interview is more difficult than working at real projects. Let's take an overview look at what to focus when preparing for the frontend (front-end / front end) developer interview.

This series is quite language agnostic except the framework when I only cover React. One reason is I'm working on React and quite good at it. Other reason is that we can both achieve client-side and server-side rendering with JavaScript and React.

It's personal preference to pick other JS frameworks like Vue or Angular, server-side languages like PHP, Ruby, Python, Java, C#, etc. Just pick one and being good at it, there's alway open jobs out there for you.

By failing to prepare, you are preparing to fail. (Benjamin Franklin)

The Expectation

Different job levels require different responsibilities and minimum qualifications. Different companies establish different expectations to filter candidates who fit well with their cultures. Whatever situation is, here are 5 factors that will have big influence on your way looking for a job:

Technical proficiency: I strongly believe that skills beat experiences. If you're good at what you're doing then you'll have all the confidence in this world. You'll create your own luck. You can even build your own products if no one hires you.
Years of experiences: Many companies filter candidates by number years of experiences! It might not be perfect, but it's a simple mechanism when hiring senior or manager level! A matter of fact that many of us are mediocre engineers. It sounds debatable but it's true. You'll see many engineers who actually stack years of experiences without advancing at all in big companies.
Personal projects: Anything like hobby projects, side projects or open-source projects will count. These make you stand out from the rest. Invest on these as soon as possible, especially fresh graduates who don't have commercial experience yet.
Former employers: Who doesn't like a candidate previously worked at Google or Facebook (unless they don't have enough money to pay you 🤑)! Having a list of former prestigious employers (relative to your market) will give you a huge advantage position in the interview process.
Interviewing skills: Competition at prestigious companies is fierce with thousands applications from top engineers around the world. You need extra gear like interview skills to be the chosen one.

Technical Proficiency

You may have heard stories people somehow got a decent job by luck with tips and tricks, focusing solely on problem solving skills. But at the end of the day, you'll be working with these technologies day in and day out, being a decent engineer is always your north star.

Basics: It's critical to have solid understanding of computer science including problem solving, design patterns, system design, networking, database, etc.

Whether you love or hate data structures & algorithms, you have to take considerable amount of time to practice. Majority companies are using it and it's not going to change anytime soon.

There are many self-taught frontend developers these days who don't have time to learn computer science fundamentals properly. It's okay as long as you can do the job and make enough money for your life. But it doesn't mean it's safe to skip this, I mean it's not cool to call yourself a software engineer when you don't know much about computer science.

HTML: Quite easy to pick up, not any fancy things here. Expected to know at least available HTML elements, how DOM works, semantic HTML, web storage, etc.
CSS: Learn proper raw CSS, how CSS engine works, and Responsive Web Design. You may only use CSS frameworks all the time but a frontend engineer doesn't know to layout using raw CSS seems unqualified.
JavaScript: A decent knowledge of JavaScript is required. Fluent data structures & algorithms coding in JavaScript is perfect. You can do almost anything with this language nowadays so don't hesitate to put a lot of effort on it.
React: (or any other web framework) Just pick one and never look back, knowing only one is going to be just fine. Pick the exact one your dream company is using would be a huge advantage.
WebDev: Having a basic knowledge of Standard JavaScript APIs, XMLHttpRequest and other browser special-purpose APIs like runtime, storage, notifications, window, socket, file system, etc.

There are many more web technologies to learn that I can't cover here. Check frontend roadmap for the exhaustive list. The more you know, the more advantages you have compare to other candidates.

Try not to get lost in the maze of frontend technologies.

Cultural Fit

Your dream company is a living entity which has standards and principles, trying so hard everyday to deliver their core values. You both should have a good match, or you could end up working miserably months later.

Know yourself: This is so important but underrated. You should define your own principles. What you really want. Who you really are. What you've done. What you can offer.
Know your dream company: This is when you respect the open internet. Things are much more open these days with the rise of community like forums, groups, twitter, etc.
Practice telling stories to meet the cultural fit: When you find a good match between a company and yourself, adjust your life stories and work experiences to emphasize that you are a good fit to that company. It's not lying but telling your stories in different ways.

Job Application

It doesn't take much time to write a good resume by following tons of tips around the net.

Research the market: Look around, track all open positions you want to apply into an excel file. Give them a priority order.
Revise your resume: No one forbids you from submitting the same resume to all open positions ! Many do that 👹. But revising resume a bit to fit the position (frontend engineer, fullstack engineer, software engineer, etc) is recommended.
Submit job application: There are many strategies here (one at a time, multiple at a time, dream companies first, dream companies last, etc) and via referrals, recruiters or job boards. Do whatever you want. I found submitting via referral is the best to guarantee you an interview slot.

Interview Process

An interview process at a company starts when you receive an email or phone call from recruiter to setup the interviews. Recruiters often follow your decisions on date and time of interviews, so buy some time if you need to. Following are 5 common steps you'll encounter for technical positions:

Phone interview w/ hiring manager: Undoubtedly the easiest one. One reason is hiring manager is often professional and conventional so you can predict what will be asked and prepare for it. Other reason is most questions are behavioral questions, we all assume behavioral questions are easier than technical questions, right? 😋. Hard to fail if you know the company well and align your answers to fit the expectation.
Phone interview w/ team member (1-3): Normally you'll have from 1 to 3 phone/video technical interviews with your potential teammates. Some companies focus on data structures & algorithms. Others focus on frontend technologies only. Better ask recruiters before these rounds to have better preparation.
Take home assignment (sometimes): Some companies may ask you to deliver an assignment in couple of days. I had experiences at this step as interviewer who reviewed candidates' assignments, I can tell you I was always very harsh because I had plenty of time to look at the code 😂. So please try your best to code beautifully and test appropriately. A little investment in UI/UX design would be awesome. Some people may think about cheating at this step. Don't! You may end up very embarrassing later at onsite interview.
Onsite interview: Regardless of how many interviews I took, I found myself very nervous and tired at this step. You simply can't cover your lack of knowledge after many 1-on-1(2) interviews all day long. You're better good at what you're applying for or this could give you a damage on your confidence later.
Offer Negotiation: It's awesome to finally get here, you're almost there, don't screw it up 😅. Try to balance between what you know about the market, working environment, project status, career development and compensation package.

Interviews at different companies may differ in terms of order and number of interviews, you better prepare all these 5 types when applying multiple at the same time.

Best Practices

Be a professional candidate. Sound cliche but never hurts if you are. Fresh graduates might not know how to do this. Experienced engineers sometimes are arrogant and act like a 🤬.
Unprofessional interviewer exists. Not many companies have seminars to train their employees how to conduct a professional interview. Software engineers often asked to do the technical interviews without a solid understanding what the company actually looking for. You may encounter some interviewers who are very technical bias, looking for someone similar to theme, asking personal questions, humiliating candidates, etc.
Good enough is good enough. I can guarantee that you can never cover all technologies need for your upcoming technical interviews. The more you learn, the more you know you don't know! Better to set a deadline and go for it.
Be patient with hiring process. One-shot interviews are rare these days unless you're exceptional and invited to work by companies. Most of us will go through very long and grueling interview which might come in vain if we fail any step of it. This is especially true applying to small non-prestigious companies when we're constantly questioning ourself whether the efforts will pay off or the offers end up very disappointing.

It’s also important to note that if it doesn’t work out the first time, it’s not the end of the line.

Don't stress out, prepare seriously and you'll be doing just fine. Wish you all reading this post to have very successful interviews in the future.