cswork / libraryOpen practice workspace

Interview guides · Ayes - Management & Technology Consulting

Ayes - Management & Technology Consulting Software Engineer Interview Guide

Ayes - Management & Technology Consulting Software Engineer interview guide: HR, Business Manager and Client rounds, C++ and Yocto questions, 7-day plan.

The 60-second brief

Ayes - Management & Technology Consulting is a technical consultancy. Candidates describe client work in Automotive, Aerospace & Defense, Rail, Energy and Industrial Automation, where the Software Engineer role centres on C++ for embedded Linux platforms. The responsibilities candidates describe are developing and tuning C++ modules on Linux, defining software architecture, working with CMake and the Yocto framework, writing specifications and architecture diagrams, reviewing code, running unit and system integration tests, and debugging. The work is done alongside hardware engineers, systems integrators and client project leads, and the engineer also gives internal Business Managers technical input on whether a project is feasible. Because placement depends on a client project, the loop checks both engineering skill and readiness to join a client team.

This guide is for engineers applying as a Software Engineer at Ayes - Management & Technology Consulting, from fresh graduates presenting a thesis to engineers with industry experience. It covers the three reported rounds (HR Screening, Business Manager Interview, Client Interview), the C++, Linux, build-system, debugging and testing questions candidates report, the motivation and logistics questions, and how to rehearse the English portions out loud.

Candidates report three rounds in this order: HR Screening, Business Manager Interview and Client Interview, over roughly 3-5 weeks. Timing between stages shifts with the availability of client projects.

Focus areas

  • English language proficiency
  • Project description & communication
  • Technical interview preparation

Overview

The reported questions fall into three groups. The first is your background: your academic path, the engineering choices behind a master's thesis or university project, and the tools, compilers and frameworks you used. The second is systems work: C++ memory management and smart pointers, building a custom embedded Linux image with Yocto, debugging race conditions and deadlocks, bringing Qt or Boost into a CMake build, and keeping quality up through unit testing and system validation. The third is professional fit: a short conversation in English, how you handle shifting scope or tight client deadlines, your mobility, and your salary and notice period. A candidate who prepares only the technical group will be caught out by the other two, and the reverse is also true.

Candidates describe live coding as less common than project walkthroughs and detailed questions about design choices, debugging strategy and code. That changes how you practise. Instead of grinding algorithm puzzles, be able to explain your own code and decisions at the level of ownership, threads, build configuration and failure modes. Whatever you claim on your CV is fair ground for a follow-up, so list only tools you can discuss in detail: if Yocto appears on it, be ready to describe layers, recipes and the image build, not only to say you ran bitbake.

The loop is also a matching process. Candidates report that the HR call covers salary expectations, location and sector preferences, and that those answers are used to pair you with client engagements. Settle your position on relocation, notice period and preferred sectors (Automotive, Rail, Aerospace and so on) before the first call, and keep it the same in every round. Then use the Business Manager round to rehearse the client round: a thesis or project story that names the problem, your own contribution, the tools and the result is the same story a client technical lead will want to hear, only with more depth on the technical decisions.

The Ayes - Management & Technology Consulting interview process

Candidates describe three stages, moving from an HR conversation to an internal technical interview and then to an interview with the client company. The order below is the reported sequence.

HR Screening

Candidates describe the first stage as a call that goes through your resume, your academic or professional background, your salary expectations and your location constraints, and includes a short spoken check of your English. It is reported as non-technical, so the work is to make your story short, consistent and easy to match to a client engagement. Practise answering aloud in English, including small-talk topics such as hobbies or a recent holiday, because the language check is conversational rather than technical.

What to demonstrate

  • How clearly you present your background and your reasons for choosing consulting over a product company
  • Whether your salary, notice period, relocation and sector preferences are workable for client placements
  • Conversational English in an unscripted exchange

How to prepare

  • Write a spoken summary of your CV in English, and in Italian too if the loop's tips apply to you, covering study, projects and the sector you want
  • Settle your answers on salary expectations, notice period and short-term versus long-term relocation, and say the same thing in every round
  • Practise the hobbies-or-vacation prompt aloud in English until it comes out as plain sentences without technical jargon
  • Prepare a specific reason for choosing a consulting firm, tied to variety of client domains, and a believable answer on where you want to be in three to five years

Business Manager Interview

Candidates describe this stage as an in-depth conversation with an internal Business Manager or senior engineering lead. It is reported to cover your technical competencies, your university thesis or past project deliverables, the tools you have mastered, your target industrial sectors, and a review of your CV in the Ayes format. Treat it as a project walkthrough with technical depth: for each item on your CV you should be able to say what the problem was, what you personally built, which tools and compiler setup you used and what the outcome was.

What to demonstrate

  • Depth of your C++ and Linux knowledge, as shown through your own thesis or project
  • Whether you can explain engineering choices and tools in a structured way
  • Sector interests and how they fit the client work on offer

How to prepare

  • Build a one-page inventory of tools (compilers, debuggers, build systems, frameworks, version control) with one concrete example of using each
  • Rehearse the thesis or project walkthrough as problem, your contribution, tools, result, and have a reason ready for each major design decision
  • Prepare crisp answers on smart pointers and RAII, the Yocto image workflow, and how you debug races, deadlocks and leaks, since these are the reported technical themes
  • Check that every claim in your CV is one you can defend with an example, and cut the ones you cannot

Client Interview

Candidates describe the final stage as an interview with the client company, where technical leads from the client side test the specific technical requirements of the project. It is reported as assessing domain readiness, problem-solving and fit for the client's engineering team. Preparation here is project-specific: learn what you can about the target sector and platform, review the C++, Linux and build topics that project is likely to touch, and be ready to talk about how you work inside someone else's team and process.

What to demonstrate

  • Readiness for the client's specific technical requirements and domain
  • Problem-solving and debugging approach on embedded Linux and C++ topics
  • Fit with a client engineering team, including handling changing scope and deadlines

How to prepare

  • Walk through a leak hunt and a race or deadlock hunt out loud, naming the tools you would use on a Linux target and what each shows
  • Practise the CMake answer for bringing in Qt or Boost, including finding the package, imported targets and cross-compilation
  • Prepare a story about requirements changing mid-project and how it changed your architecture and your communication with stakeholders
  • Write questions to ask the client's team about the target hardware, operating system, toolchain and testing process

Where candidates lose points

Describing the thesis or project as a list of tools and results without saying what you personally decided or built

Structure it as problem, your contribution, tools and result. Prepare two or three specific design decisions, each with the alternative you rejected and why, so any follow-up has a concrete answer.

Answering the smart-pointer question with textbook definitions that never touch embedded constraints

Cover unique_ptr for exclusive ownership, shared_ptr and its reference count, weak_ptr to break cycles, and RAII wrappers or custom deleters for file descriptors, mapped memory and device handles. Add what changes on a constrained target, such as limiting allocation after start-up and avoiding shared ownership where one owner will do.

Describing the Yocto workflow as running one build command, with no mention of layers, recipes or the image definition

Walk the sequence: fetch the build system and the board's BSP layer, initialise the build environment, set the machine and layers in the configuration, add your own layer with recipes or bbappend files, add packages to an image recipe, run bitbake, then locate and flash the produced image. Be ready to say where you would change a package version or patch.

Debugging a race or deadlock by guessing and adding sleeps or prints

Name a method: reproduce under load, run ThreadSanitizer or Helgrind for races, take stack traces of all threads in gdb for a hang, check lock acquisition order, and fix by consistent ordering or scoped locking. For a leak on a Linux target, mention LeakSanitizer or valgrind and watching memory growth over time.

Giving vague or inconsistent answers on salary, notice period, relocation or English small talk

Decide your range, notice period and mobility limits before the HR call and repeat them unchanged in later rounds. Rehearse the hobbies-or-vacation answer aloud in English in plain sentences, since it is reported as a spontaneous check.

Questions & practice

"What specific development tools, compilers, and software frameworks did you utilize in your recent technical

Medium · Background & Academic Experience

"What specific development tools, compilers, and software frameworks did you utilize in your recent technical assignments?"

Approach

  1. Answer by category and give a use for every tool. Compiler: GCC or Clang, plus any cross toolchain such as an arm-linux-gnueabihf GCC. Build: CMake generating Make or Ninja. Debugging: gdb, and gdbserver for remote targets. Version control: Git. Editor: VS Code or similar.
  2. Mention analysis tools only if you actually ran them: Valgrind memcheck, AddressSanitizer or ThreadSanitizer via -fsanitize, and static checkers such as clang-tidy or cppcheck. Say what each one found for you.
  3. Be ready to explain cross-compiling. The host builds for a different target architecture using a sysroot. In CMake, the toolchain is selected with a toolchain file passed through CMAKE_TOOLCHAIN_FILE.
  4. Know your build flags: -Wall -Wextra (optionally -Werror), -g for symbols, -O0 versus -O2. Know how CMAKE_BUILD_TYPE Debug and Release change them, because a bug that only shows up with optimisation is a common follow-up.
  5. Name the frameworks you used (Qt, Boost, GoogleTest, a middleware) and what they did in the project. Listing tools you cannot discuss one level deeper weakens the answer.

Follow-up

  • How did you debug code running on the embedded target rather than on the host?
  • What changes between a Debug and a Release build, and when did that difference bite you?
  • Which compiler warnings would you turn into errors on a new project, and why?

"How do you approach modern C++ memory management, and how do smart pointers prevent resource leaks in embedde

Medium · Systems & Technical Execution

"How do you approach modern C++ memory management, and how do smart pointers prevent resource leaks in embedded software?"

Approach

  1. Start from RAII. A resource is acquired in a constructor and released in the destructor. Destructors run on every scope exit, including stack unwinding after an exception, so no code path can skip the release. Prefer the rule of zero, and avoid raw new and delete.
  2. unique_ptr means sole ownership. It is move-only, and with the default deleter it is typically the size of a raw pointer. A custom deleter lets it manage C handles, e.g. std::unique_ptr<FILE, decltype(&fclose)>. Use std::make_unique.
  3. shared_ptr means shared ownership through an atomic reference count stored in a control block. std::make_shared allocates object and block together. Cycles never reach zero and leak, so one side of a back-reference should be a weak_ptr.
  4. Embedded concerns: heap allocation can be non-deterministic and can fragment a long-running process. I would allocate at start-up, use fixed-capacity containers such as std::array or memory pools, and keep allocation off real-time paths. RAII still applies when exceptions are disabled.
  5. State the limits. Smart pointers do not catch cycles, objects kept alive by a long-lived owner, or leaks inside C libraries. I confirm with Valgrind memcheck or LeakSanitizer (part of AddressSanitizer) on the Linux target or an equivalent build.

Follow-up

  • When would you choose shared_ptr over unique_ptr, and what does it cost at runtime?
  • How would you wrap a file descriptor, a mutex lock or a hardware handle with RAII?
  • How would you isolate a memory leak in a C++ application running on an embedded Linux target?

"Could you briefly describe your personal hobbies or recent vacation plans in English?"

Medium · Professional Fit & Language Skills

Approach

  1. Candidates report spontaneous English checks, so prepare two or three personal topics (a hobby, a recent trip, upcoming plans) with concrete details: where, with whom, and what you enjoyed or learnt.
  2. Get the tenses right. Past simple for a finished trip ("I went to ..."), present perfect for experience ("I have played ... for years"), and "I'm going to" or present continuous for plans.
  3. Keep sentences short and finish them. If a word is missing, paraphrase ("the place where you rent boats") instead of stopping or switching language.
  4. Practise aloud and record yourself, then practise the switch from small talk to technical English. Explaining your thesis or last project in English is the natural next prompt.
  5. Do not recite a memorised script. Answer the question actually asked and leave room for follow-up questions.

Follow-up

  • What did you enjoy most about it, and would you do it again?
  • Now can you describe your most recent technical project in English?
  • How did that hobby start, and what has it taught you?

"What are your geographic mobility preferences, and are you open to short-term or long-term relocation for cli

Medium · Professional Fit & Language Skills

"What are your geographic mobility preferences, and are you open to short-term or long-term relocation for client engagements?"

Approach

  1. Give clear boundaries instead of "I'm flexible". Say which cities or regions you accept, whether you can relocate short term or long term, how much travel you can take, and whether you need hybrid or on-site work.
  2. Separate hard constraints (family, visa or work permit, a lease, a start date) from preferences, so the person matching you to projects knows what can be negotiated.
  3. Tie the answer to the sectors you named. If your preferred sector sits in specific regions, say whether you would move for it.
  4. Keep it consistent across rounds. Saying one thing at the HR screen and another at a later stage creates matching problems later.

Follow-up

  • Would you accept a placement in another city starting soon if the project fit your profile?
  • Would you consider a client engagement abroad, and under what conditions?
  • How much travel per month could you sustain long term?

"What are your salary expectations, and what notice period do you require before starting a new engagement?"

Medium · Professional Fit & Language Skills

Approach

  1. Research a market range beforehand for your experience level, city and country. Use salary surveys and peers, then state a range you can defend rather than a single number.
  2. Say exactly what the number means: gross or net, annual or monthly, and whether it includes benefits, bonuses or travel allowances for client sites. A mismatch on these terms is the usual source of later surprises.
  3. For notice period, check your contract and any collective agreement before the call and give an exact earliest start date. If you are a student or graduate, give your graduation date.
  4. Know your floor before the call and do not go below it under pressure. If asked to go first, it is fine to give your range and ask how the package is structured.

Follow-up

  • Is there flexibility in that range?
  • Could you start earlier if a client project required it, for example by negotiating your notice?
  • What does your current or most recent package include?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

  1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
  2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
  3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
  4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

  • The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
  • Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

  1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
  2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
  3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
  4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

  • Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
  • Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

"Can you present your academic background and detail the key engineering choices behind your master's thesis o

Medium · Background & Academic Experience

"Can you present your academic background and detail the key engineering choices behind your master's thesis or university projects?"

Approach

  1. Open with three facts: the problem the thesis or project solved, the constraint that shaped it (real-time deadline, memory budget, target board), and the part you personally built. Then spend the answer on decisions, not on chronology.
  2. Walk through two or three engineering choices as alternatives you weighed: C++ versus Python for the control loop, threads versus an event loop, a full Linux distribution versus a bare-metal or RTOS target. Give the reason you picked one in a single sentence each.
  3. Back each choice with evidence: a measured latency, CPU load, memory footprint or a test result on the real hardware. Also name a limit you hit and how you worked around it.
  4. Name the toolchain concretely (compiler, CMake, Git, debugger, target OS) so the answer gives the interviewer something to dig into. Then close with what you would change if you rebuilt it today.
  5. Rehearse the same walkthrough in English as well. Candidates report language checks, and a thesis explained fluently in one language can stall in the other.

Follow-up

  • Why did you reject the alternative design, and what would have made it the better choice?
  • How did you validate the system on the target hardware rather than on your laptop?
  • Which bug in that project took you longest to find, and how did you isolate it?

"Why are you interested in joining Ayes - Management & Technology Consulting over a traditional product compan

Medium · Background & Academic Experience

"Why are you interested in joining Ayes - Management & Technology Consulting over a traditional product company?"

Approach

  1. Give two or three reasons rooted in your own background. One can be the range of sectors candidates describe for this company's projects (Automotive, Aerospace & Defense, Rail, Energy, Industrial Automation). Another can be the embedded C++ and Linux work the role lists.
  2. Link each reason to evidence: a course, internship or project that made you want variety of domains, or a toolchain you want to keep using across clients.
  3. Name the trade-off honestly and say how you handle it. You give up long-term ownership of one product and may change teams, sites or stacks. Explain how you ramp up quickly on a new codebase.
  4. Avoid two answers that sink this question: criticising product companies, and repeating the company's own description back. Speak about what you want to do, not what the firm says about itself.

Follow-up

  • What would you do if a client project used a stack you have never worked with?
  • Which sector would you want to start in, and why that one?
  • How do you keep technical depth when you move between client domains?

"What are your primary technical areas of interest, and which industrial sectors (e.g., Automotive, Rail, Aero

Medium · Background & Academic Experience

"What are your primary technical areas of interest, and which industrial sectors (e.g., Automotive, Rail, Aerospace) do you want to specialize in?"

Approach

  1. Name one or two technical areas precisely, such as embedded Linux and BSP work, C++ application or middleware development, build and integration (CMake, Yocto), or multithreaded systems. Tie each to something you have already built.
  2. Pick a first-choice sector and an acceptable second. Give a reason grounded in experience rather than general interest, for example a CAN-bus lab for automotive or a control-system thesis for industrial automation.
  3. Show you know what the sector implies for software. Automotive work often follows ISO 26262 functional safety and MISRA coding rules. Avionics software is commonly certified against DO-178C. Industrial automation brings fieldbuses such as Modbus.
  4. State your flexibility explicitly: what you would accept outside your first choice. That gives the person matching you to projects a usable answer instead of a single option.

Follow-up

  • What do you know about functional safety requirements in the sector you named?
  • Would you take a project in a different sector if it came first, and what would you want in return?
  • Which of your projects is closest to the work in that sector?

"What are your long-term career goals, and where do you see yourself professionally in the next three to five

Medium · Background & Academic Experience

"What are your long-term career goals, and where do you see yourself professionally in the next three to five years?"

Approach

  1. Give a concrete path, not a title. For example: become autonomous on embedded C++ and Linux, then take ownership of a subsystem or integration area, then move towards a technical lead or software architect role.
  2. Connect the plan to consulting work: the domains you want to gain on client projects and the skills you will build, such as a safety standard, Yocto or a fieldbus.
  3. Name one or two learning steps you will take, such as a domain standard, a deeper C++ topic (concurrency, templates) or a certification relevant to your target sector, and say why each matters to you.
  4. Keep it consistent with what you said about sectors and mobility. Avoid hinting that you plan to leave for a client or a product company soon.

Follow-up

  • What are you doing right now to move towards that goal?
  • Would you rather go deep in one domain or broad across several, and why?
  • What would make you change that plan?

"Can you explain the workflow for configuring and building a custom embedded Linux image using the Yocto frame

Medium · Systems & Technical Execution

"Can you explain the workflow for configuring and building a custom embedded Linux image using the Yocto framework?"

Approach

  1. Set up the layers. Check out poky (the Yocto reference distribution) on one release branch, plus meta-openembedded and the board's BSP layer. Source oe-init-build-env to create the build directory. In conf/local.conf, set MACHINE, the DISTRO, and shared DL_DIR and SSTATE_DIR. List the layers in conf/bblayers.conf.
  2. Keep your own changes in a custom layer, created and added with bitbake-layers create-layer and add-layer. Never edit upstream layers. Change existing recipes through .bbappend files, and use BBFILE_PRIORITY to control which layer wins.
  3. Write a recipe for the application with SRC_URI, LICENSE, LIC_FILES_CHKSUM and inherit cmake. Then define or extend an image (for example from core-image-minimal) and add packages with IMAGE_INSTALL:append. The colon override syntax is used since the 3.4 release.
  4. Build with bitbake <image>. Artifacts land in tmp/deploy/images/<machine>. For the kernel, use bitbake -c menuconfig virtual/kernel and keep changes as .cfg config fragments. For application developers, export a cross SDK with bitbake <image> -c populate_sdk. devtool helps when iterating on a recipe.
  5. Trade-offs to mention: first builds are slow, so a shared sstate cache and download mirror matter across a team. Pin layer revisions for reproducible images. License manifests come out of the build for compliance.

Follow-up

  • When do you write a new recipe, a .bbappend, or a new layer?
  • How would you add an out-of-tree kernel driver or change a kernel config option?
  • How do you keep image builds reproducible and fast for a whole team?

"What process do you follow when integrating third-party libraries like Qt or Boost into a CMake build system?

Medium · Systems & Technical Execution

"What process do you follow when integrating third-party libraries like Qt or Boost into a CMake build system?"

Approach

  1. Use imported targets, not global variables. For Boost: find_package(Boost REQUIRED COMPONENTS filesystem) then target_link_libraries(app PRIVATE Boost::filesystem). For Qt 6: find_package(Qt6 REQUIRED COMPONENTS Widgets), link Qt6::Widgets, and turn on CMAKE_AUTOMOC so moc runs on QObject classes.
  2. Choose the dependency scope deliberately. PRIVATE when only your implementation uses the library, PUBLIC when it appears in your headers, INTERFACE for header-only wrappers. Avoid directory-wide include_directories and link_directories.
  3. Set minimum versions in find_package and build in CI from a clean checkout. Recent Boost releases ship their own BoostConfig.cmake, which newer CMake versions prefer over the old FindBoost module. Header-only Boost libraries need no compiled component.
  4. When cross-compiling, find the target's copy, not the host's. Use the toolchain file with CMAKE_FIND_ROOT_PATH or CMAKE_PREFIX_PATH pointing into the sysroot. In a Yocto build, declare the libraries in the recipe's DEPENDS so they come from the target sysroot.
  5. Check the non-code constraints too. Static or shared linking affects deployment size and licence obligations (Qt is available under LGPL or a commercial licence). Use the same compiler and standard library across all binaries to avoid ABI mismatches. Alternatives are a package manager such as Conan or vcpkg, or FetchContent.

Follow-up

  • What is the difference between PRIVATE, PUBLIC and INTERFACE in target_link_libraries?
  • How do you make find_package pick up the target sysroot's Qt instead of the host's when cross-compiling?
  • Would you link Qt statically or dynamically on an embedded device, and what does the licence change?

"How do you ensure software performance and code quality during unit testing and system validation phases?"

Medium · Systems & Technical Execution

Approach

  1. Separate the layers. Unit tests (GoogleTest or Catch2) cover logic, with hardware hidden behind interfaces so gMock can stand in for drivers. Integration and system tests run on the real target or a hardware-in-the-loop rig. Trace each test back to a requirement.
  2. Measure coverage with gcov and lcov, and know the levels. Statement and branch coverage suit general code. MC/DC is required for the highest DO-178C level, and ISO 26262 recommends it at the highest ASIL.
  3. Automate quality gates in CI: warnings as errors, clang-tidy or cppcheck (plus a MISRA checker where the project requires one), and AddressSanitizer and UndefinedBehaviorSanitizer test runs. Code review covers what tools miss.
  4. For performance, set budgets first (latency, CPU, memory). Profile on the target with perf, or Valgrind callgrind and massif. Benchmark with Google Benchmark on target hardware, because host numbers do not transfer. Track the results in CI to catch regressions.
  5. Test the optimised build as well as the Debug build. Undefined behaviour and timing bugs often appear only at -O2.

Follow-up

  • How would you unit-test code that writes hardware registers or talks on a CAN bus?
  • What is the difference between branch coverage and MC/DC, and when is MC/DC worth the cost?
  • A test passes on the host but fails on the target: what do you check first?

"How do you debug a multi-threaded application when troubleshooting dynamic race conditions or deadlock scenar

Medium · Systems & Technical Execution

"How do you debug a multi-threaded application when troubleshooting dynamic race conditions or deadlock scenarios?"

Approach

  1. First make the failure repeatable. Run the scenario in a stress loop, raise the thread count, pin to fewer cores with taskset to change interleavings, or add a yield in the suspected window. Heavy logging changes timing, so I log to a lock-free ring buffer with timestamps and thread IDs.
  2. For races, I build with ThreadSanitizer (-fsanitize=thread on both compile and link; it cannot be combined with AddressSanitizer) or run Valgrind Helgrind or DRD. These report unsynchronised accesses and lock-order inversions with stack traces.
  3. For a deadlock, I attach gdb to the hung process (or take a core with gcore) and run thread apply all bt to see which thread holds which mutex and which one it waits for. That usually exposes a lock-order cycle.
  4. Fixes: a single global lock order, std::scoped_lock to take several mutexes together without deadlocking, shorter critical sections with no callbacks while a lock is held, std::atomic for simple flags, and condition_variable::wait with a predicate to handle spurious wakeups.
  5. I prove the fix by running the same stress loop for many iterations under the sanitizer, and I add a regression test. One clean run proves nothing for a timing bug.

Follow-up

  • What is the difference between a data race and a race condition, and can you have one without the other?
  • How would you diagnose priority inversion on a real-time Linux target?
  • Why must condition_variable::wait be called with a predicate or inside a loop?

Suggested practice checklist

The plan follows the reported loop: first your CV and tools, then the project story and English, then the C++, Linux and build questions candidates report, and finally the motivation, logistics and scope questions that decide client placement.

Day 1 — Inventory your CV and the tools you can defend

  • List every compiler, debugger, build tool, framework and version-control workflow on your CV, and next to each write one concrete use
  • Answer aloud, timed: "What specific development tools, compilers, and software frameworks did you utilize in your recent technical assignments?"
  • Mark anything you could not discuss for a few minutes and either study it or remove it from the CV

Deliverable: A one-page tool inventory with an example per item, and a spoken answer to the tools question.

Day 2 — Thesis story and spoken English

  • Write the thesis or project walkthrough as problem, your contribution, tools, result, with two design decisions and their rejected alternatives
  • Answer aloud, timed: "Can you present your academic background and detail the key engineering choices behind your master's thesis or university projects?"
  • Answer aloud in English: "Could you briefly describe your personal hobbies or recent vacation plans in English?"
  • If you want to be ready in Italian as well, repeat the thesis walkthrough in Italian

Deliverable: A written thesis outline with decisions, plus recorded spoken answers to the background and hobbies questions.

Day 3 — Modern C++ memory management and quality

  • Write a short example showing unique_ptr, shared_ptr with weak_ptr, and a custom deleter for a file descriptor, and explain each ownership choice
  • Answer aloud: "How do you approach modern C++ memory management, and how do smart pointers prevent resource leaks in embedded software?"
  • Answer aloud: "How do you ensure software performance and code quality during unit testing and system validation phases?", naming the test framework, sanitizers and static analysis you would use

Deliverable: A compiled smart-pointer example and spoken answers on memory management and on testing and validation.

Day 4 — Yocto images and CMake with Qt or Boost

  • Write the Yocto sequence from environment setup through layers, recipe, image, build and flash, and mark which step you have done yourself
  • Answer aloud: "Can you explain the workflow for configuring and building a custom embedded Linux image using the Yocto framework?"
  • Write a CMake snippet that finds Boost and Qt, links imported targets and takes a cross-compile toolchain file, then answer aloud: "What process do you follow when integrating third-party libraries like Qt or Boost into a CMake build system?"

Deliverable: A Yocto workflow outline and a working CMake snippet, plus spoken answers to both build questions.

Day 5 — Debugging concurrency and leaks

  • Write a small program with a data race and another with a lock-ordering deadlock, then find each with ThreadSanitizer and with gdb stack traces of all threads
  • Answer aloud: "How do you debug a multi-threaded application when troubleshooting dynamic race conditions or deadlock scenarios?"
  • Write a leak-hunting checklist for a Linux target: LeakSanitizer or valgrind, memory growth over time, and what you would change after finding the leak

Deliverable: Two reproduced bugs with the diagnosis for each, and a leak-hunting checklist.

Day 6 — Motivation, goals and logistics

  • Write and answer aloud: "Why are you interested in joining Ayes - Management & Technology Consulting over a traditional product company?"
  • Answer aloud: "What are your primary technical areas of interest, and which industrial sectors (e.g., Automotive, Rail, Aerospace) do you want to specialize in?" and "What are your long-term career goals, and where do you see yourself professionally in the next three to five years?"
  • Write your position on relocation, salary expectations and notice period, then answer both logistics questions aloud with the same wording you plan to use in every round

Deliverable: Four spoken answers on motivation, sectors and goals plus a one-paragraph statement of your mobility, salary and notice position.

Day 7 — Scope and deadline story, then a full mock loop

  • Write a STAR outline for: "How do you handle shifting project scope or tight client deadlines when deployed on a consulting project?" with the decision, the trade-off you presented and who you told
  • Run a mock of all three stages in sequence: HR questions, then project and C++ questions, then a client-style debugging and build discussion, with the English portions spoken in English

Deliverable: A finished STAR outline for the scope question, and a recorded mock covering all three rounds with notes on weak answers.

Consulting fit and project stories

For this loop, the behavioural side is mostly consulting fit: why you want client work, which sectors you want, how you react when scope or deadlines shift, and whether you can explain a project to both technical and non-technical people. Candidates also report spoken English checks and questions on mobility, salary and notice period. Prepare real stories where you made a decision, and rehearse them out loud in English.

  1. "Describe a scenario where system requirements changed mid-project and how you adapted your software architecture."
  2. "How do you align priorities when working simultaneously with an internal Business Manager and a client technical lead?"
  3. "In English, give a brief overview of an engineering project you are particularly proud of and your role within it."
  4. "Why are you interested in joining Ayes - Management & Technology Consulting over a traditional product company?"
  5. "What are your long-term career goals, and where do you see yourself professionally in the next three to five years?"

"How do you handle shifting project scope or tight client deadlines when deployed on a consulting project?"

Medium · Professional Fit & Language Skills

Approach

  1. Pick one real consulting-style or client-facing project where scope moved or a deadline tightened, and where you owned the response, not one you merely watched. Open with the situation in two sentences: what was agreed, what changed, and the date at stake.
  2. Show the handling in order: restate the new request in writing, separate what is genuinely new from what was already implied, estimate the extra work, and put the trade-off to the decision-maker as a choice (drop something, move the date, or add people) instead of silently absorbing it.
  3. Name both audiences. In this loop you answer to an internal Business Manager and to a client technical lead, so say who you told, what each needed to hear, and how you kept the two messages consistent.
  4. Show the technical protection you used under pressure: a prioritised list of must-have against deferrable items, a frozen interface, tests on the critical path, a recorded list of the shortcuts you took. Close with the outcome and what you would do differently.
  5. The mistake that sinks this answer is the heroic one: working extra hours without telling anyone, or blaming the client. Equally weak is an answer with no concrete decision in it.

Follow-up

  • What did you cut or defer, and who agreed to that?
  • How did you tell the client the date or scope was changing, and how did they react?
  • What would you change about the first conversation if the same situation came up on your next client engagement?

Turn a code review disagreement into a decision

Easy · code review · optimistic concurrency · communication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach

  1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
  2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
  3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
  4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.

Follow-up

  • Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
  • The author says clients cannot handle a 409. How do you check whether that is true?

Ship under a deadline and bound the debt you chose

Medium · pagination · technical debt · tradeoffs

You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

Approach

  1. Name the deferred failure precisely instead of calling it slow. OFFSET n makes the database produce and discard n rows, so cost grows with page depth; without an index matching the sort, every matching row is read and sorted before the limit applies; and rows inserted between two page fetches shift across the boundary so items are skipped or repeated with nothing in the response to signal it.
  2. Bound the blast radius with something mechanical rather than a promise: cap maximum page depth, cap page size, restrict the endpoint to one internal caller, or keep it behind a flag. State which failure each cap removes and which it leaves standing.
  3. Attach a number to the trigger and wire it to an alarm: the first tenant crossing N resources, or the endpoint's p99 crossing its share of the 400 ms budget, so the debt announces itself instead of waiting to be remembered.
  4. Write it where the next engineer looks, which is the code and the ticket, not a chat message: what was deferred, why, the cap, and the trigger.

Follow-up

  • At what page depth does the offset version breach your latency budget, given your page size and row counts?
  • What breaks first when you switch to keyset pagination later, and what does a client holding an old page token see?