Top 60 C Interview Questions (2026)

C is a compiled, statically typed, general-purpose language designed by Dennis Ritchie in the early 1970s. It's small and close to the hardware: manual memory management, pointers, and direct access to raw memory addresses.

It stays relevant because it produces fast native code with a tiny runtime, which is exactly what operating systems, device drivers, embedded firmware, and language runtimes need. When performance and control matter more than convenience, C is often the floor everything else sits on.

C is compiled, not interpreted. Source code is translated ahead of time into native machine code that runs directly on the CPU, so there's no interpreter sitting between your program and the hardware at run time. That's a big reason C is fast and produces standalone binaries.

The build runs in stages: preprocessing (expands #include and #define), compilation (C to assembly), assembly (assembly to object code), and linking (object files plus libraries into one executable). Knowing the stages helps you read errors: a preprocessor error, a compile error, and a linker error each point at a different phase.

The core types are char, int, float, and double, each with sizes that depend on the platform rather than being fixed by the standard. Modifiers change them: short and long adjust size, signed and unsigned adjust range, and const and volatile adjust behavior.

The standard only guarantees minimum sizes and relationships (a long is at least as wide as an int), which is why portable code uses fixed-width types from stdint.h like int32_t when the exact width matters.

A pointer is a variable that stores a memory address, the location of another variable, rather than a value itself. You declare one with a star (int *p), take an address with &, and read through it with * (dereferencing).

Pointers are why C is fast and dangerous at once: they let you pass large data cheaply, build linked structures, and touch memory directly, but a wrong address is undefined behavior. Almost every hard C interview question eventually comes back to pointers.

An array is a fixed block of contiguous elements with its size known to the compiler; a pointer is a variable holding one address. They feel similar because an array name decays to a pointer to its first element in most expressions.

The differences show where the array type is kept: sizeof(arr) gives the whole array's bytes while sizeof(ptr) gives the pointer's size, and you can reassign a pointer but not an array name. Passing an array to a function passes a pointer, which is why the callee can't know the length.

C is always pass-by-value: a function receives a copy of each argument, so changing a parameter never changes the caller's variable. There's no true pass-by-reference in C.

You simulate reference semantics by passing a pointer: the pointer is still copied, but it copies an address, so the function can dereference it and modify the original. That's why swap functions take pointers.

Format specifiers tell printf and scanf how to interpret each argument: %d for int, %f for float and double in printf, %c for char, %s for a string, %p for a pointer, and %u for unsigned.

They matter because C doesn't check them against the argument types at run time. A mismatch, like %d for a double, is undefined behavior, not a friendly error. In scanf you also pass addresses (&x), a spot beginners forget.

Precedence decides which operator binds first (multiplication before addition), and associativity breaks ties between operators of equal precedence (most are left to right, assignment is right to left).

You don't memorize the whole table. You reach for parentheses when intent isn't obvious, because a wrong assumption here produces bugs the compiler won't flag, like *p++ which increments the pointer, not the value.

The four storage classes are auto, register, static, and extern. They set a variable's lifetime (how long it lives) and linkage (where its name is visible).

auto is the default for locals (lifetime is the block). static gives a variable program lifetime and, at file scope, internal linkage. extern declares a name defined elsewhere. register is a hint to keep a variable in a CPU register, largely ignored by modern compilers.

const marks something as read-only after its initialization, so the compiler rejects any attempt to modify it. It documents your intent to callers and catches accidental writes at compile time rather than letting them corrupt data at run time. It's a safety and communication tool, not a performance one.

With pointers, position changes meaning: const int *p is a pointer to a constant int (you can't change the value through p), while int *const p is a constant pointer (you can't repoint p). Reading declarations right to left makes this clear.

C has for, while, and do-while. Use for when the iteration count or range is known up front, while when you loop until a condition changes, and do-while when the body must run at least once before the test.

do-while checks its condition at the bottom, so it always executes once. That's the distinction interviewers probe: menu prompts and input validation are the natural do-while cases.

An array is a contiguous block of same-type elements. Indexing arr[i] is defined as *(arr + i): the compiler adds i element-widths to the base address, so index 0 is the first element.

C does no bounds checking. Reading or writing past the end is undefined behavior, one of the most common sources of crashes and security bugs, so you track lengths yourself.

A C string is a char array ending in a null terminator, the byte '\0'. There's no separate string type and no stored length; functions like strlen walk the array until they hit the null byte.

This is why buffers must have room for the terminator (a 5-character string needs 6 bytes), why forgetting the null byte causes reads to run off the end, and why repeatedly calling strlen in a loop is a hidden O(n) cost each time. String bugs in C are almost always terminator or length bugs.

A prototype declares a function's name, return type, and parameter types before its use, without the body. It lets the compiler check calls for the right argument types and count.

Without a prototype, an older compiler would assume the wrong types and produce silent bugs; modern C requires the declaration to be in scope. Prototypes usually live in header files so many source files can call the function.

sizeof yields the size in bytes of a type or object, evaluated at compile time. sizeof(char) is 1 by definition, and every other size is measured in units of char.

It's an operator, not a function, so the compiler computes it without running code and its operand isn't evaluated: sizeof(x++) doesn't increment x. Use it to size allocations (malloc(n * sizeof(int))) and to count array elements portably.

#include <stdio.h> searches the standard system include paths first; #include "myheader.h" searches the current directory (or the file's directory) first, then falls back to the system paths.

So angle brackets are for library headers and quotes are for your own project headers. Both just paste the file's text in during preprocessing.

typedef creates an alias for an existing type. It doesn't make a new type; it gives an existing one a shorter or clearer name, which helps most with structs and function pointers.

typedef struct { ... } Point; lets you write Point instead of struct Point everywhere. Overusing it to hide pointers (typedef int *IntPtr) is discouraged because it obscures that a value is a pointer.

Pre-increment (++i) increments i first, then the expression takes the new value. Post-increment (i++) yields the old value first, then increments. Both change i by one when used alone.

The difference only matters when the result is used in a larger expression. Chaining side effects on one variable in a single statement (i = i++ + 1) is undefined behavior, so keep increments simple.

&& and || are logical operators that yield 0 or 1 and short-circuit: the right side is skipped when the left already decides the result. & and | are bitwise: they combine every bit of both operands and never short-circuit.

The bug this prevents is real: if (p != NULL && p->x) is safe because && stops before dereferencing a null pointer, while & would evaluate both sides and crash.

A null pointer is a pointer set to NULL, a value guaranteed not to point at any object. It's a defined, checkable state: you test if (p == NULL). An uninitialized pointer holds whatever garbage was in its memory, so it might point anywhere.

The practical rule: initialize pointers, ideally to NULL, and check before dereferencing. Dereferencing NULL is a clean crash; dereferencing garbage is unpredictable corruption, which is far worse to debug.

The stack holds automatic variables and function call frames; it's fast, managed for you, and freed automatically when a function returns, but it's small and its size is fixed. The heap is a larger pool you allocate from by hand with malloc and release with free.

The trade-off drives design: stack memory is effortless but short-lived and limited, so returning a pointer to a local is a bug. Heap memory outlives the function and can be large, but every allocation is your responsibility to free.

malloc(n) allocates n bytes, uninitialized. calloc(count, size) allocates and zero-initializes, and it also guards against multiplication overflow. realloc(ptr, n) resizes a block, possibly moving it and copying the old contents. free(ptr) returns a block to the allocator.

Two things bite people: always check the return for NULL, and with realloc, assign to a temporary first, because if it fails you'd otherwise lose the original pointer and leak it.

A memory leak is heap memory that's allocated but never freed and no longer reachable, so it stays reserved until the program exits. In a long-running process, leaks grow until it runs out of memory.

Prevent them by pairing every malloc with exactly one free, freeing on every exit path (including error returns), setting freed pointers to NULL, and running tools like Valgrind or AddressSanitizer that report leaks and use-after-free.

A dangling pointer points to memory that's already been freed or has gone out of scope. The pointer still holds the old address, but the memory it names is no longer valid, so using it is undefined behavior.

Common causes: using a pointer after free, returning the address of a local variable, or keeping a pointer into a block that realloc moved. The habit that prevents it is setting pointers to NULL right after freeing.

Adding an integer to a pointer moves it by that many elements, not bytes: p + 1 advances by sizeof(*p). Subtracting two pointers into the same array yields the number of elements between them.

That's why array indexing and pointer walking are equivalent. Arithmetic is only defined within one array (plus one past the end); going further, or mixing pointers from different objects, is undefined behavior.

A double pointer (int **pp) holds the address of a pointer. You need one when a function must modify a caller's pointer, not just the value it points to, for example allocating memory and handing the pointer back through a parameter.

The same idea underlies arrays of strings (char **argv) and dynamically built 2D arrays. The rule is consistent: to let a function change something in the caller, pass a pointer to that something, and a pointer's address is a double pointer.

A struct groups related variables of possibly different types into one unit. You access members with the dot operator on a struct value (s.field) and the arrow operator through a pointer (p->field, shorthand for (*p).field).

Structs are how C builds records: a point, a linked-list node, a network packet. Passing a large struct by value copies the whole thing, so functions usually take a pointer to a struct instead.

A struct gives every member its own storage, so its size is at least the sum of its members. A union overlays all members in the same storage, so its size is that of its largest member and only one member holds a valid value at a time.

Unions save memory and model tagged variants (a value that's an int or a float depending on a separate tag field). Reading a union member you didn't last write is a portability hazard, so keep a tag alongside it.

The compiler inserts unused bytes between struct members so each one lands on an address its type prefers (alignment). This keeps memory access fast and, on some hardware, valid at all.

The effect is that sizeof(struct) can exceed the sum of member sizes, and member order changes the total. Ordering fields from largest to smallest usually minimizes padding, which matters for large arrays of structs or wire formats.

A function pointer stores the address of a function, so you can call it indirectly and pass behavior around as data. The declaration mirrors the function's signature: int (*op)(int, int) points at any function taking two ints and returning an int.

They power callbacks (qsort's comparator), dispatch tables that replace long switch statements, and plugin-style designs. typedef makes their gnarly syntax readable.

Macros are text substitution done before compilation. Object-like macros (#define MAX 100) replace a token; function-like macros (#define SQ(x) ((x)*(x))) take arguments and paste them in. The compiler never sees the macro name.

The pitfalls are all about substitution without type checking: forgetting to parenthesize arguments and the whole body causes precedence bugs, and passing an expression with side effects (SQ(i++)) evaluates it twice. For anything nontrivial, an inline function is safer.

Inside a function, static makes a local variable persist across calls: it's initialized once and keeps its value, though its scope stays local. At file scope, static gives a variable or function internal linkage, so it's private to that translation unit.

So static means 'persistent' for locals and 'file-private' for globals and functions. Both uses reduce surprises: state that survives calls, and helpers that don't leak into the global namespace.

volatile tells the compiler that a variable can change outside the program's normal flow, so it must not cache the value in a register or optimize away reads and writes. Every access goes to actual memory.

It matters for memory-mapped hardware registers, variables shared with an interrupt handler, and flags set by a signal. It's about visibility of changes, not thread safety: volatile does not provide atomicity or ordering, which is a common misconception.

An enum defines a set of named integer constants, improving readability over bare numbers. By default the first is 0 and each next one increments, but you can assign explicit values.

Under the hood an enum is an integer type, so enum values are ints and can be used in switch statements, array indices, and arithmetic. That integer nature is both convenient and a weakness: nothing stops an out-of-range value from being assigned.

Use a mask made by shifting 1 to the bit's position. Set a bit with OR (x |= 1 << n), clear it with AND of the inverted mask (x &= ~(1 << n)), and test it with AND (x & (1 << n)).

Bit manipulation is everyday work in embedded code, flags, and permissions. Toggling uses XOR (x ^= 1 << n). Keeping these four idioms sharp is expected in any C role that touches hardware or protocols.

strcpy and strcat write until they hit a null terminator with no idea of the destination's size, so a source longer than the buffer overflows it. Buffer overflows corrupt memory and are a classic security vulnerability.

Use the length-bounded versions: strncpy, strncat, or better snprintf, which take a size limit. Even strncpy has a sharp edge (it may not null-terminate on truncation), so many teams standardize on snprintf for building strings safely.

main can be declared int main(int argc, char *argv[]). argc is the argument count including the program name, and argv is an array of string pointers; argv[0] is the program name and argv[argc] is NULL.

Arguments arrive as strings, so numbers need parsing with atoi or the safer strtol. This is the standard entry point for any tool that takes options or file paths.

Each recursive call pushes a new stack frame holding that call's parameters and locals. The frames unwind as calls return. Recursion is natural for problems that break into smaller versions of themselves, like tree traversal.

The risks are stack overflow when recursion goes too deep (no base case, or a huge input) and the per-call overhead. C compilers may optimize tail calls but don't guarantee it, so deep recursion is often rewritten as a loop.

Open a file with fopen, which returns a FILE pointer or NULL on failure. Read and write with fscanf, fprintf, fgets, fread, and fwrite, then The closing step is fclose. Always check the fopen return before using the handle.

Choose the mode carefully: "r" read, "w" truncates or creates, "a" appends, and add "b" for binary on platforms that distinguish it. Forgetting fclose can lose buffered writes, since output is buffered until flush or close.

C stores multidimensional arrays in row-major order: all of row 0, then all of row 1, contiguous in memory. So arr[i][j] sits at offset i * cols + j from the base.

When you pass a 2D array to a function, every dimension except the first must be known so the compiler can compute offsets: void f(int a[][COLS], int rows). Iterating in row-major order (outer loop rows, inner loop columns) is also friendlier to the cache.

Undefined behavior is any operation the C standard leaves with no requirements at all: the compiler may do anything, including work fine today and break after an optimization or compiler upgrade. Examples include dereferencing NULL, signed integer overflow, out-of-bounds access, and use after free.

It matters because compilers optimize assuming UB never happens, so UB can delete your safety checks or reorder code in surprising ways. The senior habit is to treat 'it worked' as no evidence of correctness and to compile with warnings, sanitizers, and defined-behavior discipline.

Unsigned arithmetic is defined to wrap modulo 2 to the power of the width, so 0xFFFFFFFF + 1 is 0. Signed overflow is undefined, which lets the compiler assume x + 1 > x always holds and optimize loops and bounds checks accordingly.

The practical consequence is that relying on signed wraparound is a real bug even when it seems to work, and a check like if (x + 1 < x) to detect overflow can be optimized away entirely. Use unsigned types or explicit overflow checks (or builtins like __builtin_add_overflow) instead.

A typical process image has several segments: text (the read-only machine code), the data segment (initialized globals and statics), the BSS (zero-initialized globals and statics), the heap (grows up as you malloc), and the stack (grows down with function calls).

Knowing this explains real behavior: why globals default to zero (BSS), why a large local array can overflow the stack, why the heap fragments, and why writing to a string literal crashes (it lives in read-only memory).

restrict is a promise from you to the compiler that, for the lifetime of a restrict-qualified pointer, the object it points to is accessed only through that pointer. It rules out aliasing, so the compiler can keep values in registers and reorder loads and stores safely.

It's mainly a performance tool in hot numeric code, like memcpy-style loops, where aliasing would otherwise force conservative reloads. Break the promise (pass overlapping pointers) and you get undefined behavior, so use it only when you can guarantee no overlap.

Strict aliasing says the compiler may assume that pointers of incompatible types don't point to the same memory (char pointers are the exception, they may alias anything). This lets it cache values across writes through unrelated pointer types.

The trap is type-punning by casting, say reading a float's bits through an int pointer, which violates the rule and is undefined behavior even though it often appears to work. The defined ways to reinterpret bits are memcpy or a union.

An inline function is a real function: it has types, a scope, and evaluates each argument once, so it avoids the double-evaluation and precedence traps of macros while still hinting that the body can be pasted at the call site.

The keyword is a hint, not a command; the compiler decides based on its own heuristics and may inline without the keyword or ignore it with it. For performance-critical small helpers, inline functions are the modern replacement for function-like macros.

const correctness means marking every pointer parameter the function won't modify as const (const char *src). It documents the contract, lets callers pass const data, and lets the compiler catch accidental writes.

In a public API it's part of the interface: a function taking const char * promises not to mutate the input, so callers can pass string literals and shared buffers safely. Retrofitting const later tends to ripple through call sites, so senior C code applies it up front.

Alignment is the requirement that a type's address be a multiple of its alignment (often its size), because CPUs read aligned data faster and some architectures fault on misaligned access. The compiler aligns variables and pads structs to satisfy it.

It matters when you cast raw bytes to a typed pointer (deserializing a network buffer), use SIMD types that need stronger alignment, or interface with hardware. _Alignas and aligned allocation control it; assuming a char buffer is suitably aligned for an int is a portability bug.

volatile only stops the compiler from caching a value; it provides no atomicity and no ordering between threads, so a volatile int shared across threads still has data races and torn reads. It was never a concurrency primitive.

C11 added <stdatomic.h>: _Atomic types and atomic operations with defined memory orderings, plus real synchronization from the threads library or the platform. For shared mutable state across threads, use atomics or a mutex, and reserve volatile for hardware registers and signal handlers.

Writing past a buffer's end overwrites adjacent memory. On the stack that can include the saved return address, letting an attacker redirect execution; on the heap it can corrupt allocator metadata. Unbounded copies (gets, strcpy) and off-by-one loops are the usual entry points.

Defenses layer up: bounded functions (snprintf, fgets), validating lengths, compiler and OS protections (stack canaries, ASLR, non-executable stacks), and testing with AddressSanitizer and fuzzing. The mindset is that any input length is adversarial until checked.

A declaration introduces a name and its type (extern int x; or a function prototype); a definition also allocates storage or provides the body. You can declare a name many times but define it once, the one-definition rule.

The compiler handles one translation unit at a time and leaves external references unresolved; the linker matches each reference to its single definition across object files and libraries. 'Undefined reference' means a definition is missing; 'multiple definition' means the one-definition rule was broken, often a variable defined in a header.

Endianness is the byte order a platform uses to store a multibyte value. Little-endian stores the least significant byte first (x86, most ARM), big-endian stores the most significant byte first (network byte order, some older systems).

It matters at boundaries: reading binary files, network protocols, or memory shared between different machines. Within one machine it's invisible. The fix is to serialize with a defined order using htons, htonl, and their inverses, rather than casting raw memory.

A flexible array member is an array of unspecified length declared as the last member of a struct (int data[];). It lets you allocate a header and its variable-length payload in a single block, sizing the allocation to hold the struct plus the elements.

This beats storing a separate pointer: one allocation, one free, better locality, and no second indirection. It's the standard C99 pattern for variable-length records like packets or strings-with-metadata.

Static linking copies the library code into your executable at build time: one self-contained binary, larger on disk, and no runtime dependency. Dynamic linking resolves shared libraries at load time (or later): smaller binaries, shared memory pages across processes, and updates without relinking.

The trade-offs are deployment versus flexibility. Static avoids the 'missing .so' problem and version skew; dynamic saves space, lets the OS patch a shared library once, and is what most systems default to. Containers have pushed some teams back toward static for reproducibility.

setjmp saves the current execution context into a jmp_buf and returns 0; a later longjmp restores it, causing setjmp to appear to return again with a nonzero value. It's a nonlocal jump, used for a crude form of exception handling across function boundaries.

The dangers are real: it bypasses normal stack unwinding so no cleanup runs, local variables not marked volatile can hold indeterminate values after a longjmp, and jumping into an already-returned function is undefined. Most code should prefer error return codes; setjmp is a last resort.

Levels like -O0 through -O3 and -Os trade compile time and code size for speed. -O0 keeps code close to the source for debugging; higher levels reorder, inline, unroll, and eliminate dead code aggressively.

Optimizers assume your program has no undefined behavior, so latent UB (uninitialized reads, strict-aliasing violations, signed overflow) that seemed harmless at -O0 can produce different, wrong results at -O2. When a bug appears only with optimization on, suspect UB first, not the compiler.

The standard approach is void pointers plus an element size, the way qsort works: the container stores raw bytes, copies elements by size with memcpy, and takes function pointers for operations like comparison or freeing. The caller casts back to the real type on retrieval.

The costs are lost type safety (mistakes surface at run time, not compile time) and an extra indirection. Alternatives are code-generating macros (X-macros or a header included per type) that trade readability for type safety. Naming both approaches and their trade-offs is The production-ready answer.

Reproduce with instrumentation first: rebuild with -g and sanitizers (AddressSanitizer for memory errors, UBSan for undefined behavior), which usually pinpoints the exact line for use-after-free, overflow, or a bad pointer. If it only happens live, capture a core dump and open it in gdb to read the crashing stack.

Intermittency points at uninitialized memory, a race, or input-dependent overflow, so widen the input set and run under Valgrind. The structure matters more than any tool: reproduce, instrument, isolate the faulting access, fix, and confirm the fix under the same sanitizer.

C++ adds classes, templates, RAII, references, function and operator overloading, exceptions, and a large standard library on top of C. Most C code compiles as C++, but not all: C++ is stricter about implicit conversions (notably void* to a typed pointer needs a cast) and treats some C idioms as errors.

The mindset shift is memory management: C is manual malloc/free, while idiomatic C++ ties resource lifetime to object scope with RAII and smart pointers. Bringing C habits (raw new/delete, C-style casts) into C++ is what usually trips experienced C developers.

A memory barrier (fence) constrains the order in which memory operations become visible, preventing the compiler and CPU from reordering loads and stores across it. Modern hardware and optimizers reorder freely for speed, which is fine for single-threaded code but breaks shared-memory assumptions.

In lock-free code you need the right ordering so that, for example, a flag is only seen as set after the data it guards is written. C11 atomics expose this through memory orders (acquire, release, seq_cst); getting them wrong produces bugs that appear only under load on certain CPUs, which is why most code uses locks unless lock-free is truly required.