Written by Jackson Godwin · Cybersecurity Analyst & Penetration Tester.

Ethical hacking interviews are unlike most IT interviews. Panels are not only checking whether you can recite the OSI model — they are testing whether you think like an attacker while behaving like a professional bound by scope, consent, and law. Whether you’re applying for a junior SOC-to-pentest transition role, a mid-level penetration testing position at a fintech, or a senior red team lead role at a bank or oil and gas operator, interviewers layer their questions by depth: fundamentals first, then methodology, then judgment under ambiguity.

This guide breaks down real interview questions by career stage — junior, mid-level, and senior/expert — with model answers you can adapt to your own experience. Throughout, we’ve woven in the regulatory and market realities that matter for Nigerian and African employers, including the Nigeria Data Protection Act (NDPA) 2023, CBN cybersecurity guidelines, and NUPRC expectations for the upstream oil and gas sector, because global technical competence alone rarely closes the interview loop in this market.

Why These Interviews Are Structured in Tiers

Junior interviews test foundational knowledge, curiosity, and your willingness to learn under supervision — panels want to see that you understand core concepts even if you haven’t yet run a full engagement solo. Mid-level interviews test independent execution: can you scope, run, and report a complete penetration test with minimal hand-holding? Senior and expert interviews shift almost entirely to judgment — scoping ambiguous engagements, communicating risk to non-technical stakeholders, and defending decisions under pressure.

Increasingly, African employers — particularly banks, fintechs, oil and gas operators, and public sector agencies — layer regulatory awareness into every tier of the interview. A candidate who understands how a finding maps to ISO 27001 controls, the CBN cybersecurity framework, or NDPA 2023 obligations stands out immediately, because compliance-driven VAPT is now the default engagement model across the region rather than a niche add-on.

Junior / Entry-Level Questions

These questions establish whether you have the conceptual foundation to be trusted with supervised engagements.

Q1. What is the difference between a vulnerability, a threat, and a risk?

A vulnerability is a weakness in a system — an unpatched CVE, a misconfigured S3 bucket, weak session management. A threat is anything capable of exploiting that weakness, such as a malicious actor, malware, or an insider. Risk is the likelihood of that threat exploiting the vulnerability, multiplied by the potential business impact. In practice, I always frame findings in terms of risk to the business, not just technical severity, because that’s what clients and regulators actually act on.

Q2. Explain the difference between black-box, grey-box, and white-box testing.

Black-box testing simulates an external attacker with zero prior knowledge of the target — you rely entirely on reconnaissance. Grey-box testing gives you partial information, such as a low-privilege user account or basic network diagrams, which mirrors an insider threat or a compromised low-level account. White-box testing gives full access to source code, architecture diagrams, and credentials, which allows for the deepest and fastest coverage but sacrifices realism. Most enterprise engagements I’ve supported use grey-box, since it balances depth with time constraints.

Q3. What is the difference between a vulnerability scan and a penetration test?

A vulnerability scan is automated and identifies known weaknesses by matching signatures against a database — it’s fast, broad, and produces false positives. A penetration test goes further: a human tester validates and exploits those findings, chains them together where possible, and demonstrates real business impact. Regulators like the CBN and frameworks like ISO 27001 typically require documented penetration testing, not just a scan report, precisely because scans alone don’t prove exploitability.

Q4. Walk me through the phases of a penetration test.

I follow a standard structure: reconnaissance and information gathering, scanning and enumeration, vulnerability identification, exploitation, post-exploitation and privilege escalation, and finally reporting with remediation guidance. I’d add a scoping and rules-of-engagement phase before any technical work begins, and a re-test phase after the client remediates — both are often overlooked by newer testers but are essential for a defensible, audit-ready engagement.

Q5. What is the difference between symmetric and asymmetric encryption?

Symmetric encryption uses a single shared key for both encryption and decryption — it’s fast and efficient for large volumes of data, like AES protecting data at rest. Asymmetric encryption uses a public-private key pair, which solves the key-distribution problem and underpins things like TLS handshakes and digital signatures. In practice, most systems use both together: asymmetric encryption to securely exchange a symmetric session key, then symmetric encryption for the bulk of the data transfer.

Q6. What tools have you used, and what is one you’re still learning?

I’d answer honestly and specifically — naming tools like Burp Suite, Nmap, Metasploit, or Wireshark, and giving one concrete example of how I used each. Then I’d name one tool or technique I’m actively building depth in, such as cloud-native attack tooling or a specific fuzzing framework. Interviewers value honesty about gaps far more than a rehearsed list of every tool that exists — it signals self-awareness and a genuine learning habit.

Mid-Level Questions

At this tier, interviewers expect you to own an engagement end-to-end, not just execute individual steps.

Q1. How would you approach testing a web application with no prior information within a 5-day engagement window?

I’d time-box reconnaissance tightly on day one — subdomain enumeration, technology fingerprinting, and mapping the application’s attack surface — then move quickly into authenticated and unauthenticated testing against the OWASP Top 10 categories most relevant to the app’s function. I’d prioritize areas with the highest likely impact (authentication, access control, injection points) over exhaustive low-value coverage, and reserve the final day for validation, retesting critical findings, and report drafting so nothing is rushed at the end.

Q2. Explain a SQL injection you found and how you’d validate and report it responsibly.

I’d describe identifying an unsanitized input parameter, confirming injection with a non-destructive payload, and then demonstrating impact — such as extracting a table name — without exfiltrating live customer data or modifying production records. Responsible validation means proving exploitability with the minimum necessary action, documenting the exact request and response, and immediately flagging anything indicating live customer data exposure to the client point of contact rather than waiting for the final report.

Q3. How do you handle a client’s production environment being fragile during testing?

I’d raise it explicitly during scoping and agree on safeguards in writing — testing windows outside peak hours, avoiding known-fragile endpoints, and a clear rollback or pause protocol if something breaks. During testing, I throttle aggressive tools like automated scanners and communicate proactively with the client’s technical contact rather than assuming silence means everything is fine. Protecting availability is as much a part of professional conduct as finding vulnerabilities.

Q4. Explain the difference between an authenticated and unauthenticated scan, and when you’d use each.

An unauthenticated scan simulates an outsider with no credentials, useful for understanding true external exposure. An authenticated scan uses valid credentials to assess what a logged-in user — or a compromised account — could see and do, which typically surfaces far more findings, including broken access control and privilege escalation paths. I use both: unauthenticated to establish the external attack surface, authenticated to assess insider and post-compromise risk, which regulators increasingly expect to see covered.

Q5. How do you prioritize findings in a report — what determines critical vs. medium?

I use a consistent scoring model, typically CVSS as a baseline, but adjust based on business context: exploitability, data sensitivity, exposure (internet-facing vs. internal), and compensating controls already in place. A finding that’s technically severe but requires physical access to an isolated internal network is rated differently from the same vulnerability sitting on a public-facing customer portal. I always explain the ‘why’ behind a rating in the report, since clients and auditors will challenge ratings that aren’t clearly justified.

Q6. A client’s environment must align with ISO 27001 and NDPA 2023 — how does that affect your testing scope and reporting?

It shapes both scope and language. Under ISO 27001, I map findings to relevant Annex A controls so the client’s audit team can trace remediation directly to certification requirements. Under NDPA 2023, I pay particular attention to how personal data is stored, transmitted, and accessed, and I flag any finding that constitutes a data protection exposure separately, since it may carry breach-notification obligations to NITDA. The report becomes a dual-purpose artifact: a technical remediation guide and a compliance evidence document.

Senior / Expert Questions

At senior level, the questions test scoping judgment, leadership, and the ability to operate at the level of risk and business strategy.

Q1. How do you scope an engagement for a bank or fintech operating under CBN cybersecurity guidelines, including third-party/vendor risk?

I start from the regulatory obligation itself — the CBN’s cybersecurity framework requires regular penetration testing and vendor risk oversight — and build scope backward from that. This means explicitly including third-party integrations, API gateways to payment switches, and any outsourced infrastructure, not just the bank’s own perimeter. I also negotiate scope to cover both technical testing and a review of the vendor risk management process itself, since regulators assess the program, not just a single test result.

Q2. Describe how you’d lead a red team engagement versus a standard pentest.

A standard pentest aims for broad, time-boxed coverage of known vulnerability classes. A red team engagement is objective-driven and assumes breach — the goal might be ‘reach the core banking database’ or ‘exfiltrate a specific dataset’ — and success is measured by whether detection and response actually work, not just whether a vulnerability exists. I’d set clear rules of engagement, a deconfliction channel with the blue team or a trusted agent inside it, and defined stop conditions, since red teaming carries higher operational risk than a standard test.

Q3. How do you communicate risk to a board or C-suite with no technical background?

I translate technical findings into business language: financial exposure, regulatory consequence, and reputational impact, usually in that order. I avoid CVSS scores and CVE numbers in the executive summary entirely, replacing them with plain statements like ‘an attacker could access customer account balances without a password’ followed by the business consequence. I always close with a small number of prioritized, resourced recommendations rather than an overwhelming list, since boards act on clarity, not completeness.

Q4. Tell me about a time you disagreed with a client about scope or a finding’s severity.

I’d describe a specific situation where a client wanted to downgrade a finding’s severity for business reasons, and how I held the technical rating while acknowledging their business constraint separately in the report — for instance, noting the finding as critical but adding a client-accepted-risk annotation with sign-off, rather than silently changing the rating. Protecting the integrity of the assessment while still being commercially reasonable is the balance senior testers are expected to strike.

Q5. How do you keep a testing team’s methodology consistent and auditable across multiple engagements?

I maintain a standardized methodology document mapped to a recognized framework such as OWASP or PTES, paired with report templates and a peer-review step before any report leaves the team. Every engagement retains its raw evidence — screenshots, request/response logs, tool output — so findings can be independently verified during a client audit or regulatory review. Consistency is what allows a firm to defend its work months later, not just at delivery.

Q6. How do you see AI changing both offensive tooling and defensive detection in the next 2-3 years, and how are you adapting?

Offensively, AI is accelerating reconnaissance, phishing content generation, and vulnerability triage, lowering the skill floor for attackers — I now factor AI-assisted attack speed into how I estimate an attacker’s likely dwell time during scoping. Defensively, AI-driven detection is improving anomaly detection but introduces new attack surface of its own, including prompt injection against AI-integrated tools, which is why I’ve been building AI governance and LLM-security assessment into my practice rather than treating it as a separate discipline from traditional VAPT.

Practical Interview Tips

A few habits consistently separate strong candidates from the rest, regardless of seniority:

• Bring a redacted sample report or methodology outline to show, not just describe, your work.
• Know one regulatory framework cold — ISO 27001 or NDPA 2023 — relevant to the employer’s sector, and be ready to connect a technical finding to a specific control.
• Be explicit about ethics and authorization boundaries without being asked; it signals professional maturity.
• Practice compressing a technical finding into two plain-language sentences a non-technical hiring manager can repeat back correctly.

Interview insight: Across banking, fintech, and oil and gas engagements in Nigeria, the candidates who advance fastest are rarely the ones with the longest tool list — they’re the ones who can tie a finding to a regulatory obligation and a business consequence in the same breath.

Preparing for an ethical hacking interview is ultimately preparation for the job itself: proving you can think offensively, act within scope, and communicate clearly to people who will make decisions based on your findings. Master that combination at whatever tier you’re interviewing for, and the technical questions become far easier to answer with confidence.

About the Author

Jackson Godwin is a Cybersecurity Analyst and Penetration Tester at Jackson Technology, specializing in VAPT, cloud security, and compliance advisory (ISO 27001, NDPA 2023, GDPR) for enterprise clients across banking, fintech, oil and gas, and the public sector.

Contact: info@jacksontechnology.com.ng  |  jacksontechnology.com.ng