The Resume

Any job search begins with a resume. The main goal at this stage is to use it to give your future manager complete information about yourself—as fully as possible, yet clearly and concisely.

The most important thing at this stage is not to fall into the trap of writing “What I WAS DOING.” Instead, write “What I ACCOMPLISHED.”

Bad Example:

• Configuring Cisco switches

• Configuring routers

• Configuring firewalls

Good Example:

• Responsible for supporting the local office network built on Cisco switches. Managed the support of existing infrastructure, installation of new equipment, and replacement of failed devices.

• Configured Cisco routers, ensuring stable VPN connections between remote offices and the central office.

• Responsible for providing network access based on tickets by adding rules to the company firewall.

• Participated in a migration project moving from one vendor’s equipment to more modern models from another manufacturer. Responsible for the transfer and subsequent adjustment of configurations.

After reading your resume, your potential future boss should understand what you did previously and what experience you possess.

You don’t need to write a lot. You don’t need to write a little. Write about yourself and your skills briefly but substantially.

“Tell Me About Yourself”

So, your resume was noticed, and you were invited for an interview.

After a short greeting, you will be asked to talk about your past experience at other companies. Be ready to fit your story about yourself and what you did at your last job into 2–3 minutes. There is no point in going too deep into details—they will ask you about all the interesting specifics later. Explain what position you held, what your duties included, and your main achievements.

If you have absolutely no experience and have just graduated from a university or a bootcamp, talk about what you studied. A description of the course curriculum or a summary of your thesis project will work fine.

“Do You Know This Technology?”

Immediately after (or even during) your “about me” monologue, they will ask you for details regarding your activities, and then smoothly transition to theoretical questions. You will be asked about well-known technologies, configurations, and methods. For example:

• What is the BGP protocol? Why is it needed?

• What is a routing table? What parameters are specified for routes?

• What is Spanning Tree? Why is it needed?

• How does a router differ from a firewall?

• What is needed to build an IPsec VPN tunnel?

Answer with everything you know. If you forget specific timers, terms, or something similar, explain it in your own words—this also demonstrates your general understanding and is valuable.

“What If They Ask About a Topic I Don’t Know?”

Don’t worry! They definitely will! There is a simple and correct answer to this, which sounds something like this: “No, I don’t know this topic. I haven’t had to work with it before. But I would find it VERY interesting to learn. I’ve wanted to for a long time!”

Remember that we gain 80% of our knowledge not while studying in courses, but while working and dealing with tasks on a daily basis.

“Why Are You Looking for a Job?”

After the technical part, they will ask about your attitude toward your previous job and your career goals.

A bad answer to such questions is to tell them what villains surrounded you at your last place (especially the boss) and how hard it was to work with them.

A good answer sounds something like this: “I already did a lot of good and useful work at my last place. I reached a ceiling in my development. I want to grow and develop, but I can’t do that there, so I am looking at companies where I can be useful and am considering offers.”

“What Are Your Salary Expectations?”

The traditional game at every interview! The rules are simple: whoever says a number first loses.

Example answer: “I would, of course, like ‘the more the better.’ But I understand that you have a fixed budget for this position. If I am a good fit for this vacancy, I am ready to consider your offers.”

It is undoubtedly appropriate to name a desired sum yourself if you have a good idea of what such a specialist costs in the labor market, but under no circumstances should you lower your expectations! Remember that the interview is the exact moment when you negotiate your salary! Increasing it while employed is exponentially harder than negotiating it when moving to a new job!

“Your Turn to Ask. What Do You Want to Know?”

Bad answer: “Nothing. I have no questions.”

Good questions that should interest you:

• What are the main tasks for this position for the next six months?

• Can you tell me about the team? Who is on it and whom will I interact with?

• What is the work format: remote, hybrid, or full-time in the office?

• Are there frequent emergencies, or is there a need to stay late for work issues?

• Is corporate equipment provided for work: laptop, phone?

Do not neglect these and other questions. Ask at least a couple of them “out of politeness.” In any case, this gives you more understanding of the place, because right now, not only are they choosing you, but you are choosing them.

After the Interview

Any interview is stressful, even for very experienced specialists. After it, you need to rest, and the next day, with fresh energy, analyze the entire dialogue and identify your strengths and weaknesses.

If you were asked about a technology or function you didn’t know, read about it on the internet for your general development. A short article on Wikipedia or a similar resource is enough to understand the principles. At the next interview, you will already know what to answer!

What’s Next?

Speaking of future interviews: Don’t wait for an answer from this employer; immediately arrange subsequent interviews with others. Your goal is to pass several interviews and receive several job offers at once, then choose the one you like best.

Even if you passed just one interview and were immediately offered a job, still try to talk to at least one or two other places. If you think that only people with little experience and knowledge go through multiple interviews, that is a huge misconception! On the contrary, if you interviewed at a company and they hire you immediately, you likely either got incredibly lucky (unlikely) or you stated salary expectations far below market value, and they want to hire you for cheap as soon as possible.

Don’t overthink it by saying, “But that’s not polite…” You definitely have 1 or 2 weeks to “think it over.” Use them with maximum efficiency for yourself! Aim for anywhere from 3 to 10 interviews. At some, they won’t like you or you won’t fit; at others, you won’t like the employer (this happens much more often than you might imagine). From the remaining ones, you will choose (!) whom to join.

Regardless of the scale of your organization or the hardware you use, glitches happen. Sometimes network access drops, a system crashes, or something else goes wrong. Naturally, when a problem is detected, the responsible staff takes every possible measure to restore functionality as quickly as possible.

After restoration, an analysis of the incident’s causes is conducted, and measures are developed to prevent similar situations in the future. All of this can be described as the “Incident Management Process.”

Typically, companies use one of the following approaches to incident response:

Startups or Small Firms

In the event of any problems or outages, everyone turns to a specific specialist. That person analyzes the situation and resolves the issues.

Mid-sized Business

A larger company where IT infrastructure support is handled by several employees or even departments. In these situations, general chat groups (in Slack, Teams, etc.) are often created where incidents are discussed collectively. The employee who discovers a problem in their area of responsibility provides colleagues with detailed information and shares a subjective estimate of the time needed for recovery.

Enterprise (Large Business)

In large organizations, incident resolution is a fully established process. Critical systems are monitored 24/7. In the event of an incident, the Monitoring and Response team immediately organizes an emergency conference (a “war room”) and invites the relevant specialists. After the incident is resolved, the suspected cause is recorded, and the data is sent to a special commission. Furthermore, incident review board meetings are held periodically to thoroughly analyze every case. Root causes are identified, preventative measures are developed, and employees are assigned to implement them.

While this sounds modern and high-tech, the devil is in the details…

Let’s look more closely at that last option involving the process and the commission analyzing incidents, keeping in mind that all process participants are human.

The Incident Review Board

This board consists of respected employees holding relevant positions. They rightfully occupy these roles and possess a broad outlook, knowledge, and experience. However, obviously, they cannot know everything. They may not always have the competence to make a correct judgment. For example, they might have significant experience in server administration, but the problem occurred in the networking environment—specifically within dynamic routing protocols they have only read or heard about.

On the other hand, their role implies making a decision, even with insufficient knowledge in a specific area.

There is also a third aspect: the psychological one. Most people in leadership positions have a subconscious fear of losing face and publicly admitting they don’t understand the issue.

Over time, a standard behavioral algorithm develops for members of the review board. The analysis of any incident must give them answers to two questions: Who is to blame? and What do we do?

The Engineers

Now let’s look at this process through the eyes of the responsible employee. During the incident, they reacted quickly, eliminated the consequences, and restored their system.

Are they a hero?

Yes, absolutely. But almost immediately after the incident, a colleague or manager asks them to prepare a report describing exactly what happened—naturally, with precise timestamps, all details, and in accordance with the established form.

Even if all causes are known and clear, putting them on paper takes time and effort. But what if it turns out the outage happened because of an action taken by the employee themselves? They are human, too. And they don’t want to feel guilty. So, instead of solving current tasks, they start thinking about how to present the facts to avoid liability.

The larger the organization, the more formalized this process becomes, and the stronger the impression that all these reports and reviews are part of a punishment system for the mere fact that an incident occurred.

Who suffers most from this approach?

Let’s take it as a given that humans make mistakes.
IT specialists responsible for keeping infrastructure running are no exception. Let’s assume a specialist makes a mistake in one out of a thousand operations. A simple typo while configuring equipment might not affect the system at all—for example, if an engineer makes a typo in the description field. But with the same probability, a typo in the configuration logic can lead to the loss of a critical company resource or even the entire infrastructure.

In any case, the more operations a specialist performs, the more mistakes they make. In other words: those who work the most, make the most mistakes, and consequently suffer the most from this attitude toward incidents.

It turns out that the process created to combat incidents actually begins to backfire in some cases:

1. It wastes more employee time, distracting them from daily tasks and increasing the risk of future incidents.

2. It indirectly punishes the hardest workers.

That doesn’t seem quite right, does it?

Criticizing? Propose a Solution!

First and foremost, with any incident management approach, I advise against looking for scapegoats. All participants in the process without exception—users, specialists, managers, and even business owners—should focus on quickly identifying the root causes and eliminating them, rather than finding someone to blame. This is only possible if everyone is confident that telling the truth won’t get them in trouble.

In other words, during any incident, the question should be: “What was done last, and by whom?” And every specialist should answer honestly and without delay: “I did nothing” or “I did X at location Y.” If the incident is caused by human error, this cuts troubleshooting time drastically. If you look deeper, you could say the specialist has a right—or rather, a Privilege—to Make Mistakes.

Judge for yourself. If they are scolded for every slip-up, glitch, or downtime, the natural reaction will be to not touch the system at all. Consequently, they won’t fully understand its capabilities and limitations. This means more time will be needed to react in the event of a system failure.

An experienced specialist is not afraid to make mistakes. Through them, they gain valuable experience and an understanding of the system’s strengths and weaknesses.

At the same time, an experienced specialist never forgets the responsibility and trust placed in them. After all, their actions directly affect the availability of the systems and services entrusted to them, and thus the business as a whole.

The specialist’s motto should be: “You broke it? You fix it!”

Remember Responsibility

Every specialist should know that a single incident caused by their actions will not result in any punishment. However, everyone will expect their active participation in analyzing the causes.

In the case of a repeated incident, the company should consider changing the IT process that might be leading to human error.

Only upon the third recurrence of the same incident involving the same specialist should disciplinary measures be considered.

To summarize:

1. Don’t look for the guilty party. This ultimately leads to an increase in incidents or the time required to resolve them—and consequently, direct losses for the company.

2. Instead, try to minimize the time spent finding the root cause.

3. If the system isn’t working, nobody touched anything, and it’s unclear what to do with it—just reboot it.

Monitoring systems are, without a doubt, a useful and critical tool. Everyone recognizes their necessity. However, for most organizations, implementing these systems is fraught with difficulties. It often happens that engineers spend most of their time maintaining the monitoring system itself rather than having it help them solve problems.

Let me share some personal experience that will likely help many people better understand the problem.

Monitoring “As Usual”

So, management concludes that a monitoring system is critically important and assigns the task of implementing it. An engineer, who is already busy with their core duties—like configuring networks—is told to “deploy a monitoring system.” Often, no one knows how to do this because it’s their first experience in this area. Let’s say the company has a hundred remote branches, and they need to monitor the availability of communication links with each of them. In this situation, they start looking for free solutions, studying available options, and picking one.

Usually, they choose the simplest solution based on checking endpoint availability via ping. After spending significant time installing and configuring it, they expect immediate results. However, the system starts throwing false positives. For example, a remote branch has a primary and a backup link, and the system monitors both. The engineer gets an alert about link issues, checks the availability, and finds that everything is working fine. The monitoring system cried wolf. Despite cases where there are actual problems, most alerts turn out to be false. As a result, instead of helping, the monitoring system simply scatters your focus, leading people to eventually neglect it.

Let’s look at another scenario. In addition to remote sites and links, the central office has critical equipment that needs monitoring. You set up availability checks for devices and their parameters. However, when a real outage occurs in the central office—especially if it affects network equipment—the monitoring system turns out to be useless. How can it transmit information if the infrastructure’s root equipment is down? You will most likely hear about the problem via a phone call or someone yelling, “Everything is broken, go fix it!” After the issue is resolved, the monitoring system will come back online and flood your inbox with thousands of emails about what happened. Very timely, right?

Suppose the company realizes the need for a more advanced monitoring system and chooses a solution with SNMP support. This protocol allows devices to send data about their status—such as CPU load, memory usage, and network interface status—to a centralized collector. After installation and setup, even if you aren’t a specialist in this field, you discover that every device on the network is constantly reporting some kind of “problem.” For instance, one device has constantly high CPU load, another is low on memory. Generally, this state might be normal for that specific device. However, the monitoring system constantly flags issues, demanding attention and verification. The result is the same: a reluctance to react to constant false alarms and a desire to receive only reliable information about real problems. Ultimately, the monitoring system gets less attention than it should.

And the final scenario. Suppose you got really into the setup, and everything is configured perfectly. Data is being sent correctly, and false positives are minimized. But an outage happens after hours. What do you do? If notifications are set up for external communication channels, you’ll get the alert at home. But is it worth driving into work in the middle of the night? If notifications aren’t set, you’ll only find out about the problem in the morning, which leads to lost time and a delayed response.

Monitoring: Successful Use Cases

As a constructive suggestion, I’ll share some experience gained from a professional in the field of monitoring. He told me about several successful cases where a monitoring system was used for good.

The first case involves monitoring a router in a remote office that acts as a gateway for internal networks and has external communication links. Simply tracking external interfaces doesn’t allow you to determine if the entire router has failed. Monitoring internal interfaces also doesn’t give a full picture, as they can be disabled accidentally or intentionally. Checking CPU or memory load might not indicate an outage but rather reflect normal device operation. So, what do you do? The solution is event correlation. Every office has a set of static infrastructure services: a print server, file server, DNS server, email server. Modern monitoring systems allow you to link events; meaning, to determine a router failure, you need to track the failure of all these services within a short timeframe—for example, 15 seconds. Combined with link monitoring, this gives you grounds to call in an engineer and suspect a router failure.

The second case is one of the most illustrative examples demonstrating the value of monitoring systems, even from a financial perspective. A guy who worked in the banking sector told me about this. As you know, banks have an extensive network of service offices, ATMs, and other remote points connected to the central office via communication links.

These links are usually purchased from a large ISP capable of providing coverage for the necessary territory and are secured by a contract. The contract includes an SLA (Service Level Agreement), guaranteeing 24/7 link uptime. All parties agree, the contract is signed, and connectivity is provided.

However, given the scale of the network, the ISP periodically has issues leading to glitches and disconnects. This is where the efficiency of the monitoring system shines. First, the system automatically generated a ticket for the ISP upon detecting a connection break. This ticket, containing the contract number, failure point info, timestamps, and other parameters, was sent to the duty engineer, who only had to confirm it and email it to the ISP’s tech support.

Secondly, the monitoring system kept statistics on all tickets and generated a monthly report reflecting the total downtime of communication channels and details on each incident. This allowed the company to save significant money through penalties for SLA non-compliance. Thus, a win-win situation was created: if there were no failures, the ISP faithfully fulfilled its obligations; otherwise, the bank received compensation for the breach of contract terms.

Afterword

Implementing a monitoring system is a complex and responsible task, requiring not only specialized knowledge but also an understanding of the company’s business processes. Therefore, it is inefficient to assign its setup to engineers who are busy with other tasks.

For the system to work effectively, you need a dedicated specialist to handle its configuration, optimization, and monitoring. Furthermore, you need staff who can react promptly to emerging incidents—a duty shift or specially trained specialists (NOC). With a comprehensive approach, a monitoring system becomes an indispensable tool for the company, significantly simplifying the work of engineers and increasing business efficiency.

Let’s talk about the most interesting topic: salaries for modern IT specialists. Naturally, the figures mentioned here aren’t set in stone, but rather serve as a rough benchmark.

Junior Network Engineer (or simply Network Engineer)

This person has studied the basics of network technologies.
They know what routing is and how switches work.
They have heard of firewalls.
They have a basic understanding of existing IT systems, servers, and virtualization—at the level of “read a couple of articles on Wikipedia or similar resources.”

With this background knowledge, zero experience, but plenty of motivation, they arrive at an interview. After successfully passing it, they start working in a position paying $65,000–$71,000  per year.

At this new job, they handle simple, routine tasks: configuring equipment using pre-made templates, investigating why communication links are down, and fulfilling access requests. They handle other mundane duties. At the same time, thanks to constant practice and hands-on work with hardware, they dive much deeper into the theoretical aspects of how technologies work, while also gaining experience interacting with the company’s specific network equipment.

They work like this for about 2–3 years, gaining invaluable experience and knowledge, after which they begin to qualify for the position of Senior Network Engineer.

Senior Network Engineer

This position brings the engineer $90,000–$110,000 per year. It includes all the same duties as the Junior Network Engineer, but at this level, the specialist is assigned to solve particularly important or complex routine tasks.

Management also starts occasionally assigning them unique new tasks for which no templates or regulations exist within the organization yet.

For example: There are 10 offices, and a VPN tunnel is built with each one. Every office uses the exact same equipment from the same manufacturer. Suddenly, a new office opens, and a similar VPN tunnel needs to be established. However, it turns out the new office bought equipment of the same class, but from a different manufacturer. A VPN tunnel needs to be configured with it.

On the surface, it’s the same task the specialist has solved before. But the use of new, unfamiliar equipment adds complexity.

Furthermore, assuming the engineer is smart, they have continued to study networking theory deeper and broaden their horizons this whole time.

But what does “broaden their horizons” mean? It sounds complex and vague. However, in the modern world, there is a huge number of existing technologies and just as many emerging ones. One way or another, we constantly hear new words and terms. To broaden your horizons, all you need to do is write down any new term you hear in a notebook, and at the end of the day, simply search online for “what is this term and technology anyway.” It doesn’t necessarily have to be about networking—let it be virtualization, databases, or even something new about programming languages. I assure you, if you read just one short article every day, in a year you will accumulate a very solid knowledge base that will help in any field of activity.

Returning to IT salaries, we see a picture where this Senior Network Engineer has 5–6 years of work under their belt, excellent practical skills in equipment configuration, a wealth of theoretical knowledge, and a decent outlook on the world of IT technologies. With all this, they are ready to apply for the position of “Lead Engineer” with a rate of $123,000 per year.

Lead Engineer

These engineers no longer need templates. They clearly know how everything is organized, the optimal way to configure specific equipment, and generally understand how to optimize any given area of their work.

In this role, the engineer begins to solve more and more new, non-standard tasks, most of which boil down to two directions:

1. How to change the existing network so that it meets new tasks, requirements, and conditions.

2. How to introduce new devices into the existing network so that they perform their functions without damaging the company’s existing infrastructure (so-called integration of new technologies).

This can include:

• Replacing old equipment with new or more powerful hardware.

• Installing new systems that had no prior analogue in the organization.

• Complex changes to the network schema itself.

• Other interesting tasks and challenges.

At this point, your horizons begin to expand almost automatically. Every task is a new challenge. New equipment, new integrations into the existing network, and other fascinating aspects.

The next few years in this position turn you into a true professional who knows their business and is ready to squeeze the maximum out of available equipment to benefit the company.

Chief Engineer, Architect, and Project Manager

After approximately 5–7 years of a career, the engineer—now a true professional—faces a choice of three vectors to pursue. Each position allows for a salary between $113,000 and $170,000  per year, but the role the engineer plays will change depending on the chosen path.

If the specialist works in a relatively small company with few employees, their position will likely include all three of these roles. However, in a large organization, these will likely be three separate positions. An engineer can become a Chief Engineer, an Architect, or a Project Manager.

• The Chief Engineer is a direct path of development implying a concentration of effort and experience on the support and maintenance of the existing network. All new projects and implementations pass through this engineer. They are responsible for ensuring everything works normally and that any technical glitches or difficulties are resolved as quickly as possible. Usually, this position is occupied by people with pronounced technical skills, strong memory, knowledge, and practical experience. Often, they do not like excessive communication. They find it much more interesting to tinker with equipment and get the most out of it.

• The Network Architect, conversely, is responsible for network development. This is an engineer with a good imagination, a creative streak, and strategic thinking. They are constantly on trend, trying to learn about new equipment and technologies appearing on the market. Their main task is to design new sections of the network, actively participate in product integrations, draw up schemas for system operations, and so on.
  This role implies much more communication with colleagues, even those who do not understand technical issues very well. The Network Architect needs to understand existing tasks, study all currently available technical solutions, and then choose the most effective one. After that, they work through all theoretical issues and, together with the implementation team, realize the vision, taking responsibility for the final success.

• The Project Manager. This is a person with a massive outlook and experience in the field they manage. This is the least “technical” role at this level, but no less important. This specialist must tie together all existing points of view: the manager setting the task, the network architect proposing a path for execution, and the chief engineer along with the colleagues who will have to configure and support the equipment. The Project Manager must find a common language with everyone and constantly synchronize the actions of the process participants. Communicative, active people who are less interested in technical details and prefer organizational work feel very comfortable in this position.

If we take a non-networking direction—for example, a Systems Engineer—the salary ranges and general scope of duties will be absolutely the same. Only the specific tasks and nuances related to the chosen direction will change.