Both are heap-backed and grow by allocating, so they reintroduce exactly the dynamic-allocation problems we avoid in C: heap fragmentation (variable-size alloc/free leaves gaps until a request fails despite sufficient total free memory, with no OS to compact), non-deterministic allocation timing that breaks WCET guarantees, and fatal, unrecoverable exhaustion with no virtual memory or OOM killer. A push_back can trigger a reallocation at an unpredictable moment in a real-time path. The fixes keep the container abstraction but bound capacity at compile time: std::array<T, N> for fixed-size storage, a templated fixed-capacity RingBuffer<T, N>, or a library like the ETL (Embedded Template Library) that offers STL-style vector/string/map with compile-time capacity and zero heap use. So the concern isn't "STL is bad", it's specifically the allocating containers; plenty of STL (std::array, many <algorithm> functions, std::span) is fine.
C++ for Embedded · Interview question
A teammate uses std::vector and std::string in firmware. What's your concern?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
What to Avoid on MCUs
The three C++ features that cost more than they're worth on a microcontroller (exceptions, RTTI, and dynamic allocation): why they hurt, and the deterministic patterns to use instead.