MFC Interview Questions

Analogy categoryAnalogies

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.'

cpp

// 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?

Migrating MFC to Modern Frameworks

MFC Quick Reference

Related Study Notes in Microsoft Technologies

Browse all study notes

Microsoft Technologies

Windows 10 / UWP Development Study Notes

.NET · 30 topics

Microsoft Technologies

Windows Batch Scripting Study Notes

Batch · 30 topics

Microsoft Technologies

Silverlight Study Notes

.NET · 30 topics

Microsoft Technologies

XAML Study Notes

.NET · 30 topics

Microsoft Technologies

WPF (Windows Presentation Foundation) Study Notes

.NET · 30 topics

Microsoft Technologies

MVVM Design Pattern Study Notes

.NET · 30 topics

Topics covered

#MFCMicrosoftFoundationClassesStudyNotes#MicrosoftTechnologies#MFCInterviewQuestions#MFC#Interview#Questions#Core#StudyNotes#SkillVeris#ExamPrep

MFC Interview Questions