MFC Interview Questions
MFC interviews at companies maintaining legacy CAD, financial-terminal, or industrial-control software tend to probe three areas: whether a candidate understands the Document/View architecture well enough to reason about real bugs, whether they understand how MFC's message routing actually works underneath the ClassWizard-generated macros, and whether they can talk concretely about memory and resource management given MFC's mix of C++ RAII and raw Win32 handles. Strong candidates connect these to first principles (the Windows message loop, COM lifetime rules, GDI's handle-table model) rather than reciting memorized class names.
Cricket analogy: A good MFC interview answer is like a commentator explaining not just that a batsman got out, but the exact mechanics of the delivery (seam position, swing) — first principles beat memorized outcomes.
Core Conceptual Questions
A frequently asked question is 'what happens when the user resizes an MDI child window, step by step, from the WM_SIZE message to the screen redraw' — a strong answer traces the path from Windows posting WM_SIZE, through CWnd::WindowProc dispatching via the message map to CView::OnSize (or an override), then explains that the base class implementation typically invalidates the client area, which queues a WM_PAINT that eventually calls OnDraw() through OnPaint()'s CPaintDC setup. Another common question probes CObject and RTTI: 'why does MFC implement its own IsKindOf() and RUNTIME_CLASS() macros instead of using standard C++ dynamic_cast', and the expected answer is that MFC predates widespread, portable RTTI support in C++ compilers of the era, and MFC's own scheme also integrates with serialization (Serialize()) and dynamic object creation (CreateObject()) via CRuntimeClass, which dynamic_cast alone doesn't provide.
Cricket analogy: Tracing WM_SIZE to OnDraw() step by step is like a coach walking through exactly how a run is scored — the throw, the relay, the stumps — rather than just saying 'they scored a run.'
// Interview-style RTTI question: IsKindOf / RUNTIME_CLASS vs dynamic_cast
class CBaseShape : public CObject
{
DECLARE_DYNAMIC(CBaseShape)
};
IMPLEMENT_DYNAMIC(CBaseShape, CObject)
class CCircleShape : public CBaseShape
{
DECLARE_DYNCREATE(CCircleShape) // adds CreateObject() support
public:
double m_radius = 0.0;
};
IMPLEMENT_DYNCREATE(CCircleShape, CBaseShape)
void ClassifyShape(CBaseShape* pShape)
{
// MFC-native RTTI, works even where dynamic_cast<> support was historically absent
if (pShape->IsKindOf(RUNTIME_CLASS(CCircleShape)))
{
CCircleShape* pCircle = STATIC_DOWNCAST(CCircleShape, pShape);
TRACE(_T("Circle radius=%f\n"), pCircle->m_radius);
}
// CRuntimeClass also enables dynamic creation by class name (used by CDocTemplate)
CRuntimeClass* pClass = RUNTIME_CLASS(CCircleShape);
CObject* pNewObj = pClass->CreateObject(); // equivalent to `new CCircleShape`
}Behavioral and Debugging-Style Questions
Beyond conceptual questions, interviewers frequently ask candidates to reason through a described symptom, such as 'our app's GDI object count climbs steadily during a printing loop and eventually printing fails — what would you check first,' expecting the candidate to walk through checking whether every CDC::SelectObject() call in the print handler has a matching restore of the old object, whether CGdiObject-derived locals go out of scope (and hence destruct) before the DC that holds them, and whether the print preview code path duplicates GDI object creation without cleanup on cancel. Interviewers also probe threading questions specific to MFC, such as 'can you call CWnd::SetWindowText from a worker thread,' where the correct answer explains that most CWnd operations are not thread-safe because the underlying HWND belongs to the thread that created it, and the safe pattern is to marshal the call back to the UI thread with PostMessage or SendMessage rather than touching the CWnd directly from a worker thread.
Cricket analogy: Diagnosing a GDI leak during a printing loop is like a bowling coach reviewing why a bowler's pace drops over a long spell — checking run-up, action, and recovery one variable at a time rather than guessing.
For the SetWindowText-from-a-worker-thread question, the fully correct answer distinguishes SendMessage (blocks the worker thread until the UI thread processes it, risking deadlock if the UI thread is waiting on the worker) from PostMessage (asynchronous, generally safer for cross-thread UI updates in MFC).
- Strong MFC interview answers connect behavior to first principles: the Windows message loop, GDI's handle model, and COM-style lifetime rules.
- Tracing WM_SIZE through message map dispatch to OnDraw() demonstrates real understanding of the Document/View pipeline.
- MFC's IsKindOf()/RUNTIME_CLASS() predate portable C++ RTTI and additionally power Serialize() and dynamic object creation.
- Diagnosing a climbing GDI handle count requires checking every SelectObject() call has a matching restore on every code path.
- Most CWnd operations are not thread-safe because an HWND belongs to the thread that created it.
- PostMessage is generally the safer pattern for cross-thread UI updates versus SendMessage, which can deadlock.
- Interviewers value candidates who reason through symptoms methodically rather than reciting memorized MFC class names.
Practice what you learned
1. Why does MFC implement its own RTTI via IsKindOf() and RUNTIME_CLASS() instead of relying solely on dynamic_cast?
2. What is generally true about calling CWnd::SetWindowText from a worker thread?
3. Why is PostMessage generally preferred over SendMessage for cross-thread UI updates in MFC?
4. When diagnosing a steadily climbing GDI object count during a printing loop, what should be checked first?
5. What message flow does the WM_SIZE-to-OnDraw() interview question typically test understanding of?
Was this page helpful?
You May Also Like
MFC Common Pitfalls
The recurring mistakes MFC developers make with message maps, GDI resources, and the Document/View architecture, and how to avoid them.
Debugging MFC Applications
Practical techniques for diagnosing MFC bugs using TRACE, ASSERT_VALID, the debug heap, and Spy++ message inspection.
MFC Quick Reference
A condensed lookup of MFC's core class hierarchy, message map macros, and common string/collection/resource idioms.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics