Forem: Bartłomiej Pasik

Stop Writing Better CVs. Start Writing Queries.

Bartłomiej Pasik — Wed, 08 Apr 2026 12:31:00 +0000

A few days ago, I was browsing developer roles and noticed something odd: the same people kept showing up across completely different searches.

A backend-heavy Node.js profile showed up in one role. The same person appeared again in a TypeScript/PostgreSQL search. Then again in an AWS/event-driven one.

It wasn't always because they were obviously the best candidate. A lot of the time, they were just easier to retrieve.

That sounds harsh, but it matches how hiring works now.

Before a recruiter ever talks to you, your profile has already been filtered, ranked, matched, or ignored by some kind of system - ATS filters, recruiter search, internal databases, Boolean queries, recommendation engines.

And most developers are still optimizing for the wrong thing.

They ask:

"How do I describe myself better?"

But the better question is:

"What searches do I need to appear in?"

Your Profile Is Data, Not Just Writing

When we build software, we don't throw data into a system and hope for the best. We think about schema, indexing, query patterns, ranking, and signal quality.

Then we switch into job-search mode and suddenly become irrational. We start polishing wording, swapping adjectives, and trying to "sound senior."

That's the career equivalent of dumping JSON into a database with no indexes and praying search still works.

Your CV is not just a story.
Your LinkedIn is not just a bio.
Your GitHub is not just a portfolio.

They are search surfaces.

Hiring Is Search-First, Then Human

A lot of strong developers are invisible for a very boring reason: their experience exists, but the query match does not.

A recruiter searches for something like:

senior node.js backend aws
typescript postgres distributed systems
lambda kafka event-driven architecture
solana data indexing engineer

Now ask the uncomfortable question: do those exact concepts exist in your profile?

Not "kind of." Not "implied." Not "someone smart could infer it."

Do they literally exist?

If not, you're depending on a human to guess what the system failed to find. That is a bad strategy.

Why Good Experience Still Gets Ignored

This is where a lot of developers get stuck. They have real experience, solid projects, good judgment, strong fundamentals - but they describe that work in vague, compressed language.

Weak signal	Searchable signal
Worked with cloud infrastructure and backend services.	Built event-driven backend services with Node.js, AWS Lambda, SQS, and PostgreSQL.
Improved database performance.	Optimized PostgreSQL queries and indexing, reducing API p95 latency by 42%.
Led architecture decisions.	Designed a multi-tenant Node.js service with Kafka-based async workflows and PostgreSQL read replicas.

The point is not to stuff keywords. The point is to encode evidence in a way search systems can actually use.

Systems Don't Reward Style. They Reward Signal.

Most hiring systems are trying to infer a few things:

What tools you've used
How recently you used them
Whether you've worked at the expected level
Whether your experience is consistent across sources
Whether your profile looks comparable to successful candidates

That means vague language is expensive.

"Worked with AWS" → weak.

"Built a Lambda + S3 + Step Functions pipeline processing 10M+ events/month" → strong.

One tells a story. The other creates retrieval, depth, and seniority signals.

The Mindset Shift That Changes Everything

Stop asking:

"How do I present myself better?"

Start asking:

"What queries should retrieve me?"

That one shift changes how you write everything - your CV bullets, your LinkedIn headline, your About section, your project descriptions, your GitHub README text, even the names of your pinned repos.

You are not just presenting yourself. You are designing structured evidence.

A 30-Minute Exercise That Exposes the Problem Fast

Here's the simplest version of this.

Step 1: Pick 5 real roles

Not aspirational ones. Not "maybe in two years" roles. Pick five jobs you would realistically apply to this month.

Step 2: Extract the raw search terms

Copy the exact phrases from those job descriptions. Not your summary of them - the company's actual language.

Not this:

cloud experience

But this:

AWS Lambda, DynamoDB, Kafka, event-driven architecture, PostgreSQL, microservices, observability, system design

Step 3: Build a query coverage checklist

Turn those phrases into a checklist and compare them against your CV, LinkedIn, GitHub, and personal site:

[ ] Node.js
[ ] TypeScript
[ ] PostgreSQL
[ ] AWS Lambda
[ ] Kafka
[ ] event-driven architecture
[ ] distributed systems
[ ] system design
[ ] observability

Every unchecked box is a discovery problem.

Step 4: Patch the missing surface area

Update your profile using real evidence from work you've actually done. Not keyword stuffing. Not a giant "skills cloud." Just better encoding.

Add the missing concepts where they naturally belong: headline, summary, role bullets, project descriptions, repository READMEs.

The goal is truthful query coverage.

What Developers Usually Get Wrong

1. They optimize for sounding smart

Words like "passionate," "strategic," "visionary," or "results-driven" rarely help without technical proof.

2. They optimize for sounding unique

Clever phrasing is bad for retrieval. Clear beats clever.

3. They compress specifics into abstractions

"Cloud-native distributed platform" sounds impressive. Node.js, AWS Lambda, SQS, PostgreSQL is far more searchable.

Your GitHub Creates Searchable Surface Area Too

Even when recruiters don't read your code, they still scan your repos, README intros, pinned projects, and naming choices. That matters more than people think.

If your LinkedIn says you built a real-time event processing service, but your repo is called new-final-project-v2, you're wasting signal.

Name things like you want them to be found.

One Practical Place to Start

If you need raw material for this exercise, open a few real listings from career.now's Board Directory and pull the exact terms companies are using today. Then compare those terms against your own profile.

You'll usually find the gap in minutes - and that gap is often more useful than another round of CV polishing.

The Uncomfortable Truth

You are not only competing with other developers. You are competing with profiles that are easier to index, easier to match, and easier to rank.

That doesn't mean skill doesn't matter. It means skill that can't be retrieved often doesn't get seen.

Final Thought

The market is no longer human-first. It's search-first, then human.

So stop treating your career documents like essays. Treat them like systems.

Define the schema. Improve the signal. Optimize for retrieval. Make the right queries return you.

Because the developer who gets found gets considered. And the developer who gets considered gets a chance to prove they're actually the best fit.

How NOT to launch your new product

Bartłomiej Pasik — Tue, 26 Nov 2019 13:13:30 +0000

As an indie maker at some point you face the last phase of your product development - the launch. Here's how not to launch your product… learned the hard way 😐

I Need Brains it was my first product... which I've screwed so much 🤦‍♂️

I wanted to create something. Literally SOMETHING. It didn't need to earn money. It could just bring some followers on my Twitter. That's all.

When the idea came, I just grabbed the laptop and I started coding backend in Node.js and after that frontend in React.

The app solved my problem. I don't know who should I follow on Twitter to get the meat. I don't want to read about politics. Only engineering and indie stuff.

Do not launch when your competitor launched his/her product a couple of days ago 🤦‍♂️

Couple of days before my launch Follow Friday appeared on PH. Almost the same idea. Better design. Quicker launch. He gained hundreds of upvotes and I got 4 😐

Do not forget about marketing stuff 💩

I was so angry that I wanted to launch quickly and I did. I'd just made two screenshots, written some short description and that's all. Did the same thing for Hackernews and for Wykop (Polish Reddit).

Do not overegineer your product 🤖

I wanted to do simple app that will list Twitter profiles. I'm full stack developer, so I thought that I should use my technologies to do it quickly. Nope. That's not how you do the MVP as an indie maker. Use the No Code tools. Seriously. For example, do you need an API that will serve some data? Use Google Sheets with Sheety or Sheet2Site to make even a full app. Do you want to do simple one page app? Use Carrd.

Here are other things you can check before launch.

Cheers. Hope your launch will be successful 🚀

Why and where you should use Node.js

Bartłomiej Pasik — Tue, 26 Nov 2019 11:46:52 +0000

In 2009, Ryan Dahl introduced his side project which had revolutionized the JavaScript world. Since then Node.js is helping businesses in the rapid development of scalable solutions that suit high traffic needs. Furthermore, Node.js has a great developer experience thanks to the Node Package Manager which is the largest open-source library registry in the world.

Why should you consider using Node.js in your next project?

Easy to learn

Node.js is really easy to start. Those who know JavaScript, know how to write Node.js applications. There are some differences, however, mostly everything is the same. The hardest thing about Node for beginners is the asynchronous non-blocking programming paradigm. Even though it’s still JS, once you get the idea, you’ll fall in love with it.

Node’s main advantage is that one JavaScript developer can work on the whole web application instead of two developers working on the frontend and backend side. Furthermore, frontend and backend applications can share the JS code. Code reusability makes application development costs less.

Active open-source community

I think the next cool feature right after the non-blocking I/O operations (communication between the system and the outside world) are open-source packages from the NPM (Node packages registry). By the numbers, there are more than 1 million active packages at this moment in the repository. Last week downloads reached 14 billion and last month over 61 billion! The numbers are tremendous.

I/O highway

The core thing about Node is the Input/Output operations and how they are handled. I/O operations are for example a database call, getting file, calling an external service, etc. In Node, we have the event loop which stores all incoming requests which are blocking operations in the loop with their callback functions. Callback functions are called right after finishing the blocking operation. With this solution, Node is not blocking the main thread and can handle new requests. Such feature allows us to handle more requests compared to threads solution from other languages.

Scalability

Node allows you to scale concurrent requests to more than other languages can do out of the box. Some guys achieved scalability levels of over 1 million concurrent requests and over 600,000 WebSocket connections. Of course, it’s a matter of the work you do behind each request and how many resources you have, though Node is still good at scaling things up.

Compared to Java, below some point defined by the number of Java threads, Java is better in handling concurrent requests, because threads are faster. Though Node, after that point is going higher in the number of concurrent requests and Java stays with the same maximum. Of course, if you write bad code, you’ll have 10 requests per second instead of 1000. In general, it’s easier to write scalable solutions in Node.

Its limits here are mostly about CPU usage due to the fact that the whole application is running on a single thread. You can’t fully use the CPU power. To scale things, you need to create a Node Cluster, use things such as PM2 node process manager or scale with Docker if you run Node inside a Docker container.

Developer productivity and satisfaction

The freshness of the technology gives developers the power to make great software. It’s ten years old now. In contrast, Java or PHP appeared more than 20 years ago, so it’s still pretty young. That and less boilerplate code, easy asynchronous programming, and elastic JSON manipulation makes Node.js developers happy while staying productive.

Where can you apply Node.js?

Node will more or less fit everywhere. When you want to do a quick minimum viable product to test your idea or you want to go enterprise, use Node. There are some caveats, however, the overall image of the Node ecosystem is good.

API

I wonder why every blog post about Node.js usage doesn’t say anything about simple API. Authors say that you can use it for sophisticated cases, but developers can use Node just to create your CRUD application. With ORM support for SQL or NoSQL databases, you can quickly expose your resources as an API. Perfectly fits MVP use case. No rocket science with project setup. Just write the API and launch your product.

Real-time applications

In Node, it’s super easy to integrate with WebSockets such as Socket.io. WebSockets, give you the ability to create a duplex connection between the client and the server. With this, the server can send real-time updates to the user when something changes.

Example usage of WebSockets:

Social feeds — update instantaneously user feeds with new posts without the need of refreshing the user’s browser
Games — fire an action event and broadcast it to other players
Document collaboration – document editing simultaneously by multiple users like Google Docs
Clickstream data — analyze user movements and behavior on your site
Real-time analytics and financial tickers — update instantaneously your charts in the client browser
Instant messaging — live chat experience inside the client browser

Serverless

If you want to scale your application automatically that will detect traffic spikes and scale up or down to match incoming traffic, serverless is a good option. It gives you the ability to pay only for the resources used during the execution, so you don’t need to pay monthly for monstrous instances that can handle that traffic.

For instance, Amazon Web Services has a thing called Lambda which is a function-as-a-service product, so you write a JavaScript function that handles the requests, saves the code in the AWS, binds it to some endpoint with API Gateway and that’s all. AWS will do the rest for you and you can sleep well when a rush of users visit the site on Black Friday, for example.

There is one thing which I don’t like about serverless architecture. It’s the vendor lock-in problem, however, in Node.js we have a framework called serverless. It allows you to write serverless applications that you can deploy to any cloud provider with a consistent experience and that’s a pretty cool thing. It integrates easily with AWS, Azure, Cloudflare Workers, Fn, Google, Kubeless, OpenWhisk, Spotinst, so you can choose which provider fits your needs best.

High throughput APIs

The best examples of high throughput API are chat applications. You want to be reliable and fast when millions of users are typing messages to each other. Of course, chats are not the only example. You can use it everywhere where you need to work at a huge scale. Proper horizontal scaling such as app architecture on top of the AWS with Node.js I/O gives you the ability to achieve this goal. Nevertheless, it’s not a magic technology that will do it out of the box.

Streaming services

Imagine you have a video file on your server which weighs 20GB and your server has only 8GB RAM. You want to give a link to a friend to download it, so you just set up your server and endpoint and you give the link to your friend. Your friend clicks the link and after that, your server is going down due to out of memory error, because the server tries to load the whole file into the memory.

In Node you can produce an out of memory error, however, Node Streams come to rescue us. With Streams, by creating file stream in our endpoint, we are just increasing memory usage by 25MB (default chunk size), because Node is not buffering the whole file. It’s just sending chunks, one by one to the end-user. Moreover, you can transform the stream on the fly. So for example, if you’d have a text file that would weigh 2GB, you could just make an uppercase of all letters in each line on the fly without loading the file into the memory. With those possibilities, you can create your own Netflix clone or any other streaming platform.

Enterprise applications

Java is super enterprise. Many treat Node as an MVP tool. However, in my opinion, that’s the matter of used tools. Many use the Express.js framework, which is elastic, good for rapid development. Although it’s used by many incompetently and that leads to non-enterprise software.

Nevertheless, there is a solution. Nest.js is our Enterprise Hero. If you are familiar with Java Spring Framework, you’ll love it. Moreover, Nest.js uses TypeScript which gives it more Enterprise power. TypeScript is a superset of Javascript which has static type-checking which allows you to “write Java with JSON”, so with TS you are more error-proof. Nest with its design forces you to write clean, enterprise code which makes your application more scalable in the matter of architecture and less error-prone, because type errors are caught even before running your app.

SQL and NoSQL

Many say that SQL support is worse in Node. Two years ago I would say that Node.js should only be used with NoSQL databases because working with NoSQL is a pleasure and with SQL is not. However, nowadays SQL tools are much better. For example, there is the Sequelize which is pretty good when you need to create CRUD operations and there is also Knex which can be used when you need to perform some advanced queries. I like query builders, however, Java query builder called jOOQ is at the top of my list, sorry Node!

Node.js SQL tools are not more complicated, I mean here the syntax, than NoSQL tools. They are at the same level, in my opinion. So, yes, you can use Node.js with the SQL database, no worries.

But…

As history shows, NPM had some failures. One of them was about the 11 line Node package which was adding characters to the string — named “left-pad.” On March 22nd, 2016 this package was deleted from the repository and it resulted in world chaos in the Node.js environment. Many projects couldn’t be built on that day. Fortunately, NPM fixed the problem by making it harder to unpublish a version of a package.

Another thing about NPM vulnerabilities, on the 6th of January, David Gilbertson published an article “I’m harvesting credit card numbers and passwords from your site. Here’s how.” It shows how any hacker could inject malicious code in the package code and the package could be installed not as your first party, but even as a third-party package. To be more precise, it’s not only a Node.js problem, but it appears also in almost any frontend technology which uses NPM. What we can do about this?

Keep checking npm audit security report.
Choose the packages you use carefully. Use more popular ones.
Have fewer dependencies.

Practical implementation

Recently, we’ve experienced the practical implementation of the article, with some extra social engineering attacks. One owner of a popular NPM package didn’t want to maintain the package anymore, so he gave maintain access to the guy who had previously asked him if he can do it for him. Unfortunately, the guy was a hacker and has added two lines of code which were importing the hacker’s package which was hijacking user data. The package was published with a malware subpackage. After that many NPM packages were updated with newer package version and the hacker could steal the data that went through applications which had the hacked package inside.

To solve the problem many packages were updated to the previous non-hacked version. It’s not a problem only of the NPM. It can appear in any language library, some will be secured, though some will fail. A solution could be to not use the newest version. For example, update the package version every two releases or more, so the version has time to be verified.

So as you can see there are some pitfalls for which we need to be ready when we use NPM. Nevertheless, it’s still the best repository of libraries among all programming languages in my opinion, because you can find almost everything here. You want to generate pdfs? NPM has it. Work with colors? No problem. Sprite sheets? Sure, that and everything else you can find in the NPM. Just remember about security checks and you’ll be ok.

Node.js limitations

There is one more thing, namely, CPU usage. Node is very efficient when you try to do many I/O operations, however, if you’d like to use Node for e.g. image processing, just don’t. Due to its design, it operates with a main single thread and it is not suitable for heavy computations. An application can’t scale one process to all available CPU cores and it’s a little bit slower than Java, for example. Node wins when you need to do plenty of I/O operations, but in this situation, you’d need to choose another language such as Java or Python. Of course, we can use 100% of available cores thanks to the Node Cluster, however, it will create new processes, so we will gain only more requests than we can handle, no CPU power to compute heavy stuff.

So are you ready for Node?

In summary, you need to define what your product needs to do. I’d say that the only no-go is when you need to do heavy computation. Although, you can use Node as a service that will handle the traffic to your other service that is doing heavy computations.

It will fit in most cases. Now with the Nest as an enterprise framework, you can’t say no to Node.