Introduction: The Challenge of Interview Feedback and the Role of GDPR

One of the most common frustrations for job seekers is the difficulty of getting genuine, constructive feedback after an interview. Sometimes companies are hesitant to share details or they give generic responses like: “We decided to go with another candidate.” For many of us, that leaves a big question mark: What did I do well? Where did I falter? How can I improve for the next opportunity?

Enter the General Data Protection Regulation (GDPR) — a data privacy law in the European Union that grants individuals (including job candidates) the right to access their personal data held by organizations. In some cases, this can include the notes and evaluations made during the interview process. By making a formal GDPR request, you may be able to obtain specific insights into your performance — valuable information you can use to become an even stronger candidate.

However, requesting feedback via GDPR must be done carefully, both ethically and professionally. In this post, I’ll outline how to craft a GDPR request, interpret the feedback you receive, and use it to build a roadmap for professional growth — while also addressing concerns and potential risks.

1. Using GDPR to Request Interview Feedback

Understanding Your Rights Under GDPR

Under the GDPR, you have the right to access the personal data a company holds about you, often referred to as a “Subject Access Request” (SAR). For job applicants, personal data may include:

• Application forms and submitted CVs
• Interview notes and scorecards
• Email correspondence related to your application
• Other records created during the recruitment process

Step-by-Step Guide to Making a GDPR Request

1. Identify the Correct Recipient

Look for the company’s Data Protection Officer (DPO) or a dedicated privacy team. Their contact details are typically found in the company’s privacy notice or on their website.

2. Use Clear, Polite Language

Your request should be respectful and concise. Explain that you want to access your personal data to understand your interview performance more thoroughly.

3. Provide Necessary Details

Include the date(s) of your interview, the position title, and any reference numbers that might help the company locate your data quickly.

4. Reference GDPR Legislation

Mention that you are making a “Subject Access Request under Article 15 of the GDPR.” This clarifies the legal basis of your request.

5. Set a Timeline

Under GDPR, organizations generally must respond within one month, although they may extend it by up to two more months for complex cases. Politely note that you appreciate a timely response.

Sample Template for a GDPR Request

Subject: GDPR Subject Access Request – [Your Name]

Dear [Name of Data Protection Officer or Hiring Manager],

I hope you are well. I am writing to formally request access to my personal data under Article 15 of the GDPR. I applied and interviewed for the [Position Title] on [Date(s) of Interview], and I would like to obtain the following information:

1. Any interview notes, feedback, or evaluation forms related to my candidacy.
2. Any scores, ratings, or assessment forms used during the recruitment process.
3. Any internal correspondence referencing my application or interview.

I am making this request to better understand my performance and areas for improvement. Please confirm receipt of this request and provide me with an estimated timeline for when I can expect the disclosure of my data.

Thank you for your assistance, and I look forward to your response.

Kind regards,

[Your Name]
[Contact Information]

2. Analyzing and Acting on Feedback

Let’s assume the company complies with your request and you receive personal data like detailed interview notes or evaluator comments. How do you make the most of it?

Objective vs. Subjective Feedback

• Objective: These are measurable details such as coding test scores, design critiques, or specific test results.

• Subjective: These reflect the interviewer’s impressions (e.g., “Candidate seemed nervous,” “Not a cultural fit,” “Needs stronger leadership presence”).

View all feedback as potentially useful. Even if the feedback feels negative or vague, ask yourself how you can respond with tangible improvements for your next interview.

Creating a Growth Roadmap

1. Categorize Feedback: Sort comments by skill area: Technical, Communication, Cultural Fit, Teamwork, Leadership Potential, etc.

2. Identify Strengths & Gaps: Note what you did well versus where you need more work.

3. Set SMART Goals: Make each goal Specific, Measurable, Achievable, Relevant, and Time-bound. For example, “Improve data structure knowledge by completing one coding challenge per day for three months.”

4. Seek Resources & Mentors: If you lack certain technical or soft skills, consider online courses, workshops, or finding a mentor who can guide your development.

5. Review & Iterate: Regularly revisit your feedback and progress to refine your approach. Over time, you’ll see measurable improvement in how you handle interviews (and in your overall professional skill set).

3. Addressing Concerns: Potential Risks & Mitigation

Asking for personal data under GDPR can feel daunting. You might worry about damaging your reputation or future hiring prospects at the company. While GDPR protects your rights, consider these points:

• Be Transparent

Emphasize that your sole motivation is self-improvement, not confrontation.

• Keep It Professional

Avoid emotional or accusatory language. Show appreciation for the opportunity and any feedback they can share.

• Clarify the Purpose

If you’re still in dialogue with HR, explain you value their input for your own growth.

• Understand Possible Limitations

Companies may redact or omit certain information to protect confidentiality or the privacy of other individuals.

• Respect the Outcome

If the company limits or denies parts of the request, stay courteous. Focus on what you can learn.

4. Alternative Leadership Building: Beyond the Job Interview

Even with thorough interview feedback, remember that interviews are only one facet of your professional journey. You can hone leadership and communication skills in various contexts:

1. Open-Source Contributions

Participating in open-source projects enhances both technical and collaborative skills, all while building a public track record.

2. Online Gaming Communities

Leading a gaming guild or participating in esports can foster real-world leadership and teamwork abilities — it sounds unconventional, but it’s surprisingly relevant.

3. Volunteer and Community Roles

Nonprofit or local community groups often need leaders and organizers. This is a great way to practice communication, strategic planning, and conflict resolution.

4. Industry Meetups & Conferences

Attending or speaking at events can boost your presentation skills and expand your network. This can pay off in future interviews by improving how you articulate your thoughts.

5. My Personal Experience: Highlights & Lessons Learned

When I first heard about using GDPR for feedback, I worried it might come across as aggressive. Would companies refuse outright? Ultimately, my desire to improve outweighed my fears, so I tried it.

• What I Requested: A concise SAR asking for my interview notes and any relevant feedback.

• What I Received: A summarized version of the interview panel’s feedback with suggestions for deeper elaboration.

• What I Learned:

1. My technical depth was good, but my explanations of how I arrived at solutions needed more structure.

2. I undersold my leadership experience by not providing enough tangible examples.

3. I didn’t clearly communicate why I wanted to join their specific team — my motivation seemed vague.

From there, I developed a practice routine:

• Technical Demos: I recorded short videos explaining my approach to coding challenges, which helped me refine how I articulate problem-solving steps.

• Leadership Storytelling: I wrote out real-life team leadership case studies (context, actions, and results) to use during interviews.

• Company-Specific Research: I doubled down on researching each company’s products and culture to better show genuine interest.

I won’t lie: making a GDPR request was nerve-racking. But the insights were extremely valuable for planning my next steps, without blindly guessing what went wrong.

6. Conclusion: Embrace Feedback for Continuous Growth

Leveraging GDPR to request feedback isn’t about forcing a company’s hand; it’s about using your legal right to access information that can drive your professional development. Whether you’re a new grad or an experienced professional refining your approach, the lessons you learn can profoundly shape your career trajectory.

Key Takeaways:

1. GDPR is a Tool: Use it ethically and professionally to gain insight into your performance.

2. Feedback is Fuel: Analyze objective and subjective commentary to hone your skills.

3. Maintain Respect & Professionalism: Approach all communications with humility, courtesy, and a growth mindset.

4. Diversify Your Growth: Go beyond interviews for leadership development — open-source, gaming, volunteering, and meetups are all valid arenas to sharpen your abilities.

Feel free to consider a GDPR request if you’re in the dark about interview results. Just remember: the goal is not to demand an outcome but to learn and grow into the best candidate you can be.

Disclaimer: The contents of this blog post do not constitute legal advice. If you have specific questions or concerns, please consult a qualified professional in your jurisdiction.

Thank you for reading, and I wish you the best on your journey toward that “10/10” interview performance. With clear feedback, strategic self-improvement, and the right mindset, every setback can become an opportunity for your next big leap forward.

References:

EU data protection info for individuals

Comments (Bluesky)

To make sure their software works well, many companies still rely on manual testing only. Not to mention the worst case when they don't test at all relying on users to find problems. Is it expensive? Yes. Is it slow? Yes. It can block tasks in the testing phase for weeks delaying the release of new features. Especially, if a person responsible for testing is busy with other tasks. And it becomes even worse in the long run. The more features you add, the more time you need to test everything. So it's not scalable at all. What else could go wrong? Let's think about the human factor. We can't guarantee that a person will test everything the same way every time. They could be distracted or just tired. So people invented unit tests, integration tests, and end-to-end tests to automate the process and defined the pyramid of tests. The biggest part of the pyramid is unit tests. And we may falsely think that unit tests are more important ignoring the rest. But the truth is end-to-end tests are the most valuable.

Key Benefits

In that sense, automated acceptance tests could be considered as a subset of E2E tests. Here are the benefits:

• 🎯 Ensures the app meets user expectations: We define the scenarios followed by the user and expectations.

• ✅ Increases confidence in software quality: We write tests once and run it many times on a large scope of devices or browsers.

• 🔄 Facilitates continuous integration and delivery: We trigger test runs on each commit or PR.

• 🔍 Enhances test coverage and efficiency: We're reusing steps involved in different scenarios. We're also confident regarding regressions.

• 🏃‍♂️ Supports agile and DevOps practices: This one is self-explanatory. We're applying changes quickly and continuously.

• 💰 Saves time and money: We don't need expensive resources to run tests. We get quick feedback after changes.

Keeping Things Simple

To get these benefits, it makes sense to start with happy paths for the most critical features. And we could keep scenarios simple and easy to understand following the KISS principle. We probably should leave the most complex and hard to automate scenarios for manual testing.

How could we implement it?

So here is what tools I'm using and why:

• Node.js/TypeScript: I prefer Node.js for tests because of its learning curve and flexibility.The issue with tests written natively using Swift (XCUITest) or Kotlin (UIAutomator) is that you need to have people who know all these languages and frameworks in order to maintain it. And you need to write it at least twice. It's not as scalable. Why TypeScript if I could use JavaScript? Because of strong typing. It gives us feedback about the code before we run it, during compilation time.

• Cucumber: If you ever worked with tools like TestRail or Qase, you probably know about test cases. Cucumber allows us to transform these test cases into code, acting as a bridge between business and development teams. It gives more people the chance to see what's being tested and how. This is probably also the main reason why I prefer Node.js over Swift or Kotlin. There are no good tools (at least for Swift) to write tests in Gherkin. We could reuse steps from a Gherkin scenario in other ones. There are even plugins and extensions for various IDEs to autocomplete these steps and when the amount of implemented steps grows, there is a possibility to write scenarios even without knowledge of a programming language. Isn't that cool?

• WebdriverIO and Appium: When it comes to testing native mobile apps, Appium is probably the only one well-known framework we could use. It's an implementation of the WebDriver protocol. There are various wrappers around it. Currently, I'm using WebdriverIO. Why? Because it's recommended by the Appium team. Would I stick with it in future? I don't know. But it does the job. I'm tempted to try Nightwatch.js in production to compare these two.

• Mockoon: Often there are some parts of the app which are hard to automate because of external dependencies. For cases with APIs, I'm using Mockoon. It allows quick setup of mock servers. And there is a CLI version which integrates nicely with the TypeScript code. It's possible to edit the response either in the app or in the code. And it can be shared with the team. In the end it's a nice tool to reduce the time spent on asynchronous tasks.

What else?

It makes sense to run such tests on some CI/CD platform in order to unblock the development process. I'll write more about it in the future.

I also plan to write about the process of setting up the environment and writing the first test. So stay tuned!