Software Tester / QA (Junior)
Required knowledge.
For a junior software tester (QA), the scope of necessary knowledge differs from that of typical programming roles. Here, the key lies in the fundamentals of testing and quality assurance. A junior tester should be familiar with:
The testing process – Understanding that testing is not just "clicking through the app," but a structured process involving planning, test case preparation, execution, and reporting. The candidate should know terms like test plan, test case, test scenario, and bug report.
**Basic terminology **– It's important to know the definitions and differences between test types (functional vs non-functional, regression, exploratory testing, etc.) as well as testing levels (unit, integration, system, acceptance). For example, you might be asked to differentiate between manual and automated testing, or to list types of tests (smoke, ad hoc, security, etc.).
Bug lifecycle – What happens from the moment a bug is found until it's fixed: reporting, triage, fixing, retesting, closure. A tester should know how to write a proper bug report: description, reproduction steps, expected vs actual result, bug priority/severity, environment version.
Basic IT knowledge – Even though manual testers don't write much code, they should understand the technical context. A general understanding of software development methodologies (Agile/Scrum vs Waterfall), the tester’s role in the team, and tools like JIRA (for bug tracking) is helpful. Basic SQL (e.g., running a simple SELECT query) and HTTP/API knowledge is increasingly valued—testing APIs or using tools like Postman is a common part of the job.
Test automation (basics) – Even if you're applying for a manual tester position, questions about automation may come up, as the industry is heading in that direction. It's good to at least know what Selenium/WebDriver is, the purpose of unit tests (written by developers), and what Continuous Integration (CI) means from a QA perspective. If you've taken any automation courses (e.g., Python or Java basics for test automation), be sure to mention it. However, coding is not a main requirement for manual testers—it’s a “nice to have.”
Attention to quality and detail – A tester must be curious and detail-oriented. A recruiter might test your observation skills and approach to detail by asking how you'd test a simple feature (like a login field). This requires implicit knowledge—e.g., testing different paths (correct data, incorrect data, empty fields, special characters), validating error messages, checking security (password masking). Analytical thinking often separates good candidates from average ones.
Soft skills in a QA context – Recruiters place high value on communication and collaboration when hiring testers. Testers work closely with developers and managers, and their reports often influence key product decisions. That’s why the ability to communicate clearly, ask good questions, and be assertive (e.g., defending a bug the developer downplays) is assessed just as much as technical knowledge.
In summary, focus on testing theory and the practical aspects of a tester’s work. An ISTQB Foundation certificate isn’t required, but its syllabus is a solid table of contents for what you should know. It's also worth understanding the domain in which the company operates—for instance, testing banking apps differs from testing games. Show that you grasp the industry context (e.g., precision is key in finance, user experience in gaming).
Sample technical questions In a QA interview, you’ll likely face a mix of theoretical and scenario-based questions. Here are some examples you might encounter:
What are the types of tests, and how do they differ from testing levels? – Candidates often confuse these terms. A correct answer might be: Test types (in terms of purpose) include functional, non-functional, structural, and change-related (e.g., regression, retesting). Testing levels (in terms of scope) include unit, integration, system, and acceptance testing.
What is the difference between verification and validation? – Verification checks whether the product is built correctly (doing the thing right), while validation checks whether the correct product is being built (meeting user requirements). A classic software quality question.
What is exploratory testing and when is it used? – You should be able to explain that it’s an unscripted type of testing where test scenarios are created on the fly while exploring the system. The goal is to discover unexpected paths and defects. In other words, the tester interacts with the app without a strict step-by-step script and documents findings in real time.
What should a bug report include? – This tests your practical knowledge. The answer should include elements of a good bug report: a unique title, clear description, reproduction steps, expected vs actual result, environment details (app version, device), attachments (e.g., screenshots). Also mention setting the bug’s priority and severity.
Is a tester responsible for product quality? – This is a tricky, reflective question. A good answer might be: “To some extent yes, but not solely.” A tester helps detect bugs and provide quality insights, but the entire team is responsible for the product’s quality. You could say: "A tester provides information about quality, but isn’t the only one making release decisions."
SQL or API-related questions: For example, “Which SQL query would you use to check how many records meet a specific condition?” – SELECT COUNT(*) FROM ... WHERE ... would suffice. Or “How would you test a REST API service without a user interface?” – Answer: by using Postman or curl, sending a GET/POST request, and verifying the response code and body.
Test scenarios: You might be asked something like, “You have a calendar app—how would you test adding an event?” In that case, list various scenarios: adding valid data, edge cases (e.g., very long event title, past date), missing required fields, conflicts (two events at the same time), permissions (whether another user can see my event), etc. A logical approach is key—start with positive cases, then move to negative and boundary cases.
As you can see, the questions can be quite descriptive. Some companies, instead of asking questions, may give you a mini practical test: for example, they might give you a printout of an interface and ask you to “list as many bugs as you can find on it” or ask you to test a simple test application live. That’s why it’s crucial to practice thinking like a tester — not just memorizing definitions.
Recommended learning sources. Here are some ideas on where to get knowledge when preparing to become a tester:
ISTQB Foundation Level Syllabus: Even if you’re not taking the certification exam now, it’s worth downloading the syllabus (available for free, also in Polish) and studying the concepts in it. It’s a theory capsule on testing — perfect for ensuring you understand terms (such as functional/non-functional tests, test design techniques, etc.).
Books on testing: A classic is Testing Computer Software (Kaner, English), or the Polish Zawód Tester (R. Smilgin) — the latter is accessible and set in the context of the Polish market. You can also check Certyfikowany Tester ISTQB. Podstawy (M. Łukasiewicz) if you aim for thorough preparation.
Courses and testing blogs: There are many free beginner testing courses online — e.g., on Udemy you can often find “Software Testing for Beginners.” Worth checking Polish sites like testerzy.pl (a portal on testing with articles on testing techniques) or blogs by experienced testers (e.g., Jakub Paczkowski, Remigiusz Bednarczyk — you’ll find posts on how to start). On YouTube, look for recordings of testing meetups — there’s a lot on channels like WrotQA or test:fest.
Practice on your own: Although building a tester portfolio is hard, you can practice testing on available applications. Pick any web app (e.g., a simple online store, blog) or mobile app and try to list ten potential bugs or improvements. You can even write bug reports for 2-3 defects you find. This exercise will help you build observation and documentation skills.
Tools: If you have time, familiarize yourself with basics of tools testers use: e.g., JIRA (issue tracker) — there is a free version, you can create an account and see what a bug report form looks like. Also get to know Postman (API testing tool) and Selenium IDE (a simple browser test recorder — even if you don’t use it, it gives you an idea how UI test automation works).
Tester community: Visit forums like Testerzy.pl, join Facebook groups (“Testowanie Oprogramowania,” etc.) where beginners ask questions and share experiences. Often other juniors share what questions they got at interviews — priceless knowledge! Also look for online testing events — many are free.
Common candidate mistakes (QA). Some frequent mistakes candidates make during tester recruitment:
Too theoretical approach: Some juniors memorize ISTQB textbooks and answer every question with a dry definition. That’s not necessarily wrong, but recruiters might feel you lack practical insight. Try to back every definition with a real (even hypothetical) example. For instance, when talking about integration tests, say “for example, I’d connect the login module with password reset and check their interaction.”
Lack of attention to detail during the interview: Paradoxically, a tester who is careless (mixes terms, can’t organize answers) might raise doubts. Try to be precise — practice answering in complete, clear sentences. If you get a live testing task, take brief notes so you don’t miss anything when discussing results.
Negative attitude toward developers: Sometimes candidates (especially career changers from non-tech jobs) emphasize that “a tester is the one who points out bugs to developers.” This “quality police” attitude isn’t well seen. Better present yourself as a partner delivering quality — someone who collaborates with devs to jointly deliver a good product. Avoid suggesting you’ll compete with developers — emphasize cooperation.
Lack of confidence / overconfidence: This is a balance to find. If you have some experience (courses, university projects), talk about it — highlight your strengths. Don’t undersell yourself (“I’m just learning, others are better…”), as it may discourage. On the other hand, don’t be arrogant — admit you have gaps and want to learn. Recruiters like candidates confident in their abilities but open to learning.
Lying or misleading: Applies to any job, but worth repeating — don’t lie. If you say in your CV “SQL – intermediate,” be sure someone will check. Better honestly say “I know basics, learning more” than get caught. Trust is crucial, especially for testers reporting on product quality. No one hires a dishonest or evasive candidate.
Lack of company knowledge: Tester should show curiosity — also about potential employer. If asked “What do you know about our company/product?” and you can’t say anything, it reveals lack of preparation. Common candidate mistake overall. Solution: always read about the company before the interview, consider what quality challenges the product might have. You can even mention you tried their app and have some observations (but be careful — phrase diplomatically to avoid sounding critical).
No questions at the end: Like in other roles, if candidate has no questions for the recruiter, it signals lack of engagement or preparation. As a future tester, you can ask e.g., “How big is the testing team and do you work with any methodology (Scrum/Kanban)?”, “What kinds of tests are mostly manual vs automated here?”, or about tools used (JIRA, test management, CI). It shows you think concretely about your role.
Practical tips. A few practical pointers for tester candidates:
Train tester thinking: In everyday life, start noticing “errors” in the systems around you. Using a mobile app? Think about what you would test. Found a typo on a website? How would you report it? Such habits will become second nature and make it easier for you to switch into problem-finding mode during an interview. You can also play with non-functional testing: for example, check the performance of a website (does it load quickly?) or usability (is it easy to find the information you need?). This will show in the interview that you are passionate about software quality.
Prepare examples from your experience: If you switched careers and have completed a course project, talk about how you tested your own project (even if you programmed it yourself, you might have checked its correctness). Or if in a previous job in another field you cared about quality (e.g., quality control in a factory, customer service where accuracy mattered), highlight it as analogous experience. It’s important to show you have a natural inclination for spotting errors and improving things.
Demonstrate reporting skills: You can prepare (for yourself) a sample bug report, e.g., based on some open-source project. When asked “Can you write a bug report?” you can say yes and briefly describe its structure. You can also mention that you practiced writing reports for your own purposes — this shows initiative.
Stay calm during a testing task: If the interview includes live testing (e.g., you get a web app to check within 5 minutes), the key is to be systematic. Don’t blindly click everything. Instead, say your plan out loud: for example, “First, I will go through the main path of adding an item to the cart, then check an edge case with an empty cart, and finally try to enter invalid data in the order form.” This organization will impress. Take quick notes so you don’t forget anything, and after the test, present your findings logically. If you didn’t have time to check something, say so — honesty and professionalism come first.
Emphasize communication and teamwork: In your answers, weave in elements that show you understand the tester’s role in a team. For example, if asked about a difficult situation, you might say hypothetically: “When a developer says ‘It works on my machine,’ I first calmly verify if we tested on the same environment or if there’s a data difference. I try never to confront, but rather work together to find the cause of the bug.” Showing you can maintain good communication and have a “us vs. the bug” mindset (not “tester vs. dev”) is a big plus.
Attitude towards continuous learning: You may be asked how you plan to grow as a tester. It’s worth mentioning that you plan, for example, to learn the basics of automation or that you’re interested in some performance testing tool. You don’t need to know it yet, but showing willingness to learn is key. Testers should be curious about new techniques and tools — employers value self-driven learners. If you read blogs or books on testing, talk about it (just make sure you’ve actually read something so you can comment).
DevOps (Junior)
Knowledge scope: The DevOps Engineer role is quite specific — it combines development and administrative knowledge. From a junior DevOps, a broad orientation in many IT areas is expected, mostly at a basic but solid level. Here are the key ones:
Operating systems (Linux): Almost every DevOps role requires knowledge of the Linux environment. You need to be comfortable in the terminal — basic commands (file system navigation, file and directory manipulation, permissions, processes). Questions might include how to check the machine’s IP address, find a process by port number, use grep, or explain the difference between a process and a thread. Linux is one of the most frequently required skills in DevOps job listings.
Networking: Understanding the basics of computer networks is crucial. Know the OSI model at a general level and protocols like TCP/IP, UDP — their differences and characteristics. Specifics: DNS (what it’s for, what A/CNAME records are, TTL), HTTP/HTTPS (response codes, headers, differences between GET and POST), FTP/SSH (basic use, ports). You might be asked: “What is DHCP and what is it used for?” or “List main HTTP methods and when to use them.” As a DevOps, you’ll often diagnose network issues, so understanding ping, traceroute, NAT, firewall is very useful.
Databases: Not as deeply as backend devs, but DevOps should know the difference between relational and NoSQL databases, how to do backups and restores, what replication and sharding mean. DevOps often helps manage databases from an infrastructure perspective, so questions like “How to back up a MySQL database?” may come up.
Scripting languages: Automating tasks is core to DevOps. You’ll need at least basic bash scripting and often one higher-level scripting language (Python, Go, Ruby — usually Python). A junior DevOps doesn’t need to be an application developer but should be able to write, e.g., a bash script to monitor logs or a simple Python script to move files. Questions can be practical: “How to write a loop in bash?” “How to import a library and install dependencies in Python?” You might get a mini task to write code (FizzBuzz in bash is a classic).
Containerization and virtualization: Very popular areas, it’s important to understand their essence. Virtualization means creating a virtual machine with its own OS by a hypervisor. Containers (Docker) are lightweight isolated environments using the host system’s kernel. Know the difference between containers and VMs, basic Docker commands (build, run, stop, Dockerfile basics). A common question: “Can containers run inside virtual machines and why?” (Answer: yes, it’s common — containers and VMs are complementary technologies). Kubernetes at the junior level is usually not required in depth, but it’s good to know the concept of container orchestration and mention you’ve heard about K8s, even if you haven’t used it.
• CI/CD (Continuous Integration/Continuous Deployment): DevOps often manages CI/CD pipelines. It’s good to know what Jenkins, GitLab CI, GitHub Actions are—at least one of these tools in theory. You might be asked something like: “What is a CI/CD pipeline and why is it used?” — answer that it automates the process of building, testing, and deploying applications, enabling faster and more frequent releases. A possible question: “How would you design a pipeline for application X?” — here, just logically describe the steps: build, run tests, deploy to test environment, etc.
• Version Control Systems: Like in other roles, Git is the standard. As a DevOps, you might be kind of the “repository guardian,” so it’s good to understand concepts like commit, branch, merge, rebase, tag, conflict. Quick questions may include: “What’s the difference between merge and rebase?” or “How do you undo the last commit that’s already been pushed?”
• Monitoring and Logging: Basics of system monitoring—e.g., do you know which server metrics are important to monitor (CPU, RAM, I/O, request count, etc.), and examples of tools (Prometheus, Zabbix, Grafana — just names are enough). Logging — why centralized logging (ELK stack: Elasticsearch+Logstash+Kibana or Graylog) is useful. They usually don’t dig deep here unless you mention you’ve actually used something.
• Security Basics: DevOps also touches security: concepts like SSH (public/private keys), encryption (TLS), managing passwords and secrets (e.g., don’t store passwords in plaintext in pipelines). You might get asked: “Is it okay to store user passwords in plaintext in the database?” (Of course not — you must hash them, e.g., with bcrypt). Or “Which is more secure by default: containers or VMs?” — the goal is to spark a discussion (containers share the host kernel, so have higher risk of escape, VMs provide better isolation — but it’s a complex topic).
• Cloud: More and more companies use AWS/Azure/GCP. A junior DevOps doesn’t need certifications, but it’s good to know basic cloud services: that EC2 (virtual servers) and S3 (storage) exist, that cloud billing is pay-as-you-go, and understand advantages of cloud vs on-prem (scalability, no need for own infrastructure). Often asked: “Name three main cloud providers” (AWS, Azure, GCP). If the job ad requires “basic AWS,” be ready to say what EC2, RDS, maybe Lambda are — at least briefly.
• DevOps Mindset: This is a soft but important point — do you understand the idea of DevOps (collaboration between dev and ops, automating everything possible, improving the release process). You might not get asked directly “What is DevOps?” but it’s good to show you understand that your goal is to improve the team’s work, not just admin for the sake of admin. Different companies define the role differently — try to feel whether they want more of a developer writing CI/CD scripts or an admin managing infrastructure.
Phew, that’s a lot 😊. Junior DevOps is demanding because of the breadth of knowledge. Don’t panic—you don’t have to be an expert in every point above. Your task is to show solid basics and ability to learn quickly. If you don’t know a term (e.g., “Terraform,” “Kubernetes”), say honestly you haven’t had a chance to use it yet but you know what it’s for and want to learn. It’s important to have the fundamentals mastered — without that, it’ll be hard to pass a technical interview.
Sample Technical Questions: DevOps interviews can be very diverse—from theoretical control questions, through practical tasks (e.g., write a script), to architectural discussions. Here are some junior-level example questions:
What’s the difference between a virtual machine and a container? — explain that VM emulates entire hardware and guest OS, while a container shares the host kernel, isolating processes. Containers are lighter (less resource-heavy), VMs more isolated.
What is a CI/CD pipeline and what benefits does it bring to a project? — answer that it’s a set of automated steps (Continuous Integration/Continuous Deployment) enabling frequent and reliable app updates. The pipeline builds code, tests it, and deploys it, minimizing human errors and speeding up releases. You can mention a tool you know (e.g., “I configured a simple pipeline in GitLab CI for building a Node.js app”).
Name monitoring tools you know. — e.g., Prometheus + Grafana, Zabbix, NewRelic, Datadog — no need for details, just to check if you understand monitoring is for tracking system performance and stability.
What’s the difference between TCP and UDP protocols? — TCP establishes a connection (handshake), guarantees packet delivery and order, is stateful; UDP is connectionless, faster but unreliable. You can add which apps use each (TCP — HTTP, UDP — video streaming, DNS).
How to check on Linux which process listens on a given port? — correct answer: use lsof -i :port_number or netstat -tulpn | grep port. This checks your Linux practical skills.
What is DNS and what role does it play? — Domain Name System translates textual domain names to IP addresses; uses port 53 (UDP, sometimes TCP).
How does the Linux boot process work? — harder question, usually for more experienced; worth knowing buzzwords: BIOS/UEFI → bootloader (GRUB) → kernel → init/systemd (service startup).
Which version control systems do you know and why use them? — just say Git (probably the only one you really used) and maybe SVN as older, used for tracking code changes and collaboration.
(Git) What’s the difference between merge and rebase? — merge joins branches preserving commit history with a merge commit; rebase “rewrites” history by applying commits on top of another branch, creating a linear history.
(CI) What is a pipeline (in CI/CD context)? — a set of CI/CD tasks, e.g., Jenkins job or a .yml file in GitLab CI defining build/test/deploy phases.
Have you worked with cloud (AWS/Azure/GCP)? — if yes, prepare for questions like “what is EC2/S3/VPC” (if AWS) or generally “What’s more cost-effective: own infrastructure or cloud?” There’s no single answer — you can say cloud reduces admin overhead and allows scaling, but own infra might be cheaper at constant high load. This checks your reasoning and knowledge of pros and cons.
Remember, in DevOps thinking matters more than memorizing. You might get tricky or deliberately wrong questions (to test if you notice). They might ask about your experience: “Tell me about the hardest technical problem you solved.” Prepare a story, even from personal projects (“I had an issue configuring nginx for multiple domains — learned about virtual hosts then”). Showing passion and problem-solving ability is key.
Recommended Learning Sources: DevOps is broad, but the community shares lots of knowledge. Here are useful types of resources:
Official tool docs: Docker, Kubernetes, Ansible, Azure/AWS docs — often long but well-structured. Start with intro/tutorials, e.g. “Docker Get Started” for container basics.
Interactive labs: Great are interactive scenarios like Katacoda (now part of O’Reilly) — lets you practice “running first pods in Kubernetes,” “setting up CI server” in browser. Also Linux Survival or OverTheWire (Bandit) — console games teaching Linux and security. Practice helps you learn quickly.
DevOps blogs and case studies: Read others’ experiences — e.g., blog DevOpsiarz.pl with recruitment tips and guides, No Fluff Jobs posts for junior DevOps. Helps to understand focus areas.
Community and open source: Join groups like “DevOps Polska” on Facebook or Slack/Discord (Polish and English communities). There you find course recommendations, Q&A, expert advice. Also play with open source: clone GitHub repos of DevOps tools, run locally to see how they work.
Certifications (optional): Some consider AWS Certified Cloud Practitioner or Linux Foundation SysAdmin. Certs don’t teach you per se but help organize knowledge. If you have time and budget, consider it, but not mandatory at start. Understanding topics and research skills matter more.
Online courses: Platforms like Udemy have “Complete DevOps Bootcamp” courses covering Docker, CI, cloud, etc. Make sure the course is up-to-date because tools change fast. On YouTube, channels like “TechWorld with Nana” explain Kubernetes, Terraform, etc., with great visuals in English. Roadmap.sh has a “DevOps Roadmap,” an interactive tech list to check your knowledge gaps.
Typical mistakes of DevOps candidates. When starting as a junior DevOps, watch out for these pitfalls:
Listing tons of tools without practical knowledge: Sometimes candidates stuff their CVs with everything they’ve heard of (“Docker, K8s, Ansible, Terraform, AWS, GCP…”), but then can’t answer simple questions about them. This tactic doesn’t work — recruiters prefer someone who knows fewer things but well. It’s better to say “I haven’t worked with technology X” than to bluff. Also, questions can be tricky — they might ask about a non-existent technology (to see if you admit you don’t know or start improvising). Admitting lack of knowledge is no shame — pretending to know something can get you disqualified.
Gaps in fundamentals (so-called “clicking around in the cloud without understanding”): If you learned AWS by clicking in the web console but don’t understand what’s happening behind the scenes, you’re at a disadvantage. For example, someone might be able to click “Deploy to Cloud” from a template but can’t explain how DNS works or what an IP address is. A DevOps must understand the basics — build your knowledge from the ground up. Especially networking and operating systems — no shortcuts here, you need to master these.
Inability to search for information: This might not come out directly during the interview, but if you get an open question like “What would you do if the app runs slow in production?”, the recruiter expects to see your thought process on how you’d find the root cause. Shooting one answer (“the server is definitely too weak”) is a mistake — better to show you’d analyze various possible causes, check metrics, logs, etc. Show that you know how to learn and diagnose — because as a DevOps you’ll constantly be learning new things.
Neglecting security issues: If the conversation turns to security (e.g., access management, encryption, backups), be careful not to say something that shows recklessness. For example, “I keep passwords in Evernote” — bad answer 😉. It’s better to admit you know security is important and rules must be followed (you don’t need to know them all, but awareness is crucial). If asked “Is it okay to do X” (e.g., store passwords in plaintext) and you say you see no problem, that’s a serious minus.
Overconfidence or technological rigidity: You might know one tool very well (e.g., Docker inside out) and want to shine. But be careful not to come across as a know-it-all — show your skills but also openness. For example, if the company uses a different CI system than you know, say: “I haven’t worked with X, but I know the principles of CI, so I’ll pick it up quickly — after all, tools serve the same purpose.” Avoid absolute statements like “only Kubernetes makes sense, the rest is outdated” — you don’t yet know the company’s context well.
Lack of preparation for English interviews: Many companies require English (documentation, international teams). Often part of the technical interview is in English. A common mistake is huge stress at this moment. If you know your English might be tested, practice talking about yourself and technical topics in English beforehand. Make flashcards with key terms (e.g., load balancer, outage, pipeline, script). This will boost your confidence if asked: “Could you describe how DNS works, in English?”
Practical advice. How to approach a junior DevOps interview:
Show your DIY projects: In DevOps, “passion for technology” is highly valued. If you’ve hobbyist experience setting up a game server, your own blog on a VPS, playing with Raspberry Pi — mention it. For example, “I set up my own NAS server on Raspberry Pi at home and automated photo backups” or “I configured a GitHub Actions pipeline to automatically build my project.” These small things show initiative and passion, which often outweigh formal junior experience.
Prepare for practical tasks: You may be asked to write a simple script (bash/Python), analyze a config, or solve a logic problem. For example, you might get an nginx config snippet with an error and be asked what’s wrong — so review sample nginx/Apache configs beforehand. For scripts, practice writing bash scripts that read a file and output unique lines, or loop printing numbers 1–10. You might get “write deploy.sh to copy files to server and restart service” — you don’t need exact environment knowledge, pseudocode with scp and systemctl is fine. Show you can think in automation terms.
Think aloud when diagnosing a problem: If asked hypothetically, “Imagine a new app version stopped working after deployment — what do you do?”, don’t throw one answer immediately. Instead say: “I’d first check monitoring — is CPU or memory usage up? Then look at app and system logs. If nothing there, I’d try rolling back to the previous version for comparison. Maybe it’s a dependency issue — I’d also check server configuration.” This methodical approach impresses and shows maturity. Remember — DevOps often has to troubleshoot calmly and narrow down problems step by step.
Emphasize DevOps culture (collaboration): You might be asked about teamwork experience. If you have a group project (e.g., at university), talk about how you divided tasks, if you used git. Highlight that you like helping others tech-wise (“In my previous role I was the go-to IT person even though it wasn’t my main task — I enjoy supporting others and improving the team’s workflow”). DevOps philosophy is about breaking silos, so showing you don’t have a “that’s not my job” mindset but rather “I like helping and improving team work” is a big plus.
Mind formalities and transparency: You may be asked about availability (are you ready for on-call duty? Usually juniors won’t be immediately on call but consider your answer). They might ask your preferred working environment (Linux/Windows — obviously Linux 😉). Be honest. If you don’t know something technically, admit it — this is often a test to see if you can admit ignorance (in this industry no one knows everything, that’s valued). As said earlier — liars get a firm no.
Show that you care: At the end of the interview, ask questions that prove your engagement. For example: “What are the company’s near-term plans for infrastructure modernization? Is there a chance to learn Kubernetes if you don’t use it yet?” — this signals forward thinking. Or ask the senior DevOps (if present) about their biggest challenge in the company — this shows genuine interest in the real work, not just the job. These talks are also your chance to evaluate the company, so don’t be afraid to ask.