How to Interview for a Systems Analyst Position in 2024
The search process begins with communication with a recruiter. What questions to ask?
Questions for the recruiter
Before entering into a long correspondence, clarify three main points:
does the vacancy offer a remote work format;
how many stages of selection;
what kind of fork does the vacancy have?
After all, after going through several stages, it will be very unpleasant to find out that you can only work in Moscow, and after the first technical one, you will still have practice, system design, behavioral, acquaintance with the team and the grandmother of the technical director. They offer 100k money before taxes for this pleasure.
By the way, when asked about the fork, recruiters often answer something along the lines of: “We can’t tell you what your expectations are?” Please do not be fussy and directly state the amount you want.
Firstly, you will save time, and secondly, if the interview goes well, you can always raise your salary at the negotiation stage.
There is a possibility of getting cheaper, but to avoid this, always study the market and indicate your desired salary a little more.
The number and duration of interview stages may vary from company to company, but the most common are the following:
Screening. A short introduction to the recruiter and answers to basic questions. A sort of test for adequacy. As a rule, it does not take more than half an hour.
Technical interview. It tests “hard questions”, questions on business and system analysis, tasks and everything that the company considers important. Duration is from an hour to an hour and a half. Technical ones can be from one to infinity.
Meeting the team/service station. A formal meeting where anything technical is rarely asked. More like the final stage before receiving an offer.
Test task – only for juniors. No, they can offer it to everyone, but I don’t see any point in giving the test to specialists above the middle level. The demand for analysts in the Russian Federation is gigantic; you are more likely to find a company where they can test your skills without a test (for example, only on the technical side). They usually give it after screening, but they can also do it after technical screening.
I would like to highlight screening separately. Prepare answers to all the trivial questions: why did you decide to change jobs? What are the strengths and weaknesses? Where do you see yourself in five years (just kidding, they stopped asking that). Here it is very important to correctly answer 2 questions: are you actively looking for a job and are there any offers on hand?
You are ALWAYS actively looking for a job, and there are ALWAYS offers.
By answering this way, recruiters will understand that it is better not to delay too much and immediately assign you the next steps. After all, you don’t want to lose good specialists. Well, don’t forget to ask your questions, but more about organization. You are unlikely to get an answer to anything deep.
Self-presentation
A technical interview is divided into three blocks: a story about yourself (or self-presentation), questions for you, and questions from you. Self-presentation sets the tone for further conversation, cuts off some questions and shows you as a specialist knowledgeable in your field. It is all the more surprising how few candidates actually prepare for this part and can present a detailed and interesting story about themselves for 5-7 minutes.
So, what does the interviewer expect when he asks the question, “Tell me about your experience?” Oddly enough, a short, rich story about the tasks being solved and your strengths.
Think about the structure so that you don’t jump from project to project, but present the key points logically. If there is too much experience and companies, then it is better to talk about the last two places of work at most.
Few people are interested in what was there before.
I myself adhere to the following structure:
Greetings. I introduce myself, talk about what projects I have worked on and how much experience I have.
I’m talking about one or two projects – what did I do? What methodology did you use? team size? What artifacts did he leave behind? what tools did you use? In this block I highlight all the keywords from the vacancy: we worked on SCRUM, microservice architecture, rest integration, used a broker as an asynchronous interaction, etc. Whatever the interviewer wants to hear, he gets here.
Separately, I highlight any difficult task that stands out from the standard routine. I’m talking about it both from a technical point of view and from the point of view of its impact on business.
I polish this beauty with additional features that make me stand out from the rest. For example, I say that I actively mentor and lead tg channel. I always end with the phrase: “If you have any questions, I’m ready to discuss.”
It would seem nothing complicated, but candidates often make a number of mistakes that spoil the overall impression:
The structure of the story may be completely absent. The analyst jumps from topic to topic and loses the thread of the story. As a rule, such candidates do not try to answer a question they see for the first time, but immediately say: “I don’t know.”
The story is too long. This happens among analysts with extensive experience, as well as people 35+. They will tell you how they studied at university in the 90s, how they worked at a factory in the 2000s, got closer to tenth grade in IT, and then the time for the interview will come…. To be fair, if you find yourself in the role of an interviewer and find such a candidate, ask the question more precisely: “Tell me about your last place of work as an analyst?”
The story is tied to past, specific experiences. Here you seem to listen, and they wrote technical specifications, and coordinated technical specifications, and won tenders, and whatever else they did. In fact, the candidate played the role of a one-man orchestra somewhere in a state company, and can hardly imagine how modern development is organized.
Business Analysis Section
You spoke clearly about your experience, made a positive first impression, now it’s time to check the hard drives. In general, the interview is divided into 2 types: the company can ask general information on business/system analytics (top 100 questions on CA) or ask specific questions about the stack they use. And if we look at the first type today, it’s problematic to prepare for the second, because all you have is a vacancy. You know without me that expectation and reality rarely converge.
In the business analysis block, they ask classic things from “Software Requirements Development.” From the role of BA/CA on projects and types of requirements to documentation and modeling. Recently, not much time has been allocated to questions on business analysis, but they are actively asking about system analysis, and specifically integrations. Structurally, the BA block is divided into the following parts:
General questions about the role of AD/SA
Project life cycle and flexible methodologies
Working with Requirements
Work with documents
Modeling
And the lower the candidate’s level, the more theoretical questions he will receive. More experienced colleagues can avoid the “base” if they highlight key words in the story about themselves. In general, the information is not secret and is in open sources; most theoretical questions can be easily learned by heart. Let's look at each of the parts of the BA block in more detail:
General issues
Here they ask about what a business/systems analyst does in general. What is his role and value in the team? What problems does it solve? What is the difference between a business and a systems analyst? Or maybe you can do without an analyst at all? What artifacts are the result of the analyst's work? What tools does he use?
Project life cycle and flexible methodologies
There are not many questions about the life cycle; it is rather important to understand what stages of the life cycle exist and what the analyst does at them. But they ask well about flexible methodologies. What are SCRUM and Kanban? What is the difference between these approaches? What roles and ceremonies are there in SCRUM? Name the Agile manifestos. Exclusively theoretical knowledge that is not applied in work, but for some reason they ask.
Working with Requirements
They generally ask everything regarding requirements. Give classifications of requirements. What requirements gathering techniques exist? Which ones to use in a particular situation? How to manage requirements? How to validate and verify them?
Work with documents
Everything related to documenting and recording requirements, both traditional types (TOR) and flexible (Use Case/User Stories). What sections would be included in the technical specifications and why? How would you write an integration specification? Are you familiar with GOST 34? What are Use Cases and User Stories, give examples?
Modeling
They ask for knowledge of basic notations. What is BPMN and what elements are there? What UML diagrams do you use? Plus specific questions on individual UML diagrams, in the spirit of – What types of connections in a class diagram can you name?
To summarize, advanced software and the ability to “chat” are very helpful in business analysis. Everything related to the analyst’s work and requirements are debatable questions that can be discussed for a long time. Yes, of course, there are always rules and recommendations, but no one forbids saying: “This is how it was in our company” and inventing, inventing, inventing.
System Analysis Section
As part of the interview, the system analysis block involves testing the candidate’s technical skills. The reality is that this is the most important segment showing your level. It is realistic to prepare for theory, although it is a little more difficult than in business analysis. But practice will be easy if you have already worked with this or that technology. Otherwise, some abstract concepts may be difficult. Globally, the systems analysis section is divided into three topics:
Software architecture
Web services
Database
It would seem that there are only three topics, but if you look at it, each of them can be discussed for hours. Today we are considering exclusively theoretical issues, and we will leave practice for the future.
Software architecture
What types of software architecture are there? What is the difference between monoliths and microservices? What are the pros and cons of monoliths and microservices? Implementation patterns for microservice architecture?
Most often, attention is paid to monoliths and microservices, although you can always show off your knowledge and talk about serverless or service-oriented architectures. On the other hand, if you are not sure about something, it is better not to go there.
Web services
Behind this topic lie questions affecting integration. And from top-level to specific ones. What types of integration can you name? What is the difference between synchronous and asynchronous integration? What are REST and SOAP? What is the difference between them? What is ESB? What is the difference between a broker and an ESB? What authentication methods can you name?
In fact, here you can dig and dig, you can pull out a separate technology and talk about it. But the most frequently and deeply asked question is about REST. What are RESTful principles? What HTTP methods can you name? Which methods are idempotent? What response codes do you know?
On an interesting note, I was once asked: “Why is WebSocket used to implement chat, and not gRPC?”
Database
A classic that is asked both by business and system analysts. Most often they are asked to solve a simple problem in SQL using JOIN and aggregate functions. If we talk about theory, I would highlight the following questions: What is the difference between SQL and noSQL databases? What is normalization? What is a transaction? What methods can you name for scaling a database?
Practical section
Most often, the section is separated into a separate interview in large companies. In an hour and a half you will be asked to solve various problems that can be combined into three categories.
SQL task
The most popular task that tests the corresponding skill. Most often, an analyst is asked to write a SELECT using a JOIN from one or more tables, using aggregate functions and grouping.
It is worth mentioning that the tasks may be more complex, but most often this will be clearly indicated in the vacancy. For example, a requirement for knowledge of window functions.
Domain Modeling
Here, most often, the analyst is asked to design some kind of diagram, showing a process or subject area. I got BPMN, Sequence, and ER. Depending on the level of the vacancy, the company may not be tied to any notation at all, but simply test the candidate’s systematic thinking.
An example of an interview task sounds like this: Design a logical data model for an online bookstore. Or another example: Design a Sequence diagram for the payment process in a banking application.
API task
This opens up space for creativity. The simplest task is to find errors in JSON or XML.
A more interesting question might sound like this: Design an endpoint for an online store selling books.
Please note that both this and the previous examples contain elements of system design. The more questions the analyst asks the interviewer and the more the scope of work is narrowed, the easier it will be. You understand that it is impossible to create an adequate API in an hour? You cannot do without the proper level of abstraction.
Questions after a technical interview
Congratulations, you have passed the technical interview. They answered business analysis questions smoothly, applied knowledge on integrations to the system analysis sections, and finally, the interviewer said: “I’m done, now I’m ready to answer your questions.” About half of the candidates are stuck at this moment and don’t know what to ask. Here's a sample list of great questions that show you as an engaged analyst.
“What do I have to do every day? What are my responsibilities? Tell us an approximate day for a systems analyst.”
With this bunch of questions you show your interest, plus you immediately more or less understand the scope of work. Yes, there is a job description and a story from the recruiter, but they are usually very abstract. Here, a person who is actually involved in the company will be able to talk about combat missions.
An answer along the lines of: “Well, we actually never had a systems analyst, and we hire one because it’s cool and fashionable” is bad.
Unless the position involves building analytics from scratch, then there is appropriate compensation.
“How are work processes structured? What methodology do you work with?
Needed to get an idea of how the work will go. Is it possible to solve problems in an assembly line mode or will you have to constantly sit on calls, discussing every sneeze? A clear and described flow, as well as its understanding, greatly simplifies and speeds up the work.
If they answer you: “Each task is unique and requires careful discussion with the entire team,” know that it is better not to work in such a place.
“Is there an employee development plan? And the development plan for the company as a whole?
The question is needed to understand from the very beginning whether there will be an opportunity to upgrade expertise and develop. An employer may not have an internal portal with courses, but will compensate for external training. When asking something like this, they will most likely tell you additionally about the salary review process. A bad answer sounds like: “We have such interesting problems that employees develop simply by solving them.” Read it as: “In 3 months you will be bored, but we won’t do anything about it.”
It is also worth asking questions that concern you based on past experience. For example, processing, KPIs, etc. Find out about everything that caused inconvenience earlier, so as not to run into the same rake. For example, at my previous job, the bonus part of my salary (analyst) depended on the SLA of support tickets. Naturally, I primarily solved user requests, and did not do what I really like.
I want to remind you that asking questions is extremely important. And every question is appropriate to ask in the right situation. For example, you shouldn’t talk about your salary at a meeting with your team, but you can find out about remote work even during the first contact.
And more useful tips
As a bonus, I'm sharing with you a few reminder tips that apply to the interview process in general.
Interviews and real work have virtually nothing in common
Most interviews test theoretical knowledge, and practice takes a back seat. The work, for the most part, involves solving specific, narrow problems. You can automatically rivet synchronous integrations using existing documentation, fitting them into standard processes. But this will not help if during the interview you are asked about authentication, asynchrony, non-relational databases and the like. You can be a powerful practitioner, but without a base and understanding of why we do it this way and not otherwise, you can’t pass social security. This leads to the second piece of advice…
You should always prepare for interviews
The theory easily disappears when you don’t use it constantly. The time spent on preparation is converted into a better offer. It will be very annoying if you are a master of use cases, but forgot to repeat the types of requirements for BABOK. Globally, this will not put an end to you, but it will definitely give the employer a reason to offer less money. And even with structured information in your head, it is important to present the experience correctly. Therefore it is worth…
Learn to sell yourself as a highly qualified specialist
During the interview, both sides are a little disingenuous: the company may remain silent about the outdated stack or the amount of technical debt, but you shouldn’t tell everything as it is. For example, you use SQL once a month to check the availability of data in the database. To the employer’s question: “Do you speak SQL?” It’s fair to answer: “Yes, I own it, I use it in my work, I create reports.” And here there are two options for events: they will either ask you to solve a problem that you can master (after all, you prepared and repeated the syntax), or they will answer: “Well, okay” and move on. Always present yourself a little better than you really are; if in doubt, they will immediately check you. There is no need to bury yourself. And finally the last piece of advice…
Always bargain for an offer
Having received a long-awaited job offer, it is very easy to say: “Yes, I agree to everything.” But wait, chances are the employer will be able to give even more. Don't be afraid to bargain. The easiest way is to write something like: “Thank you for the offer, I really liked you, but I have another offer, and I can’t choose where it would be better for me. Is it possible to improve conditions? The offer will not be withdrawn and they will not look at you crookedly. In the worst case, they will say: “Sorry, we can’t change the conditions.” Then just accept it as it is and stay with it.
I partially understand why many candidates are unable to talk about their achievements and are afraid to ask for more. My generation was taught not to stand out and to be modest. But an interview is definitely not the place where you need to restrain yourself (within adequate limits). Don’t be shy about selling yourself wisely and everything will work out.
Do you want even more useful material on systems analysis? I run a tg channel (Not)System analytics, where I talk about softs and hards. I'm waiting for everyone!
