Skip to main content

Command Palette

Search for a command to run...

From Interview Surprise to MVP: Testing Developer Job Transparency

Updated
5 min read

A few weeks ago, I applied for a Backend Engineering role, expecting a technical interview similar to what I had experienced before—like the collaborative pair programming session I had when joining Automattic, where a developer and I worked together to add features to a WordPress plugin. Instead, I received a 90-minute coding assessment with a mix of LeetCode-style and domain-specific questions, scheduled within a 5-day window. A few days later, another interview surprised me again—I showed up expecting a discussion about my experience but was handed a piece of paper and asked to design an API response.

This made me wonder: Why are developers going into interview processes without knowing what to expect?

The Problem I Experienced

Most job boards tell you the salary, tech stack, and basic requirements. Company culture information is usually found on their career pages or sites like Glassdoor. But they rarely mention what the interview process actually looks like. Will there be whiteboarding? Take-home projects? Multiple rounds? System design sessions?

As a senior developer with options, knowing the interview format helps me:

  • Allocate preparation time effectively

  • Choose opportunities that align with my strengths

  • Avoid processes that feel misaligned with my experience

But this information is typically discovered during the interview process itself — too late to make informed decisions about time investment. Some companies do provide excellent transparency (detailed assessment instructions, preparation resources, and clear reapplication timelines), but they're the exception. Most companies leave you guessing about format, expectations, and preparation requirements until you're already committed to their process.

Building an MVP to Test the Idea

I decided to build something to test whether other developers want this transparency. Enter GlobalRemote — a job board that shows interview processes upfront.

The initial concept was simple: curate remote jobs that include detailed interview process information alongside the usual job details.

What I Built

Rather than scraping existing job boards, I chose manual curation to ensure data quality:

Data Sources:

  • Company career pages and hiring documentation

  • Direct outreach to recruiters for process clarification

  • Cross-referencing with resources like the hiring-without-whiteboards GitHub repo

  • Employee posts on platforms discussing company interview experiences

Information Collected:

  • Number of interview rounds and types (technical, behavioral, system design)

  • Time commitment expectations for assessments

  • Specific technologies or frameworks tested

  • Any unique aspects of their process

Current Status: 7 manually verified listings with complete interview transparency

Problems I Discovered While Building

As I started sharing the concept with other developers, two additional pain points kept coming up:

Geographic Restrictions: Multiple people mentioned getting excited about "remote" jobs only to discover hidden location requirements during the application process. Some jobs require specific timezone overlap, others have legal restrictions, and some companies prefer certain regions for operational reasons.

Regional Salary Context: A developer friend in New Zealand pointed out that my original $120k+ USD threshold excluded competitive senior roles in his market. A $90k USD role in Auckland might be excellent locally, even if it wouldn't meet US market expectations.

These insights taught me that the problem space was broader than just interview transparency.

Early Feedback and Response

I've been testing this concept in developer communities to see if it resonates:

Developer Community (WhatsApp):

  • 11 positive reactions

  • Discussion focused primarily on geographic restriction frustrations

  • One business-oriented suggestion about data reporting potential

  • Strong engagement suggesting the concept resonates

Tech Alumni Network (Slack):

  • 8 positive reactions

  • One person confirmed experiencing the geographic restriction problem and mentioned facing similar challenges during their recent job search

  • Another mentioned that LeetCode-style processes feel "lazy" from companies

  • Generally positive response to the transparency concept

Technical Challenges I'm Learning From

Building this MVP has revealed several interesting technical challenges:

Data Verification Complexity: Interview processes are described inconsistently across companies. "Technical interview" could mean live coding, whiteboarding, take-home projects, or system design discussions. This required careful manual interpretation to understand what each company actually does.

Geographic Restriction Nuance: "Remote work" has many different meanings depending on company policy. Some companies require timezone overlap (e.g., "must work EST hours"), others have legal restrictions (e.g., "US/Canada only"), and some have operational preferences. Parsing and categorizing these restrictions requires understanding both company policies and legal frameworks.

Quality vs. Scale Trade-offs: I could scrape thousands of job listings quickly, but most would lack the interview process details that make the platform valuable. Manual curation ensures quality but limits scale — at least initially.

What I'm Learning About Developer Pain Points

Developers immediately understand the value proposition. The feedback suggests this is a real pain point, not just my personal frustration.

Geographic restrictions are more frustrating than I initially thought. The distinction between timezone requirements, legal restrictions, and operational preferences matters to job seekers.

Interview format transparency could change application behavior. Some developers mentioned they would self-select out of processes that don't align with their strengths or preferences.

Is This Problem Worth Solving?

The early feedback suggests there's genuine demand for this transparency, but I need more data points to be confident. The real test is whether developers would actually change their job search behavior based on this information being available upfront.

If interview transparency and geographic clarity would genuinely help you make better decisions about where to spend your time applying and preparing, then this is worth building. If it's just "nice to have" information that wouldn't actually change your behavior, then it's probably not worth the effort.

What I Need from You

I'm at the point where I need broader feedback from developers to decide whether to continue developing this or pivot to other opportunities.

If you're a developer who's job hunting or has recently job hunted:

  • Have you experienced similar interview process surprises?

  • Would knowing the interview format upfront change how you apply to jobs?

  • What other information would be valuable to know before applying?

  • Does the geographic restriction transparency resonate with your experience?

The engagement so far suggests there's something here, but I want to validate this with more developers before investing significant time in scaling the platform.

Check out the current MVP: jobs.alleyne.dev

Right now, I'm genuinely uncertain whether this problem is significant enough to warrant a dedicated solution, or if it's better solved through incremental improvements to existing platforms. Your feedback as developers who experience this problem firsthand will help me make that decision.


What's been your experience with interview process transparency during job searches? I'd love to hear your stories and thoughts in the comments.

B

Have you experienced similar interview process surprises? Yes

Would knowing the interview format upfront change how you apply to jobs? Yes

What other information would be valuable to know before applying?

Does the geographic restriction transparency resonate with your experience? Yes

1
D

Thanks Brian Sandi Appreciate you taking the time to respond - this kind of feedback is exactly what I needed