The Ultimate 'I Wrote the Library' Interview Fail

Level 1: Your Own Game

Imagine you invented a really cool game and taught it to all your friends. Later, you go to a new school, and during recess an older kid (who doesn’t know you) starts quizzing you about the rules of your own game. He thinks he’s the expert because he’s read a few rules somewhere, and when you answer in a different way (since, well, you made the game, you know all the details), he tells you, “No, you don’t understand how this game works!” Then he says you can’t play because you “failed” his little test. How silly is that? You’d probably giggle because the situation is so backwards — you’re the creator, yet someone who barely knows the game is acting like you’re wrong about it.

That’s exactly what happened in this meme’s story. A person went to a job interview and the interviewer asked him about a piece of software that the person himself created (kind of like his “game”). The interviewer didn’t realize this and thought the person’s answers were wrong, so they didn’t give him the job. It’s funny in a crazy way: the interviewer was like a teacher who didn’t recognize the student who wrote the textbook, telling the author “you don’t know what you’re talking about.” The creator knew more than anyone, but still got told off. The reason this makes people laugh is because it’s so upside-down. It reminds us of a teacher marking the answer wrong even though the kid who answered is the one who made the quiz! It feels unfair, but also kind of comical because of how unbelievable it is.

In simple terms, the meme is showing a goofy mistake: not recognizing someone’s true skill. It’s like if you drew a beautiful painting and someone said, “Hmm, I don’t think you understand this painting at all.” You’d be thinking, “But I painted it!” You might even find it a little funny how wrong they got it. The story here has that same energy. Everyone can laugh at how mixed-up things got, and it also teaches a little lesson: before you judge someone on what they know, make sure you know who you’re talking to!

Level 2: Author vs Interviewer

At its core, this meme is about a job interview situation that turned absurd. The image is a screenshot of a tweet from an iOS developer named Jens Ravens. In the tweet, he says he “got rejected during a job interview for ‘not understanding’ the concepts of a certain iOS library.” The twist is revealed next: “What the interviewer didn’t know: I wrote that thing.” In plain terms, the interviewer challenged him on an iOS software library (a collection of code used in iPhone apps), and decided he didn’t understand it well enough — not realizing that he was actually the author of that library. The tweet ends with Jens saying he had a lot of fun in that interview, punctuated by a laughing emoji 🤣, indicating how ridiculous (but amusing) the experience was for him.

Let’s break down what likely happened step by step:

1. The setup: Jens, the candidate, is an experienced iOS developer. He has even created and published an iOS library (perhaps as an open-source project). This means other developers, possibly including the interviewer’s company, might use this library in their own apps.
2. The interview: During a technical interview (common in software HiringAndInterviews), an interviewer decided to ask about this specific library. They probably wanted to test if Jens understood the concepts or design principles behind it. Interviewers often prepare questions about tools and frameworks relevant to the job. Here, the library Jens wrote was chosen as a topic.
3. Misjudgment: The interviewer was unaware that Jens was the one who wrote the library. Perhaps the interviewer only knew the library by name, not the author, or didn’t connect Jens’s name to it. So the interviewer proceeded normally, perhaps asking something like, “Can you explain how works and what its key design concepts are?”
4. Different answers: Since Jens is the author, he knows the library inside-out. He might explain it in depth, talk about why certain decisions were made, or describe it in a way that doesn’t match the interviewer’s expected answer. The interviewer might have had a specific answer key or a buzzword in mind (for example, expecting to hear “it uses the observer pattern” or “it’s built on reactive programming”). If Jens’s explanation didn’t use those exact terms — maybe because he explained the underlying idea in his own words — the interviewer could mistakenly think he doesn’t “get” his own library. It sounds crazy, but if the interviewer only has shallow knowledge (maybe they learned about the library from a blog or a cheat-sheet), they might not recognize a correct but differently-worded explanation.
5. Rejection: Concluding that Jens “did not understand” the library’s concepts, the interviewer decides he’s not qualified for the job and rejects him. This is ironic because Jens literally has expert-level knowledge — he built the thing! It’s akin to failing an exam about a book when you are the one who wrote the book. The interviewer’s lack of preparation or insight led to a false negative in the hiring process (rejecting someone who is actually very qualified).
6. Aftermath: Jens found the experience more funny than upsetting. He knew exactly how absurd the situation was. In his tweet, he even says “I actually had a lot of fun during that interview,” laughing at the fact that he was being “schooled” on his own work. He didn’t take it personally; instead, he shared it as a humorous anecdote highlighting how InterviewHumor can stem from flawed TechnicalInterviews.

So, why is this significant to other developers or anyone in tech? It shines a light on a common problem in the TechnicalInterviewProcess. Interviews are supposed to assess a candidate’s knowledge, but they often become rigid quizzes. Sometimes the people conducting them aren’t truly knowledgeable about the topic either — they might just have a checklist of things to look for. In this story, the interviewer was using an iOSDevelopment topic (an iOS library) as a test, but ironically wasn’t informed enough to realize the candidate’s credentials. It’s a bit embarrassing from the company’s side: they turned away the person best suited to discuss that tool.

For a junior developer or someone new to tech, the lesson here is that interviews can be imperfect. You might encounter interviewers who ask trivia or expect textbook answers. It’s important to prepare, but also realize that sometimes the process doesn’t properly measure a person’s true skill. This meme, through a bit of humor, encourages companies and interviewers to do better: know who you’re interviewing (check their portfolio or contributions), and focus on meaningful discussion rather than gotcha questions.

A few terms explained for clarity:

• iOS library: This is a collection of code written to perform common tasks in iPhone/iPad apps. Developers use libraries to save time, instead of writing code from scratch. If you wrote an iOS library, you basically created a tool that others can include in their apps for extra functionality.
• Open source: This means the library’s code is publicly available for anyone to read or use. Many iOS libraries are open source, shared on platforms like GitHub. If Jens wrote the library, his code is out there for free, and he’s known in that open-source community (at least to those who pay attention).
• Interview “concepts”: Interviewers often ask about the “concepts” of something, which usually means the design principles or key ideas. For an iOS library, this could be questions like “What problem does it solve? How does it achieve that under the hood? What programming patterns does it use?” They expect the candidate to demonstrate understanding, not just usage.
• Rejected: In job-hunt terms, this means the candidate didn’t pass the interview stage and wasn’t offered the job. Here it happened because the interviewer thought the candidate lacked knowledge, which is the funny/tragic part.
• Interviewer preparation: Ideally, before interviewing someone, you’d read their resume or know their work. If the interviewer had done that, they might have noticed the candidate had that library listed as one of his projects! Failing to do so led to this awkward outcome.

This meme resonates with developers because many have experienced interviews that felt unfair or absurd. It encourages a bit of cautious optimism and laughter: yes, sometimes interviews go very wrong, but you’re not alone — even star developers have face-palmed at the process. In the community, stories like this serve as gentle push for companies to improve how they evaluate talent, and for candidates to not lose confidence when an interview experience doesn’t reflect their true abilities.

Level 3: Wrote the Code on It

This meme highlights a painfully ironic scenario in technical interviews: an expert being told they don't understand their own creation. It's a screenshot of a tweet by an iOS developer (Jens Ravens) who was rejected for supposedly not grasping the "concepts" of a certain iOS library. The punchline? He was the one who wrote that library. This is the kind of DeveloperIrony that makes seasoned engineers both laugh and groan. We've got an interviewer_unaware_authorship situation — a major open_source_authorship_fail where the interviewer didn’t realize the candidate literally authored the tool in question.

In the world of IOSDevelopment, libraries are shared bundles of code (often open-source frameworks) that developers include in their apps to solve common problems. Here, the interviewer probably picked a popular iOS library from their question bank, expecting to quiz the candidate on its inner workings or usage. The tragic comedy is that the candidate was the maintainer of that library, someone who knows its architecture intimately. Yet the interviewer, armed with perhaps only a surface-level understanding or a stack of flashcards about it, decided the candidate “did not understand” their own creation. This scenario is a textbook case of a broken TechnicalInterviewProcess in action — where HiringAndInterviews rely more on rote checklists than actual insight.

Why is this so funny (or cringe-worthy) to experienced devs? It exposes the absurd gap that can exist between real-world expertise and interview trivia. The interviewer was likely looking for canned answers: maybe expecting the candidate to recite a specific definition or pattern (“Does this library use MVC or MVVM? Explain dependency injection in it,” etc.). The author, on the other hand, probably gave a nuanced explanation, perhaps even pointing out trade-offs or design decisions that the interviewer didn't fully understand. Instead of realizing they're speaking with the library’s creator, the interviewer assumed the candidate was confused. It’s a career_HR nightmare when the InterviewHumor comes at the expense of recognizing talent.

This situation is a bit like quizzing Linus Torvalds on git usage and telling him he’s wrong about branching strategies — it’s beyond absurd. 😅 Yet, those of us who’ve been around the block have seen similar things. Technical interviews can become cargo cult exercises: an interviewer with a shallow grasp of a topic wields their prepared questions like a gatekeeper’s key. If your answers don’t use the exact buzzwords or match the expected script, you fail — even if you literally wrote the code behind it. The meme nails this developer irony: the interviewer ends up effectively gatekeeping the gatekeeper.

From a senior perspective, this also highlights poor interviewer preparation and flawed process. A well-prepared interviewer would have known the candidate’s background (especially if the candidate’s resume or online profile lists the open-source library they maintain). But in many companies, interviewers are voluntold to grill candidates on whatever topic is on the sheet, often without context. It’s a classic hiring anti-pattern: trusting a quiz over a candidate’s actual experience. By relying on shallow question banks — “Tell me the concepts of Library X” — the company failed to recognize they had the ultimate subject-matter expert in the room. Instead of a productive discussion or maybe even learning from the candidate, the process devolved into a gotcha quiz show. No wonder the tweet’s author says “I actually had a lot of fun during that interview” with a laughing emoji — when you realize the situation is that ludicrous, sometimes all you can do is sit back and enjoy the ride as the interviewer ties themselves in knots. True story: being rejected for “not knowing” your own work is such a farce that it becomes comic relief among developers who share these war stories.

Let’s sketch the interview’s logic in pseudo-code for dark humor’s sake:

// Interview pseudocode for checking knowledge of SomeiOSLibrary
if candidate.isAuthor(of: "SomeiOSLibrary") {
    // Interviewer doesn't realize this, missing a crucial context
}
if !candidate.answersUsingExpectedBuzzwords("SomeiOSLibrary") {
    interviewer.reject(candidate, reason: "not understanding the library concepts")
} else {
    interviewer.moveToNextQuestion()
}

The code above lampoons how the interviewer ignored the candidate.isAuthor fact and hinged the decision on rigid expected answers. The TechnicalInterviews system here fails spectacularly: it’s treating a creator like a newbie for not parroting the handbook the creator probably wrote. The humor isn’t just in the individual incident; it’s in recognizing a systemic flaw. Just about every experienced dev knows someone with a similar anecdote (or has one themselves): the time you got rejected because the interviewer had no idea what they were talking about — or worse, wouldn’t listen to someone who did.

In summary, at the expert level this meme underscores the paradox of technical interviews: they aim to assess true understanding, yet often only skin-deep signals are measured. It’s a cautionary tale about HiringAndInterviews gone wrong — and a wink to all the coders out there who have felt the sting (or amusement) of being misunderstood by an underqualified gatekeeper. The next time someone fails an interview for “not understanding” something they literally built, we’ll laugh to keep from crying, and remember this meme as the perfect example.