When I first started recruiting in tech, I kept seeing the same pattern. Smart recruiters got stuck not because they could not learn the language, but because nobody had explained which parts of that language actually matter. They were handed job descriptions full of Python, React, APIs (ways software systems talk to each other), Kubernetes, SQL, and now LLMs (large language models), RAG (retrieval-augmented generation, where a system looks up information before answering), and agents (AI systems that can take actions or complete tasks), then expected to sound confident right away. That gap is why I wrote this guide.

I wrote it because most technical hiring does not break down on the hardest terms. It breaks down on the common ones. A recruiter hears JavaScript, Node.js, Spring (a Java framework for building applications), CI/CD (continuous integration and continuous delivery, the automated process for testing and shipping code), cloud (rented computing infrastructure and services), microservices, or pull requests and knows the words, but not always the recruiting signal behind them. The same thing is happening now with AI vocabulary. More teams talk about model APIs (ways applications connect to AI models), embeddings (numerical versions of text or content that capture meaning), inference (running a trained model to get an output), and AI literacy, but those terms can describe very different levels of work. If you cannot tell the difference, you cannot calibrate the role well.

So this guide stays close to real recruiting conversations. We start with the map you actually need, not trivia. Then we sort the building blocks: languages, frameworks, libraries, runtimes, and databases. We walk through how software gets built and shipped, from repositories and branches to testing, deployment, and release. We make infrastructure terms less mysterious by breaking down cloud, containers, microservices, serverless, and Kubernetes. We also connect tools to job families, including front-end, back-end, platform, data, ML, and AI engineering, so you can hear a term and place it in the right lane.

My goal is simple. By the end, you should be able to read a stack line with less guesswork, ask better follow-up questions in intake and screening calls, and stop treating every technical keyword as a separate skill. You do not need to pretend to be an engineer. You need a clearer working map. That is the idea behind this guide and the wider Tech Recruitment 101 series: practical explanations you can use immediately in the job.

What recruiters actually need to understand

You do not need to become an engineer to recruit engineers well. You need a working map. That map helps you tell what a team is building, where a role fits, and which experience matters. GitHub’s own hiring guidance makes the same point: recruiters do not need to be engineering experts, but they do need clear role calibration and shared expectations with hiring teams (GitHub ReadME Project: Hiring technical talent).

The mistake I see early-career recruiters make is treating technical terms like a spelling test. They memorize definitions and stack acronyms with no structure behind them. That creates fake fluency. You can repeat “Kubernetes,” “microservices,” and “CI/CD” and still have no idea whether the candidate matches the job.

Useful technical knowledge works differently. A term is a clue, not a fact to collect. “Python” may signal back-end engineering, data work, or machine learning. Stack Overflow’s 2025 Developer Survey shows Python usage rose to 57.9%, tied to AI, data science, and back-end work (Stack Overflow Developer Survey 2025). So if a manager says, “We need strong Python,” the next question is, “Python for what?”

The same rule applies to process terms. A candidate who mentions pull requests, branches, repositories, and code reviews is usually describing normal team workflow, not rare senior expertise. GitHub’s 2025 Octoverse report says developers merged 518.7 million pull requests in 2025 and made more than 986 million commits, which tells you these words describe mainstream software collaboration, not instant proof of level (GitHub Octoverse 2025).

Here is the frame I use.

Start with category. Is the term a programming language, a database, a front-end framework, a cloud platform, a delivery practice, or an AI concept? Then listen for depth. Did the person use it once, or build around it every week? Then decide whether it is core or incidental. A back-end engineer at a company with a React front end does not become a React engineer by standing near React.

AI makes this even more important. Stack Overflow’s 2025 survey found 81.4% of respondents used OpenAI GPT models for development work in the past year, yet more developers distrusted AI tool accuracy than trusted it, and only 3% reported high trust in AI output (Stack Overflow Developer Survey 2025). So “used LLMs” might mean deep product work with model APIs, retrieval, or evaluation. It might also mean they asked a chatbot for code and cleaned up the mess afterward.

This book will teach vocabulary, but not as trivia. We will tie each term to the hiring decisions it should change. After building recruiting teams a few times, I can tell you that confidence comes from knowing which follow-up question unlocks the real story.

The building blocks: languages, frameworks, libraries, and databases

Most recruiter confusion starts when different kinds of tools get listed in one line as if they were interchangeable. They are not. A programming language is what developers write in. A framework gives structure. A library solves a narrower problem inside that structure. A database stores and retrieves data. If you keep those buckets separate, job descriptions get much easier to read.

This matters because one stack line may say JavaScript, React, Node.js, PostgreSQL, and AWS. That does not mean five versions of the same skill. It means one language, one front-end library, one back-end runtime (the software layer that lets code run), one database, and one cloud platform. In the Stack Overflow Developer Survey 2025, JavaScript, SQL, and Python remain among the most commonly used technologies, which is a good reminder not to over-focus on obscure tools when the basics do most of the hiring work.

A programming language is the closest thing to a developer’s base skill. JavaScript, Python, Java, and C# are languages. When a candidate knows a language well, they can usually learn nearby tools faster. But the language alone rarely tells you the job family. Python can point to back-end work, data work, automation, or AI-related work. The surrounding tools tell you more.

A framework is a larger structure developers build inside. Spring is used with Java, often in enterprise back-end systems. .NET is a broad Microsoft ecosystem, and when someone says “I’m a .NET engineer,” they usually mean back-end or full-stack work in that stack.

A library is usually narrower. React is the example recruiters see most. Technically, React is a library for building user interfaces, though many teams treat it as the center of a front-end stack. For recruiting, the useful point is simpler: React usually signals front-end product work, not back-end or infrastructure depth.

Node.js trips recruiters up because it is not a language. Developers write JavaScript or TypeScript, and Node.js lets them run that code on the server. So a profile with JavaScript, React, and Node.js often points to a full-stack web engineer.

SQL needs special care because recruiters hear it in two ways. First, SQL means Structured Query Language, the language used to query relational databases. Second, people use “SQL” loosely to mean relational database work in general. If a job asks for SQL, read the rest of the stack. PostgreSQL, MySQL, SQL Server, and Oracle are databases. SQL is the language used to work with them.

A relational database stores structured business data in tables with defined relationships. A schema is the structure of that data. A query is a request for data. A data model is the higher-level design for how the information is organized.

NoSQL is the catch-all term for databases that do not work like classic relational systems. In practical recruiting terms, SQL databases fit structured business data well. NoSQL databases often show up when teams need flexibility, very high scale, fast key-value access, or document-style storage. MongoDB is a common document database example. Redis is often used for caching or fast lookups. Do not assume “NoSQL” means more advanced. It usually means a different trade-off.

The stack often hints at the kind of product a person has built. Java plus Spring plus SQL often points to enterprise back-end work. JavaScript plus React plus Node.js often points to web product teams. Python plus SQL still needs one more question.

When you screen, translate the stack into work, not buzzwords. Ask: did this person build user interfaces, server logic, or both? Did they mostly consume data, or design how data was stored? Did they work inside a mature enterprise stack or a fast-moving product environment? From my years doing this, separating the base language, the application layer, and the data layer is the fastest way to judge how close the match really is.

How software gets built and shipped

Once you can sort the building blocks, the next step is understanding the work chain around them. A lot of software terms make sense only when you line them up in order. That matters because a job brief may list half this chain, while the team needs real ownership in only one part.

A repository, or repo, is the shared home for a codebase. Version control tracks changes in that repo over time, and Git is the tool most teams use. A commit is one saved set of changes. A branch is a separate line of work, often for one feature or fix. These terms tell you the team works in a structured way, but not how senior someone is.

A pull request, or PR, is a request to merge one branch into another. Code review is where teammates check that change before it is merged. If a hiring manager says “strong PR habits,” ask what that means. Do they want someone who can work inside a normal review process, or someone who can set the standard for the team?

Testing sits in the middle of this workflow because teams do not want broken code moving downstream. A unit test checks one small piece of code in isolation. An integration test checks whether parts work together, such as an app talking to a database or external service.

An API, or application programming interface, is a defined way for one piece of software to talk to another. In plain English, it is a menu of allowed requests and expected responses. If a candidate built API integrations, ask whether they designed the API, consumed it, or maintained it. Those are different kinds of work.

An endpoint is one specific address in an API. A person who says they “worked on endpoints” likely handled practical back-end tasks such as request handling, validation, authentication, or response formatting.

An SDK, or software development kit, is a set of tools that helps developers use a platform or service. Teams may use an SDK for cloud services, payments, maps, or large language model tools. GitHub reports that more than 1.1 million public repositories now use an LLM SDK, which tells you that SDK work is no longer niche jargon (GitHub Octoverse 2025).

Once code passes review, automation usually takes over. A build turns source code into something runnable or deployable. Continuous Integration and Continuous Delivery, usually shortened to CI/CD, is the automated pipeline that runs checks and moves code toward release.

An environment is a place where software runs. Development is where engineers build and experiment. Staging is a pre-production environment. Production is the live environment users depend on. If a role owns production, the risk and responsibility are higher.

A deployment is the act of putting new code into an environment. A release is when that change becomes available to users. A rollback is the reversal step when a release causes problems. If a candidate talks about rollbacks, incident response, or production fixes at odd hours, they likely worked close to live systems. Nobody loves a rollback, but it is still better than pretending production is a feelings-based environment.

When a job brief throws all these terms at you, slow it down and ask where the real weight sits.

That one habit will save you from lazy matching. “Experience with CI/CD” may mean deep pipeline ownership, or it may mean the candidate knows how to work in a normal modern team.

Infrastructure without the mystery: cloud, containers, microservices, and Kubernetes

Infrastructure means the systems and setup that let software run reliably. Once the delivery flow is clear, infrastructure terms get less intimidating. Most of them describe where software runs, how teams package it, and how they keep it stable. You do not need deep engineering knowledge here either. You need to separate exposure from ownership.

A server is just a computer that runs software for other people or systems. If an app has users, data, logins, or payments, it runs somewhere. That “somewhere” may be a company’s own machines, or rented from a cloud provider.

Cloud means renting computing resources instead of owning the hardware. The three names you will hear most are AWS, Azure, and Google Cloud. In hiring, the important question is usually not “which cloud?” but “what did this person build or operate there?”

A candidate who says “worked with AWS” may mean almost anything. They may have deployed an application, managed permissions, set up monitoring, tuned costs, built data pipelines, or simply logged into the console once and looked nervous. Push for verbs. Ask what they deployed, migrated, automated, secured, or fixed.

The same rule helps with cloud resumes full of badges. AWS, Azure, and Google Cloud are platforms, not jobs. A back-end engineer may use cloud services to run an application. A DevOps engineer helps teams ship software reliably by connecting development work to operations, often through automation and delivery pipelines. Platform engineers build and maintain the internal systems and tools other engineers use. Site Reliability Engineers, or SREs, focus more on uptime, alerts, and incident response. The platform name matters less than the type of ownership.

Containers package software with what it needs to run, so it behaves the same way in different environments. Docker is the best-known container tool, so many people use “Docker” as shorthand for containers in general.

Kubernetes is a layer above containers. It manages many containers across many machines. It handles scheduling, scaling, restarts, service discovery, and rollout control. It usually means the company runs enough services or environments that manual container management became painful.

Recruiters often overread these terms. Docker is common. Kubernetes is common in larger or more complex environments. Neither proves depth by itself. A resume that lists Docker and Kubernetes tells you the candidate has likely been near modern infrastructure. It does not tell you whether they owned design decisions, handled production issues, or copied commands from an internal wiki with impressive confidence.

Use simple questions to test ownership. “What problem were containers solving for your team?” is better than “Explain Kubernetes architecture.” “How did you deploy services?” is better than “Which orchestration primitives did you use?”

Microservices need the same treatment. A microservices architecture breaks one large application into smaller services. When a hiring manager says “we need someone with microservices experience,” ask what they actually need: independent service design, distributed systems reliability, API integration, or high-scale operations.

Serverless is another term that sounds stranger than it is. It does not mean no servers exist. It means the cloud provider manages more of the server work for you. Developers write functions or services and pay based on usage. It is often useful for event-driven workloads, background jobs, and teams that want speed without managing much infrastructure.

A useful rule is to listen for the optimization goal behind the buzzword. Cloud may mean speed. Containers may mean consistency. Kubernetes may mean scale or standardization. Microservices may mean team autonomy or complex growth. Serverless may mean lower operational overhead.

When resumes are stuffed with infrastructure terms, separate proximity from ownership. “Used Kubernetes, Docker, AWS” suggests exposure. “Built CI/CD pipelines, handled production incidents, reduced cloud costs” suggests responsibility.

Roles, specialties, and where AI changes the vocabulary

Once you can read tools and workflows, the next step is attaching them to the kind of work they usually support. You do not need to memorize every term. You need to know which hiring lane it points to.

The core vocabulary is still stable. The Stack Overflow Developer Survey 2025 shows that the terms recruiters hear most often still cluster around JavaScript, HTML and CSS, SQL, and Python. Most intake meetings are not about exotic stacks. They are about common work done with common tools.

Front-end engineers build what users see and interact with. Terms like React, TypeScript, HTML, CSS, state management, and accessibility usually live here.

Back-end engineers build the systems behind the screen. Terms like APIs, databases, SQL, Java, C#, Python, Node.js, authentication, and microservices usually point here.

Full-stack engineers work across both sides. That does not mean they are equally deep in everything. Ask where they spend most of their time.

Mobile engineers build for phones and tablets. iOS often means Swift. Android often means Kotlin. React Native and Flutter usually signal cross-platform work.

DevOps engineers and platform engineers help teams ship software reliably. You will hear cloud, containers, Kubernetes, Terraform, CI/CD, and observability (the logs, metrics, and traces teams use to understand what a system is doing). SREs overlap with this world but focus more on uptime, incident response, and reliability under real load.

Data roles split into a few lanes. Data engineers move and prepare data. Data analysts use data to answer business questions. Data scientists build models and run analysis. The same term, especially Python, can point to different lanes. Stack Overflow notes Python rose sharply in 2025, tied to AI, data science, and back-end use, which is a useful reminder not to infer the job from the language alone (Stack Overflow Developer Survey 2025).

Security engineers protect systems, applications, and data. QA roles test software and prevent defects. Some QA work is manual. Some is automated. “SDET” means Software Development Engineer in Test, which usually signals stronger coding ability and test automation work.

AI changes the vocabulary, but it does not erase the old lanes. Many teams now use large language models, or LLMs, through an API without doing deep machine learning work. LinkedIn reported that AI engineering postings became a meaningful share of tech jobs in 2025, while AI literacy spread across mainstream titles like software engineer and architect (LinkedIn AI Labor Market Update, September 2025).

When you hear machine learning, think model training, feature pipelines, evaluation, and productionizing predictive systems. When you hear machine learning operations (MLOps), think the infrastructure around machine learning models: deployment, monitoring, versioning, reproducibility, and retraining. When you hear inference, think running a trained model to get an output. Fine-tuning means adapting an existing model on additional data for a narrower use case.

RAG means retrieval-augmented generation. In plain English, the system looks up relevant information first, then gives that information to the model before it answers. A vector database usually stores embeddings, which are numerical representations of meaning, for example by storing text in a way that helps the system find similar documents fast. Prompt engineering means designing inputs that help a model produce useful output, but by itself it is rarely a complete engineering role. If someone’s “AI experience” is mostly writing prompts in a tool, that is not the same as building AI products. Stack Overflow found developers use AI tools heavily, yet trust in AI output remains low, which is a good reminder that usage is not the same as expertise (Stack Overflow Developer Survey 2025).

Use intake questions to test whether the AI wording is real or decorative. Ask what the model actually does in the product. Ask whether the team trains models, fine-tunes models, or calls a model provider API. Ask what success looks like: latency, quality, cost, accuracy, or adoption.

After building recruiting teams a few times, I have found that role clarity beats jargon every time. You do not need to relearn the whole industry every quarter. You need to map terms to work.

Using the glossary in real recruiting conversations

A glossary helps only when it changes what you ask, what you write, and what you flag. Otherwise it is decorative trim on a job description.

In intake meetings, I treat technical terms as signals, not proof. If a manager says, “We need Kubernetes,” I do not stop at the noun. I ask what problem Kubernetes solves in this role. Are they running containerized applications at scale? Do they need someone to maintain infrastructure? Or did Kubernetes appear because it showed up in another team’s stack?

The same rule helps with common tools. A hiring manager may ask for React, SQL, Python, Docker, and AWS all in one breath. Your job is to sort capabilities from inventory. React may mean “build user interfaces.” SQL may mean “query production data safely.” Python may point to back-end work, data work, or AI-heavy work, depending on the team. That matters because the same word can point to very different talent pools.

When a term is broad, probe it. When a term is specific and low-risk, let it go. If a manager says “microservices,” ask whether the team needs someone to design distributed systems or simply work inside an existing service-based architecture. If they say “Git,” you usually do not need a ten-minute debate. Most engineers use repositories, branches, pull requests, and code review as normal workflow, and GitHub’s 2025 Octoverse data shows just how mainstream that language is in modern software teams GitHub Octoverse 2025.

This sharpens sourcing too. Good outreach does not recite every acronym in the spec like a hostage note. It names two or three terms that reflect the actual work. “I saw your background with React and API integrations” sounds informed. “We need React, Kubernetes, CI/CD, GraphQL, Kafka, Terraform, and ML” sounds like you lost a fight with a keyword parser.

In screening calls, your goal is not to test depth you do not have. It is to confirm fit, context, and level. Ask candidates where they used a term, what they owned, and how often they worked with it. “You mention CI/CD. Did you maintain the pipeline, troubleshoot it, or mainly use it?” is a strong recruiter question. “Explain how Jenkins agents handle parallelized builds” is not, unless you enjoy very long silences.

AI vocabulary needs the same discipline. Terms like LLM, RAG, embeddings, and agents show up more often because developers are using these tools in real projects. GitHub reports more than 1.1 million public repositories now import an LLM SDK, and LinkedIn reported AI engineering hiring growth above 25% year over year in 2025 GitHub Octoverse 2025 LinkedIn AI Labor Market Update, September 2025. But do not overread the label. Stack Overflow’s 2025 survey also found developers distrust AI tool accuracy more than they trust it, which is a useful reminder that “used AI” does not equal “built production-grade AI systems” Stack Overflow Developer Survey 2025.

The real skill is judgment. Probe when the term affects scope, seniority, or sourcing strategy. Let it go when it is standard background noise. Flag a mismatch when the manager asks for specialist depth but describes shallow day-to-day work, or when a candidate names a tool but cannot place it in context. Recruiting teams do not need fake fluency. They need level clarity and shared expectations, which is exactly what GitHub’s guidance on hiring technical talent stresses GitHub ReadME Project: Hiring technical talent.

A little accuracy goes much further than a lot of jargon. After building recruiting teams a few times, I can tell you this part gets easier because you stop chasing words and start listening for meaning.

The thread running through all of this is simple. Do not collect terms. Translate them. When you hear Python, ask what kind of work it supported. When you hear React, place it in front-end product work. When you hear CI/CD, Kubernetes, RAG, or agents, separate exposure from ownership. When you hear a crowded stack line, sort it into categories and decide what actually carries hiring weight. That shift is what turns technical vocabulary from something intimidating into something useful.

If you want a next step, use this guide in your next intake meeting or screen and force yourself to ask one better follow-up question than you asked last time. Not five. One. Ask what problem the tool solved, what the candidate owned, or whether the term is core to the role or just nearby. That habit will do more for your judgment than memorizing another list of definitions.

This guide is one part of the Tech Recruitment 101 series. The other books are built the same way: plain English, practical use, and enough structure to help you work with confidence. Read them the same way you should use this one. Take the idea, test it in a real conversation, and keep the parts that make you better at the job.

Glossary

• .NET — A Microsoft software development ecosystem commonly used for back-end and full-stack application development, often with C#.
• AI (Artificial Intelligence) — A broad term for systems that perform tasks that usually require human-like reasoning, prediction, or language understanding.
• AI Engineer — An engineer who builds products and features that use AI models, often including LLM-based applications in production.
• AI engineering — The work of building software products that use AI models in real applications.
• AI literacy — A practical understanding of how AI tools and concepts work well enough to use or discuss them effectively.
• Android — Google’s mobile operating system; in hiring, it usually refers to software development for Android apps.
• API (Application Programming Interface) — A defined way for one software system to interact with another through requests and responses.
• API integration — Connecting one application or service to another through APIs so data or functionality can be shared.
• applied ML — Practical machine learning work focused on using models in real products or business problems.
• architect — A senior technical role focused on system design, technology choices, and overall application or platform structure.
• authentication — The process of verifying who a user or system is before allowing access.
• automation — Using software or scripts to perform tasks automatically instead of manually.
• automated — Describes work or processes handled by software with minimal manual effort.
• AWS (Amazon Web Services) — A major cloud platform that provides rented computing infrastructure and related services.
• Azure — Microsoft’s cloud platform for running applications, storing data, and managing infrastructure.
• back-end — The server-side part of software that handles business logic, data processing, and system behavior behind the user interface.
• Back-end engineer — An engineer who builds and maintains server-side systems, APIs, and data-related application logic.
• branch — A separate line of work in version control, usually used for developing a feature or fix without affecting the main codebase.
• build — The process of turning source code into something runnable, testable, or deployable.
• C# — A programming language commonly used in Microsoft-based development, especially with .NET.
• caching — Storing frequently used data in a faster-access layer so systems can respond more quickly.
• candidate — In this text, often used in the context of technical interviews or profiles that describe engineering experience.
• chatbot — A software system that interacts with users through conversational text or voice, often powered by AI.
• CI/CD (Continuous Integration / Continuous Delivery) — Automated pipelines that test, build, and move code toward release.
• cloud — Rented computing infrastructure and services used to run applications without owning physical hardware.
• cloud platform — A provider environment, such as AWS or Azure, where teams run software and infrastructure services.
• cloud provider — A company that rents out infrastructure and services for computing, storage, networking, and more.
• code review — A process where teammates examine code changes before they are merged to check quality and correctness.
• codebase — The full collection of source code for an application or software system.
• commit — A saved set of code changes in version control.
• console — A management interface, often web-based or command-line, used to interact with software or cloud services.
• container — A packaged unit of software that includes the code and what it needs to run consistently across environments.
• containerized — Describes software that has been packaged into containers for more consistent deployment and operation.
• containers — Packaged software units that help applications run the same way across different systems and environments.
• cross-platform — Describes software built to run on more than one operating system or device platform.
• CSS (Cascading Style Sheets) — A language used to control the visual styling and layout of web pages.
• data analyst — A role focused on using data to answer business questions, often through reporting and analysis.
• data engineer — An engineer who builds and maintains systems that move, transform, and prepare data.
• data model — A higher-level design for how information is structured and related inside a system.
• data pipeline — A system or workflow that moves and processes data from one place to another.
• data science — A field that combines data analysis, modeling, and experimentation to extract insights or make predictions.
• data scientist — A role that uses data analysis and modeling to answer questions or build predictive systems.
• database — A system for storing, organizing, and retrieving data.
• delivery pipeline — An automated sequence of steps that helps move code from development through testing and toward release.
• deployment — The act of putting software into an environment where it can run.
• DevOps — A way of working that connects software development and operations to help teams ship and run software reliably.
• DevOps engineer — An engineer who helps teams build, deploy, and operate software through automation, infrastructure, and delivery practices.
• development — An environment or stage where engineers build and test software before release.
• distributed systems — Systems made up of multiple connected services or machines that work together.
• Docker — A widely used tool for creating and running containers.
• document database — A type of database that stores information in document-like formats rather than relational tables.
• embedding — A numerical representation of text or other content that captures meaning so systems can compare similarity.
• embeddings — Numerical representations of content used to help AI or search systems find related meaning.
• endpoint — A specific API address or route that handles a defined request.
• enterprise — In software hiring, usually refers to large-company systems, tools, and environments with more formal structure.
• environment — A place where software runs, such as development, staging, or production.
• evals — Short for evaluations; tests or methods used to measure how well an AI model performs.
• evaluation — The process of measuring model quality, system performance, or output usefulness.
• event-driven — Describes systems that react to events or triggers, such as messages, uploads, or user actions.
• external service — A service outside the main application that software connects to for added functionality or data.
• feature — A specific function or capability delivered in software.
• feature pipeline — The workflow used to create, manage, and prepare model input features for machine learning systems.
• fine-tuning — Adapting an existing AI model using additional data for a narrower task or use case.
• Flutter — A framework for building cross-platform mobile applications from a single codebase.
• flow_diagram — A structured visual representation of steps or process flow shown in the book’s diagrams.
• framework — A larger software structure developers build within, providing patterns and tools for application development.
• front end — The user-facing part of an application that people see and interact with.
• front-end — The user-interface side of software, typically built for browsers or apps that users directly interact with.
• Front-end engineer — An engineer who builds user interfaces and client-side application behavior.
• full-stack — Work that spans both front-end and back-end software development.
• Full-stack engineer — An engineer who works across both user-facing and server-side parts of an application.
• function — In this context, a unit of software logic, often used in programming or serverless systems.
• GCP — Short for Google Cloud Platform; Google’s cloud infrastructure and services offering.
• Git — A version control tool used to track code changes and collaborate on software development.
• GitHub — A platform for hosting code repositories and collaborating with Git-based workflows.
• Google Cloud — Google’s cloud platform for hosting applications, infrastructure, and data services.
• GraphQL — A query language and API technology that lets clients request specific data structures.
• HTML (HyperText Markup Language) — The standard markup language used to structure content on web pages.
• incident response — The work of identifying, handling, and recovering from production issues or outages.
• inference — Running a trained machine learning model to generate an output or prediction.
• infrastructure — The systems and setup that allow software to run, including servers, cloud services, networking, and related tools.
• infrastructure as code — Managing infrastructure through code files instead of manual setup, allowing repeatable changes and automation.
• integration test — A test that checks whether multiple parts of a system work together correctly.
• iOS — Apple’s mobile operating system; in hiring, it usually refers to software development for iPhone or iPad apps.
• Java — A programming language commonly used for back-end systems, especially in enterprise environments.
• Java framework — A framework used with the Java language to provide structure for building applications.
• JavaScript — A programming language widely used for web development on both the front end and, with runtimes like Node.js, the back end.
• Jenkins — A widely used automation server for building, testing, and deploying software.
• Kafka — A distributed event streaming platform often used for moving data between systems at scale.
• key-value — A simple data storage model that saves information as pairs of keys and values for fast lookup.
• Kotlin — A programming language commonly used for Android app development.
• Kubernetes — A system for managing containers across multiple machines, including scaling, restarts, and deployment control.
• language — In this context, a programming language developers use to write software.
• latency — The delay between a request and the system’s response.
• library — A reusable set of code that solves a narrower problem inside an application.
• LLM (Large Language Model) — An AI model trained on large amounts of text to generate or understand language.
• LLM SDK — A software development kit that helps developers connect applications to large language model services.
• log — A recorded software event or message used to understand what a system is doing.
• logs — Recorded system events and messages used for debugging, monitoring, and observability.
• machine learning — A field of AI where systems learn patterns from data to make predictions or generate outputs.
• manager — In this text, often a hiring or engineering manager providing technical requirements for a role.
• merged — In version control, combining changes from one branch into another.
• metrics — Quantitative measurements used to monitor system performance or behavior.
• microservices — An architecture where one large application is split into smaller independent services.
• mobile engineer — An engineer who builds software for mobile devices such as phones and tablets.
• model — In AI or machine learning, a system trained to produce predictions, classifications, or generated outputs.
• model API — An API that lets applications send requests to an AI model and receive outputs.
• model APIs — Interfaces applications use to connect to AI models.
• model provider API — An API supplied by a third-party AI provider so teams can use hosted models without training their own.
• MongoDB — A document-oriented NoSQL database often used for flexible data storage.
• MLOps (Machine Learning Operations) — The infrastructure and operational practices used to deploy, monitor, version, and maintain machine learning models.
• ML (Machine Learning) — A short form of machine learning.
• ML Engineer — An engineer who builds and maintains machine learning systems, pipelines, and production model workflows.
• monitoring — Tracking system behavior, health, and performance over time.
• MySQL — A relational database product that uses SQL.
• NoSQL — A broad category of databases that do not follow the classic relational model.
• Node.js — A runtime that lets developers run JavaScript or TypeScript code on the server.
• observability — The use of logs, metrics, and traces to understand how a system behaves internally.
• OpenAI GPT models — Large language models from OpenAI commonly used for text generation and other AI tasks.
• operations — The work involved in running, supporting, and maintaining software systems in live environments.
• Oracle — A relational database product often used in enterprise environments.
• orchestration — Coordinating and managing multiple software components or containers across systems.
• parallelized builds — Build processes that run multiple tasks at the same time to speed up software delivery.
• payments — In this context, payment-related systems or services integrated into software applications.
• pipeline — An automated or structured series of steps for building, testing, deploying, or processing software or data.
• platform — A technical foundation, environment, or set of services that other software or teams build on.
• platform engineer — An engineer who builds and maintains internal systems and tools that help other engineers work more efficiently.
• PostgreSQL — A relational database product commonly used in modern application development.
• PR (Pull Request) — A request to merge code changes from one branch into another for review.
• pre-production — A stage or environment used to test software before it goes live to users.
• prod — Short for production, the live environment used by real users.
• production — The live software environment that real users rely on.
• production-grade — Describes software built to run reliably in real, live environments.
• profile — In this context, a candidate’s resume or professional background summary that lists technical experience.
• programming language — A formal language developers use to write software instructions.
• prompt engineering — Designing prompts or inputs to help AI models produce more useful results.
• provider API — An external API offered by a third-party service provider.
• pull request — A proposed code change that asks teammates to review and merge it.
• Python — A programming language used across back-end engineering, data work, automation, and AI-related work.
• QA (Quality Assurance) — Work focused on testing software and preventing defects before release.
• query — A request for data from a database.
• query language — A language used to request and manipulate data in a database, such as SQL.
• RAG (Retrieval-Augmented Generation) — An AI approach where a system first retrieves relevant information, then gives it to the model before generating an answer.
• React — A library for building user interfaces, commonly associated with front-end web development.
• React engineer — A front-end-focused engineer whose work centers on building interfaces with React.
• React Native — A framework for building mobile apps using React and JavaScript or TypeScript.
• Redis — A fast data store often used for caching, queues, or quick lookups.
• release — The point when a software change becomes available to users.
• relational database — A database that stores structured data in tables with defined relationships.
• repo — Short for repository; the shared home for a project’s code.
• repositories — Shared locations where codebases are stored and versioned.
• repository — A storage location for a project’s code and change history.
• response formatting — Structuring system output in the expected format for an API or application response.
• retrieval — In AI systems, the step where relevant information is looked up before a response is generated.
• retrieval-augmented generation — See RAG; a method that combines information lookup with model generation.
• rollback — Reversing a deployment or release when a change causes problems.
• role calibration — Aligning on what a technical role actually requires in terms of scope, depth, and expectations.
• rollout control — Managing how software changes are introduced, often gradually or with safeguards.
• runtime — The software layer or environment that allows code to execute.
• schema — The defined structure of data in a database.
• screen — In this context, an early-stage recruiter conversation used to assess fit and clarify experience.
• SDK (Software Development Kit) — A packaged set of tools and code that helps developers use a platform or service.
• search — In this context, technology used to find relevant documents, data, or results, often important in AI and retrieval systems.
• security engineer — An engineer who protects applications, systems, and data from security risks.
• server — A computer or system that runs software for users or other systems.
• server logic — The application logic that runs on the back end rather than in the user interface.
• server-side — Software that runs on a server rather than on the user’s device or browser.
• serverless — A cloud model where the provider manages more of the infrastructure so developers can focus on code and usage-based execution.
• service — A software component that performs a specific function, often as part of a larger system.
• service-based architecture — A system design where software is divided into separate services.
• service discovery — A way for services in a distributed system to find and communicate with each other.
• software engineer — A broad engineering role focused on building and maintaining software applications or services.
• Software Development Engineer in Test (SDET) — A QA-oriented role that usually combines software development skills with test automation work.
• software development kit — See SDK; a toolkit that helps developers build with a platform or service.
• source code — The human-readable code developers write to create software.
• spec — Short for specification; a written description of role or product requirements.
• Spring — A Java framework commonly used to build back-end and enterprise applications.
• SQL (Structured Query Language) — The language used to query and work with relational databases.
• SQL Server — A relational database product from Microsoft.
• SRE (Site Reliability Engineer) — An engineer focused on keeping systems reliable in production, including uptime, alerts, and incident response.
• SREs — Plural form of Site Reliability Engineers.
• staging — A pre-production environment used to test software before release.
• stack — The set of technologies used to build and run a software product.
• stack line — A short list of technologies in a job description or profile that summarizes a team’s technical stack.
• state management — Techniques and tools for controlling how application data changes over time, especially in front-end development.
• storage — The systems or services used to save and retrieve data.
• Structured Query Language — The full name of SQL, the standard language for working with relational databases.
• Swift — A programming language commonly used for iOS app development.
• system — In this context, software or connected software components that work together to perform tasks.
• Terraform — A tool for defining and managing infrastructure as code.
• test automation — Using software to run tests automatically instead of manually.
• test strategy — The overall plan for how software will be tested and quality will be checked.
• tool — In this context, a software product or utility used to build, test, deploy, or operate systems.
• traces — Observability data that shows how requests move through parts of a system.
• trained model — A machine learning model that has already learned patterns from data and is ready to produce outputs.
• training — In machine learning, the process of teaching a model using data.
• TypeScript — A programming language based on JavaScript that adds static typing and is commonly used in web development.
• unit test — A test that checks one small piece of code on its own.
• uptime — The amount of time a system stays available and working.
• user interface — The part of software users directly see and interact with.
• validation — Checking whether incoming data or inputs meet expected rules before processing.
• vector database — A database designed to store and search vector embeddings efficiently, often used in AI retrieval systems.
• vector embeddings — Numerical representations stored for similarity search, usually in AI systems.
• version control — A system for tracking code changes over time and supporting collaboration.
• web engineer — An engineer focused on building web-based applications, often across front-end and back-end work.
• workflow — The sequence of steps a team follows to build, review, test, and release software.