🔗 How to Interview Software Developers as a Software Developer

Table of Contents

1. Introduction
2. Why You Should Care
3. The Interviewer Mindset
4. My Interview Process
5. Gauging Candidates' Technical Skills
6. Ensuring a Positive Atmosphere
7. Appendix 1: On Take-Home Assignments
8. Appendix 2: How to Write Job Descriptions
9. Appendix 3: How to Read Résumés
10. Appendix 4: But My Workplace Sucks, Why Would I Do This to Someone?

Introduction

I've started interviewing candidates for Software Development positions many years ago, even before I started managing teams. For a long time, though, I absolutely sucked as an interviewer, and this is something I only know in hindsight. In those first years, I've received neither training nor feedback with regards to interviewing.

If you've ever interviewed as a candidate, you've more than likely had at least one bad experience, and most others were mediocre. That's because most interviewers do not receive any training, they're simply thrust into the job of doing interviews, and the only thing they know how to do is the same crap they've experienced when they were interviewing as candidates themselves. There's also a pervasive mindset that many interviewers share: They view the interview process as one-sided, i.e. the candidate needs to convince them why they should hire them, but there's no burden of proof on the company/interviewer. There's a big power imbalance.

I've had a few terrible interviews of my own in my younger days. I once interviewed for a telecom company that had the messiest offices I have ever seen in my life. It was chaos. The manager interviewed me in his filthy office full of dirty network equipment that was thrown everywhere. After the "main part" of the interview he asked me to step aside while he deliberated with a colleague about whether to hire me. He opened a door that led to a stairwell heavily stinking of cigarettes, where the lights were broken. I was left standing for several minutes in pitch black while they decided whether I was worthy of getting their shitty job. When they let me back in, the manager said they wanted to offer me the job, but felt it important to mention that it was a real job, where you don't go home just because your contract hours were over, and you're expected to give your all to the job. I stood up and left, didn't say a word.

That's one reason why I get embarrassed when I think back to interviews I handled myself in my career. I made many of the common interview mistakes:

1. I would not properly introduce myself. Sometimes, not at all.
2. I would consider the process one sided: the candidate needed us, not vice versa, and the burden of proof was only on them.
3. I was disorganized, and wasn't always sure how to proceed.
4. I quizzed the candidates on pointless programming trivia that for some reason seemed important to me.
5. I was intent on finding candidates that perfectly fit what I considered to be the ideal employee, from a skills perspective, which in practice meant no one.
6. I conducted the interviews in uncomfortable locations (whatever the company assigned).
7. I was blind to the candidate's body language.
8. I didn't really care.

As time went on, I started noticing the bad aspects of my interviewing process, and most importantly, I started caring, so I read up on the subject and began testing different processes, and tweaking various aspects of them. I continued to hone my skills until I reached a high level of proficiency, as was evident by both the number of high-quality candidates I had hired, and the positive feedbacks the companies received from pretty much every candidate I had interviewed, including those who were not hired.

Why You Should Care

It's possible that you're reading this because your employer is asking you to interview candidates, despite you not really wanting to. Maybe you're an entrepreneur building a new team and you have no choice. Here's why you should really care about the interview process and the ways to improve both it and yourself:

• You will be working with whoever gets hired, and it's in your best interest that new hires are a good fit for your team and have good interpersonal skills that will allow you both to work well together.
• Interviewing candidates helps you work on and improve your own interpersonal skills. It is not that much unlike public speaking, of which many people are deathly afraid. Your ability to conduct a good interview process will provide a tremendous boost to your confidence.
• Being an interviewer is a good way to increase your rank in the company de-facto. When you're interviewing candidates, you're not just representing the company, you're also an active part of its growth process and you directly affect its future. Creating a better company is literally within your hands, and you want to feel that you're working for a company that cares. I'm not trying to take away from the companies' own responsibilities to create good work environments and proper interview processes, but you taking active part in them, and striving to make them better, will increase your metaphorical stock in the company.
• While it's reasonable to believe that most software developers will choose the job that pays them the most, many developers will actually prefer a job where they've had a positive interview experience over one that pays a bit better. This can give you an edge over wealthier companies. This is anecdotal, but I have enough experience to consider this true.

The Interviewer Mindset

The first and most important idea that you must adopt is that the interview is a bidirectional process. You're not only interviewing the candidate, the candidate is interviewing you, if only implicitly, and that's a good thing: both sides need to figure out if they fit each other, and as much as you're trying to get to know the candidate, the candidate will be trying to get to know the company, through you. It's your job to be a good representative of the company (and by good I mostly mean "accurate"), and you should strive to inform the candidate as well as possible of what it's like to work for the company or the team, even if they don't explicitly ask. Many candidates are so nervous—not to mention hold the mindset that they're there to convince you to hire them and not also vice-versa—that they ask no questions.

The second idea is that chemistry and interpersonal skills are just as important as programming skills, if not more so. You should strive to leave the interview with as clear an answer as possible to the questions "do I want to work with this candidate? Can I expect them to properly assimilate into the team? Will I be able to depend on them?"

The third idea is that you need to provide the candidate with as comfortable an experience as possible, in order to be able to get as clearer a picture of them as possible. Interviewing is a stressful situation for pretty much everybody, and it's a kind of stress that isn't particularly representative of a person's ability to perform under pressure, so you can't always reach the conclusion that a person doing poorly in an interview due to stress will also perform poorly under pressure while on the job. Even the most seasoned, experienced engineers have difficulty in an interview setting. If you create a relaxed atmosphere and successfully relieve some of the pressure, you'll see more of the candidate's true self.

The fourth idea is you want people to want to work with/for you. An enthusiastic new hire has a much better chance of assimilating and providing results quickly. You want to hire someone who's genuinely excited to be hired, not just hoping for the nightmare of interviewing for multiple companies to end; but don't expect them to come with that excitement, it's on you to get them excited. A positive interview experience will greatly help to achieve that. Also keep in mind that while the software engineering "community" is not small, word does get around. Candidates who have bad interview experiences will tell people about it, and this can hinder your ability to hire. Similarly, candidates who have good experiences will also tell people about it. I've had candidates who were not hired, but still had a good enough experience interviewing that they recommended to friends to apply as well.

The final idea is that you need to be flexible. You will not find the perfect candidate. You will not find a candidate with 16 years of experience developing in the Go programming language, or one who knows the language down to its core. You won't find someone who has worked on systems with the exact same architecture as yours. This is actually an important concept for both sides. There's nothing that turns me off more than a candidate who tells me something like "I only want to work with Python". What kind of bullshit is this? So hire a candidate with good technical skills, even if those skills are not in the exact same stack you were hoping them to have. If they're able to show technical proficiency in something, then they probably have the ability to learn a new language or a new stack. Similarly, don't just reject a candidate because they don't fit the job description of the specific position the interview is for. Learn what else the company is looking for. I've had candidates who clearly did not fit the specific position I was hiring, but I believed were a good fit for other, related positions in the company, and some of them got hired for those positions.

My Interview Process

I will be elaborating on the different parts of the interview process in a moment, but for now I would like to detail the general process I have settled on after many years of interviewing. I consider it as a sort of a checklist, one that ensures I never forget to do basic things like introducing myself ever again.

1. Room preparation: I prepare the room where the interview is going to take place. I print the candidate's résumé so that I have it with me. I fill a pitcher of cold water, bring a few cups, and set them on the table; the candidate will need this. I also bring a pad of paper and a pen.
2. Personal introduction: I welcome the candidate, and introduce myself, mentioning my name, my position in the company, and a very short summary of my career (or, in other words, how I wound up in my job). This may sound weird for you to tell the candidate about your own professional history, but I found that it helps establish the interview as a two-way street, it relieves some of the pressure off the candidate, and they often seem interested and even appreciative. It's actually not uncommon for candidates to ask me follow up questions. In any case, this should take no more than five minutes.
3. Company introduction: I introduce the company, as much as is necessary, from a largely business perspective. If it's a startup with a relatively short history, I will talk about that history a bit, and describe the company's product(s) as succinctly as possible. I may mention the investors of the company, I find startup interviewees are often interested and require reassurance that the company has enough funding to last more than a few months. I will then quickly talk about the specific team for which the candidate is interviewing, and the team's part of the company whole. Takes another four or so minutes.
4. Position introduction: I will talk about the position a bit, describing what we're hoping to achieve by hiring for that position, and what the responsibilities will largely look like. Probably two or three minutes.
5. Candidate history: I ask the candidate to talk about themselves, detailing their professional history, and whatever they think is relevant to the interview. I find that I can absorb the information better if I ask the candidate to elaborate on certain topics as they are talking, otherwise I can quickly forget. For example, if the candidate mentions a certain system they worked on, but doesn't volunteer what aspects of the system they worked on, I will ask them. I often use this information later on in the technical section.
6. Candidate desires: I ask the candidate why they left their previous job (if relevant, or why they're thinking of leaving their current job), what kind of job they're looking for, how they want to see their careers evolving, etc. The latter two questions often stymie the candidates, and while it doesn't disappoint me when it does, I absolutely love it when the candidate is prepared for this question, which doesn't happen often. The reason I ask comes from personal introspection. There have been several cases in my life where I never asked myself that question when pursuing certain things, and being asked that question by someone else put me on the spot and forced me to look within myself, which truly changed things for me. So I ask these questions because chances are I am going to get an honest answer, even if it takes the candidate a few minutes of silence before it finally comes out, and it helps me to decide if the candidate is a good fit for the position and the company, and vice-versa.
7. Technical skills: I attempt to gauge the candidate's technical skills, and get a feeling for what it's like to work with them. This is the longest section of the interview, and I elaborate on it later on.
8. Candidate questions: I allow the candidate to ask whatever questions they have. If they don't have any questions, I insist.
9. Next steps: I quickly describe the next steps of the hiring process, as relevant.
10. Goodbye: I make sure to thank the candidate for taking the time to interview with us, and wish them good luck.

My interviews average 60 minutes, sometimes more, sometimes less. I think my shortest interview was 30 minutes. If this amount of time, or this process, seems excessive, I respect that opinion but disagree. People deserve basic respect, and while making decisions as quickly as possible can be a good thing in certain situations (and I know you have your own deliverables to work on and you don't have time to spend on interviews), these are human beings we're dealing with, and I'd prefer not to be too quick to hire or reject someone before I got to know them better. My longest interviews, by the way, were usually my better ones, with candidates who got hired, and we both enjoyed the process. You will see why interviews may get longer when you read the next section.

Gauging Candidates' Technical Skills

Many software developers that interview other software developers are naturally inclined to quiz candidates on their technical knowledge. After all, that's probably the biggest reason management has asked you to interview candidates in the first place. Problem is, it's a very hard thing to do, which is probably why so many companies resort to pseudo creative interview techniques like asking contrived questions about imaginary, hypothetical scenarios, based on a theory that it will tell them something about the candidate's ability to solve problems or some such.

Gauging a candidate's technical abilities is even more difficult when the interviewer's technical experience and the candidate's technical experience do not match. I've had a very varied career so this hasn't been that big of an issue for me, but it's not uncommon for me to have negligible to non-existent experience in certain technologies and domains for which the candidate does have experience. As such, my interview methodology has evolved through the years to one that allows me to gather as much information about the candidate as possible in a relatively short time.

It's important for me to emphasise that during the technical portion of the interview, I am not looking for reasons to reject the candidate. I'm not waiting for that one question for which the candidate does not know the answer. I won't reject a candidate solely because they claim to have 6 years of experience programming in Python, but don't know what a context manager is. There are no gotchas. Instead, I am looking for reasons to hire the candidate, and for that I need information.

During the technical section I, therefore, strive to achieve the following:

1. Verify the candidate's résumé: I ask the candidate about the technologies they mentioned in their résumé. At the very least, I ask them to explain them. This works well with technologies I'm actually not familiar with. If the candidate's résumé mentions experience with PostGIS, of which I have zero knowledge, then I would ask them to explain what it is. The candidate's response can provide quite a lot of insight: Do they actually have experience with it? How capable are they of achieving proficiency in a technology they work with on a regular basis? How well can they provide technical explanations to other technical people? If you're an experienced developer, your bullshit meter should easily allow you to recognize bad answers, regardless of your knowledge of the technology.

   I wanna stress again that I'm trying gather information that I will take into consideration in my final decision, I'm not just trying to catch people who are dishonest in their résumé. I know it's considered by many to be okay to exaggerate on your résumé and to fake it 'till you make it, but personally I hate it. I prefer an honest person with almost no real-world experience than a dishonest person with experience. If a candidate mentions years of experience building RESTful web applications—as most résumés do—but can't explain what REST even is, then I'll be trying to figure out why. Maybe they do have experience developing RESTful web applications, but never truly bothered to learn about them. This is something that I will take into consideration.

2. See what it's like to work with them: I will often present a problem and ask the candidate to work with me on solving it. Most of the time, I will draw from the candidate's own professional experience, concocting a real world problem that can relate to a system they worked on, or ask them to build a system that is somewhat similar.

   For example, if I interview a candidate whose last job was working on a real-time video processing system, then I will ask them to build—in theory—a video processing system, or something similar such as a video analysis system. They're not actually going to write code (although they are welcome to put some code down on a paper, and sometimes I will ask), they're going to "describe" code (and architecture), and I allow them to choose the programming language and whatever technology stack they want. I start small, and expand the problem as we go along.

   Initially, I may ask the candidate to describe an independent function that counts the number of occurrences of each hex color in every frame of a video file. As the candidate answers, and depending on the solution they are describing, I will ask questions such as "what happens if the video file is 16GB?", hoping the candidate will recognize that their solution loads the entire video file into memory, and impose a restriction such as "the system will only work on devices with 8GB of memory."

   In the beginning, I try to keep the problem domain as small as possible, and I am more inclined to ask questions that will show me how proficient the candidate is in the programming language they've chosen. I prefer to ask questions less related to syntax and more related to features. "Suppose our function can fail in several different code paths within it. How can we ensure the video file is properly closed without explicitly calling close in all these code paths? How will we return errors?"

   When I'm satisfied with the first stage, I expand the problem, asking the candidate to modify the function such that it assigns a value of "dark" or "light" to each frame, based on the ratio between darker and lighter colors. I give the candidate more information as necessary. Then I'll ask them how we can make the process faster, trying to see if the candidate has a proper understanding of concurrency. After that I may change the requirements such that the video is received from the network frame by frame.

   Later on I will require the candidate to expose the function as an HTTP server. I will ask about the API we will create, and introduce requirements meant to reveal the developer's understanding of HTTP. I find that most developers, despite working almost exclusively on web services and REST APIs, to be unable to answer a simple question such as "what is the format of an HTTP request" and "what are HTTP headers?"

   As we go along, I often improvise or change the direction I was planning to go through based on the candidates answers, or ability to answer. I will also ask them to diagnose potential issues in the system. For example, I will often tell the candidate that we've deployed the system (which is probably an HTTP service at this point), people started using it, everything was fine, we went to sleep, and we started getting calls from angry users that the system "isn't working", and ask the candidate to guide me through diagnosing the issue.

   My ability to expand the problem and tighten its requirements will be directly affected by the candidate's technical skills and experience. With junior candidates who have little experience I may need to keep the problem at a higher, more theoretical level. My ability to do the same with experienced developers interviewing for more senior positions is critical for me to recommend hiring them.

   This process not only provides me with a good picture of the candidate's technical skills, their critical thinking abilities, and their ability to achieve proficiency in a technology/domain; but it gives me an idea of what it's like to work with them. Great interviews are those that have a healthy back and forth between us. I like candidates who ask for more requirements and a clearer picture of the problem domain rather than just start saying things. Many candidates actually enjoy this process, and the further we go along, the more confident the candidate becomes.

3. Understand what kind of training this candidate will require, if hired, and how quickly I can expect them to deliver. Whereas the previous process was mostly within the candidate's supposed comfort zone, this time I will try to see how experienced the candidate is with our own technological stack and problem domain. If they're not, that's fine, but I need to manage my (and the company's) expectations.

   This is a much shorter process than the previous one, and I will often simply ask the candidate to say whatever they can say about their experience with our stack/domain, if they have any. The previous section was already enough to gauge their technical proficiency and learning ability, I just need to have an idea of the kind of training they'll need.

As I said, this is the longest part of the interview process, but at its end, I know the candidate a lot better and have a much better understanding of what to expect from them.

Ensuring a Positive Atmosphere

Remember that interview I had for that messy telecom company? I would never want to do something like that to a candidate. Unfortunately, sometimes it wasn't easy to provide a good setting for an interview. In a startup I worked for, as we were growing, our offices became more and more clogged up, such that sometimes the only places to conduct interviews were in those tiny rooms meant for making phone/video calls.

One time, I interviewed a candidate in one of those rooms, because the company set up multiple interviews at the same time, there was a management meeting just then, and no other room was available. The offices were a bit of a mess at the time, because the company got a shipment of computer equipment, so the glass window in that tiny room was blocked by two giant stacks of cardboard packages, and the only light in the room was somewhat dim. I was furious. The interview was terrible. After the candidate left, I went shouting to HR that we should be ashamed of ourselves for giving candidates such a bad experience, and that I refuse to ever interview anyone in those claustrophobia-inducing hell holes. From that point forward, we made sure never to have two interviews at the same time, and set aside a nice, comfortable, good sized, sun filled room for all interviews. You should put your foot down about that. No one should want to come work for a company that wouldn't show them basic common decency during the hiring process, I don't care how big your exit is going to be.

While interviewing, I take care to notice the interviewee's body language, looking for signs of abnormal discomfort or nervousness, so that I can take care of it. The interview process is stressful enough without outside stressors like an uncomfortable room or the candidate having a bad day, and helping them get more comfortable will do the both of us good. This help can often be something simple as a change of scenery. Trying another room, taking the candidate on a walk around the office for a few minutes, going to the kitchen area for a cup of tea and some cookies, whatever.

I once interviewed a developer who really gave signs of discomfort, to the point where she could hardly tell me about herself. When we made it to the technical section, she drew a blank on everything. I decided to start fresh, and took her outside for a cup of coffee. We sat down, and after a bit of chit chat, I just started talking about a fake problem I was having at work, feigning ignorance about how to proceed. She started chiming in, making suggestions, asking questions, drawing from her own experience, all the while oblivious to the fact that the interview was still going on. As we kept talking, she calmed down so much that we were able to go back in and officially finish the interview. While we ended up not hiring her, I think we both grew from the experience.

Please make sure to have a pitcher of cold water in the room, both the interviewer and the interviewee will be doing a lot of talking, and with the natural stressfulness of the situation, candidates easily dehydrate, especially in those shiny skyscraper building with that state-of-the-art ventilation system that ironically gives everybody terrible headaches.

Appendix 1: On Take-Home Assignments

Many companies give candidates a take-home assignment to further prove their technical capabilities. This can be a sort of test, or a programming assignment. While I am not against the idea, I try to avoid it as much as possible, but it can be a valuable tool in certain cases.

My intention is to have enough information about the candidate from the interview such that an assignment is not necessary. I will only ask the candidate to do one if I am still unsure after the interview, or I wish to give the candidate another chance, for whatever reason.

It's important to understand that your candidates will be stressed for time, and you have to keep your assignment on the shorter side. The candidate may be interviewing to multiple companies, some or all of whom have given them their own assignments, or they're still employed, so they don't have the time to work on a large assignment.

When I give an assignment, I make it somewhat similar to the technical section of the interview. I start small, and allow the candidate to expand their solution as time allows, making sure to emphasise that not providing a solution that answers all the extra requirements is totally fine. The most a candidate should work on an assignment is a couple of hours or so.

Most of my assignments are to write a library, one that I can simply import and test, but I'm more interested in reading the code than testing it. I have a unit test that automatically tests and benchmarks the code I receive from the candidates, and while it matters if some of the tests fail, I want to see how clear the code is, how well structured it is, how consistent it is. I can easily tell when a candidate's assignment is a jumble of copy-pasted code. It's not only about getting code that works and does what it's supposed to do. There's a lot of code that "just works" out there, but is unmaintainable because it's a big mess that literally scares developers.

Note that I require candidates to submit their work directly via email and to not publish it on GitHub or other public platforms.

If you are giving a take-home assignment to a candidate, you should take an effort to follow up with them, regardless of the company's official followup. This can be a simple phone conversation or an email describing your impressions, but on a few occasions I was still unsure after a candidate's assignment and invited them for a quick face to face meeting to go through their work, and most of these were eventually hired. It's also important to check with every candidate that was given a take-home assignment how long it took them to work on it and how difficult it was, if pretty much all candidates agree that it took a long amount of time, you'd want to modify it accordingly.

Appendix 2: How to Write Job Descriptions

Most job descriptions you read in the want ads are so useless it boggles the mind. Who writes these things? Probably HR, who doesn't have much technical knowledge, which is why they all seem to follow the same format:

1. A buzzword-laden, full-on novel about how the company is making the world a better place, and how their employees are floating on the clouds, living their best lives, putting their mark on the world. Bleh.
2. A confusing description of what the position is and what the developer's responsibilities will include, but really just a bunch of sentences about working with people in different teams and some abstract bullshit about improving a product and taking it to the next stage.
3. A 24-point listing of technical requirements that have nothing to do with reality.

These things are unreadable—not to mention the candidate who conforms with all their requirements hasn't been born yet—and I think most people don't read them, particularly those forwarded by staffing agencies. CVs are sent en masse to whichever companies are currently hiring. I therefore believe it's better to keep the job posting short and to the point:

1. A short description of the company, its problem domain, and what products or services it provides. No fluff, no bull.
2. A short description of the team, and the position within the team the posting is for, and optionally the current technological stack the team is working with (developers look for it).
3. A short list of skills you're hoping the candidate to have. If you feel the need to specifically mention technologies, only mention them as examples, and avoid using time as a measurement of experience. No "5+ years of experience required/recommended" bullshit.
4. Some humor can be good, but don't force it.

For example, here's a job posting for a fictional development position in a fictional company:

Ponzinet Technologies is hiring for a Senior Software Engineer position. The company is a young startup founded in 2021, providing a fast and efficient CI/CD platform as its initial offering. The company is funded by Bail Me Out Ventures, among other investors, and is expanding to meet the growing demand of customers.

This posting is for a position in the company's backend team, working on the engine that executes the actual CI/CD pipelines. As part of this job, you will work on expanding the product's range of supported programming languages, improving the system's efficiency, and implementing ongoing features and requirements.

Our system is a SaaS service written in Go and deployed on AWS, Azure, and GCP. The team is looking for a candidate who can demonstrate proficiency in any of the following skills:

1. Distributed system design, concepts such as member consensus (e.g. Raft), consistency, load balancing, etc.
2. Data analysis, SQL, graph databases, full text search, etc.
3. Linux programming, concepts such as concurrency, sandboxing, etc.
4. Cloud-native applications, technologies such as Docker, Kubernetes, etc.

That's it really. Keep it simple, keep it short, and avoid too strict and specific requirements. Chances are, nobody's going to read it anyway.

Appendix 3: How to Read Résumés

If you're interviewing candidates, chances are you're also reading their résumés (or CVs if you will) ahead of time as well. In some ways, this part of the hiring process is even more daunting than actual interviews. For a long time, it was important to me to read résumés in their entirety, but not only did that take a lot of time (we had a constant stream of candidates), it also made me angry. Most résumés I got were sent by staffing agencies, and they were terrible. Sometimes unreadable. Full of errors, bad formatting, useless information, and they were all basically the same. Often they were forwarding candidates who clearly did not fit the position we were hiring for. My main takeaway from all those résumés is that staffing agencies don't give a damn, and if this is what they get paid for, they should be out of business.

I always preferred a résumé that was actually written by the candidate, but even those were usually bad. It's hard to summarize one's own life in one or two pages, as is knowing what to highlight that would actually matter to those reading résumés. Add to this the fact that most résumés look exactly the same, and eventually it all becomes a fuzzy cloud of buzzwords and sentences that don't actually say anything. Ironically, those candidates that try to get creative and break from the norm also often end up creating unreadable résumés. But at the end of the day, it was simply taking way too much of my time.

Eventually, résumés stopped being that important to me before deciding whether to invite someone for an interview. Instead, I moved to quickly scanning through the résumés, looking at things like the number of jobs they've had (if any), the companies they worked for, how often they've switched jobs, and what technologies they worked with. If they mention a GitHub account or something similar, I will take a look. Formal education, by the way, was never important to me, although I do look at it. Even I don't have a degree in Software Engineering (mine is in Mechanical Engineering). After that, I forward those résumés that seem to fit the job description to HR for an initial phone call, for which we established some basic guidelines together. Those candidates that HR also feel are a potential fit are invited for an interview.

As mentioned previously, it is in the interview where a résumé becomes more important to me, as I go over it with the candidate and attempt to verify it, or ask questions about points that are not clear enough in the résumé. I often highlight certain sections of the résumé, either before or during the interview, to make sure I remember to address them.

Appendix 4: But My Workplace Sucks, Why Would I Do This to Someone?

To make it better. If it really sucks as you claim it to be, quit.