What can you become in IT without work experience?
The article is dedicated to IT students. When 10 years ago I was a student at a provincial university, I thought that I was being taught to be a programmer. The teachers – theorists, associate professors, professors – were as far from real software development as the university program was from programming and modern technologies (it included six-month courses in Delphi, Pascal, 1C and Java). The diploma says faceless “engineer”; there was no one to ask for help.
Looking at the students and candidates I know who come for interviews, I can say that the problem is still relevant. Often, even people with several years of work experience do not understand what else they could do other than an almost randomly chosen direction. I myself coded for five years before I realized that my calling was in systems and business analysis.
Pictures speak louder than words, so here's a diagram. It presents the main specialties in IT and the most likely paths of development with arrows. As you can see, there are a lot of specialties, and only some require programming skills. Most likely, I didn’t remember everything. The Systems Analyst and Test Engineer are located on the border because understanding programming principles will make their lives much easier.
Retraining for a related specialty is almost always possible. Companies usually accommodate employees halfway, because it is easier to grow a motivated specialist on your own than to find the one you need on the market.
![](https://habrastorage.org/getpro/habr/upload_files/d3d/f49/aa0/d3df49aa0fef0909bc873ae633b9763b.png)
What can you become without experience?
I tried to arrange the specialties in order of participation in the work on the project from the start of the project to implementation, but some specialties are especially important in iterative development and work with the results of the previous iteration.
Business analyst
This person must answer the following questions:
What are we doing?
For whom?
What are the external restrictions?
What should be the work processes in a company?
What should happen to the information in the system?
A business analyst examines the activities of a company, its subject area, work processes, production, as well as regulations and laws to which the company must obey. A business analyst must find problem areas in work processes and suggest how they can be improved. It may happen that an information system is not needed for this. But we are talking about development, so a business analyst is the person who brings business requirements to the team, that is, he says how the system should change the life of the company and interact with users.
It will be much easier to pass an interview if you read a book before it “Development of software requirements” (K. Wiegers, J. Bitney).
Product Analyst
Essentially a subtype of business analyst on a system project that is developed iteratively without specific requirements from users. The task of a product analyst is to put forward hypotheses about which improvements will bring the maximum benefit, test them, abandon failed hypotheses, and so, through trial and error, manage the product to glory and greatness to gaining a competitive advantage.
Data Analyst
This person collects data and squeezes useful information out of it. His path is statistics, graphs, hidden dependencies and confidence coefficients.
This is a specific field in which mathematics, statistics and programming come in handy.
It is advisable to take a course in data analysis before your interview. It will likely cover the basics of Python programming.
Machine Learning Engineers are close to this profession, as they are engaged in setting up all kinds of neural networks. I did not single them out separately, because the requirements for vacancies for them are very similar.
BI Analyst (Business Intelligence Analyst)
A subtype of data analyst who specializes in generating reports, dashboards and presentations for managers and specialists who, based on these documents, will make decisions about the development strategy of their department or company.
Before the interview, it is advisable to take a course on the topic and practice working in a BI system.
Interface designer (UI/UX designer)
Defines the appearance and behavior of the user interface, but more importantly, the user journey within it. How many clicks the user will make to achieve his goal, how much time he will spend on the site page, what color the treasured button will be depends on the designer. The designer must be an artist and a psychologist, and also have a good knowledge of the patterns and capabilities of the platform on which the application interface is implemented.
Before going to interviews, it is worth taking a Figma course and adding a training project to your portfolio.
System Analyst
This person must answer the following questions:
How will we implement the requirements that the business analyst brought?
What technologies will we use for this, and how exactly?
What data and in what formats should our system exchange with the user, with other systems, between its parts?
How is data processed within the system and its parts?
What errors might occur?
The systems analyst serves as a liaison between the business analyst and the developers. It decomposes the needs of the business (customers, users) into technical implementation. A systems analyst knows exactly how the system works from the inside. And he also writes a lot. A systems analyst creates and maintains documentation that contains all technical requirements for the system. This is what the developer will use to write code, and the tester will check the implemented functionality.
There is often no clear boundary between business and systems analysts. The upper (collection of requirements) and lower (description of requirements for developers) boundaries of responsibilities may also vary – the level of development of requirements can be completely different.
Before the interview, I advise you to read the same book. “Development of software requirements” (K. Wiegers, J. Bitney) and telegram channel “Systems Analyst“.
Developer
This is the person who implements the requirements conveyed by the systems analyst.
The developer directly programs data processing algorithms, software interfaces, and manages data storage.
When choosing this path, you need to decide what is closer to you: user interfaces (frontend, all these screen forms, windows, buttons) or complex data processing algorithms (backend, the logic “under the hood” of the system); development of mobile applications, web or desktop?
Based on these preferences, you should choose a programming language and take a course on it, so that at least you don’t get lost in the syntax during the interview.
Quality assurance engineer
A person who ensures that all system requirements are met. The tester checks not only the implemented functionality, but also the requirements themselves for incompleteness and inconsistency. He also arranges load crash tests for the system, etc.
Like developers, testers can be divided into frontend and backend, but often work with the entire system.
Testers maintain a special type of documentation – test cases.
Technical writer
This person prepares official documentation for the system: technical specifications for customers, user manuals, marketing documents, and documents for registration with various organizations (for example, the patent office or the Ministry of Digital Development).
A technical writer does not have to have a deep understanding of technology; he describes the system from the words of other team members. However, he knows better than anyone else the rules for preparing documents, GOSTs, standards and rules of the Russian language.
Technical Support and/or Implementation Engineer
It is not entirely correct to combine these categories, but their responsibilities are similar and often combined.
The implementation engineer configures the system at the customer's stands. Depending on the project and the complexity of the system, he can deploy the system himself or wait for the DevOps engineers to complete their work.
The implementation engineer interacts with direct users of the system, trains them, helps them adapt to the system, collects pain points and wishes, and records errors in trial operation.
The first line technical support engineer also interacts with users, records requests, errors, and provides consultations. The second and third lines of technical support handle more complex requests.
Both types of engineers know the system well and can perform an initial analysis of problems: reproduce errors, analyze system logs and data in the database.
Experience as an implementation engineer or third-line technical support is a good basis for development into system analysis or testing.
What can you become after gaining experience in development?
Project manager / Product owner
Often appearing from a business analyst, product analyst or manager from outside IT.
They perform similar functions – they determine the boundaries of the project and the direction of development based on financial indicators, risks and deadlines. These people create the project plan and monitor its implementation. They also assess risks and make decisions about what actions to take if a negative situation does occur. They recruit the team and distribute funding.
Project managers are usually present in custom development projects or products with a clearly defined target audience and direction of development. Product owners are responsible for product projects that have clients, but no customers outside the company.
Head of the development team (Team lead)
Usually grows out of a developer, systems analyst or tester.
This person organizes the work of the development team. He serves as a liaison between the project manager, the company's senior management and the team. He synchronizes the goals of the company and the development team, builds internal processes, selects personnel and monitors the development of subordinates.
The team lead needs to have both managerial skills and technical knowledge, because without the latter it is impossible to effectively solve the internal problems of the development team.
System Architect
Usually grows out of a developer or systems analyst, sometimes from a tester.
This person designs the system at the level of components, data exchange between them and with external systems. Unlike an analyst, an architect solves not immediate, but strategic problems. He must understand in which direction the system will develop in the next six months, a year, three years, in order to fit the current development into the target solution and thereby reduce the need for a global rework of the system in the future.
Information Security Engineer
His responsibilities include analyzing system vulnerabilities and ensuring data protection. Responsibilities may include analysis of the system architecture and code, analysis of logs, system administration, monitoring and analysis of the actions of company employees outside the system, training employees in information security rules.
DevOps engineer
Often grows out of a developer, tester or implementation engineer.
A generalist who is responsible for deploying the system, allocating resources for it, delivering updates to stands, system administration, fault tolerance and security.
PS
I also wanted to talk about why you shouldn’t be afraid of interviews, how to write a resume if you have no experience, and how to choose a company you like, but the article was already very long. I will raise these topics next time.
I have an idea collect contacts of experienced specialists in various fields, to whom students can write in a personal message/messenger and ask questions about the job itself and what they need to prepare for an interview. Of course, there are many articles on “what a beginner needs to know,” but, unfortunately, they cannot replace personal questions.
If you are a middle+ or higher level specialist and agree to take part in this initiative, please write your specialization and communication channel in the comments. I will collect these contacts into a single list and add them to this article or the next one.