[Go Make Things] How to nail your job interview

By rahmat hidayat

Friday, April 11, 2025

​ This week, I'm sharing my best career and job hunting tips. So far, we've talked about coffee chats, how to find open roles, and how to write a kick-ass resume. Today, let's talk about how to nail your job interview. Let's dig in! (You can view the full series—and stuff not covered in this series—in the Go Make Things members digital garden. You can even bookmark you favorite stuff!) ADHD and interviews When you have ADHD (like I do), interviewing can be extremely stressful. You might ramble when answering questions. You sometimes forget things you know really well. You can get overwhelmed or thrown off by questions you weren't expecting. You might avoid eye contact. The interview process isn't always built for ADHD brains, but in this section, I'll teach you some tips and tricks to help you approach interviews with calm and confidence. The End Goal During an interview, employers are trying to understand two things: Do you have the skills and knowledge to do the job? Are you someone they could actually work with every day? Interviews are also an opportunity for you to figure out those same things about a prospective employer: Is this a role that that will let you grow and do your best work? Is this a team and manager you actually want to work with every day? Interviewing is a skill. If you don't do it often, you may find it really awkward and difficult at first. But because it's a skill, that also means you can learn it, and get better at it. Interview Questions For most jobs, there are four types of questions an interviewer will ask: Yes/No. Questions that can be answered with a "yes" or "no" response (more on this in a minute). Example: "Do you have experience with Sass?" Situational. Questions that ask you how you would handle a hypothetical situation. Example: "What would you do if you needed to complete a project with a JavaScript framework you'd never used before?" Behavioral. Questions that ask you to explain how you handled a real life situation you've been in. Example: "Tell me about a time when you had to complete a project using a new technology." Technical. These can take many forms, from theoretical "how would you approach this problem?" questions to multi-day take-home assignments. We'll talk about technical interviews more in another section. For most of these, there's a trick you can use to answer them more effectively. The STAR Method My favorite framework for answering most interview questions is the STAR Method. This is an ancronym that stands for… Situation Task Action Result To answer a question using this method, identify a Situation or Task you were in, describe the Actions you took, and then explain the Results you achieved. Remember, tasks make you an expense. Outcomes make you an asset that adds value to the organization. Use this format even for Yes/No questions. It allows the interviewer to learn more about how you work and solve problems, and demonstrates your ability to add value. Examples Let's look at some specific questions, and examples of how to answer them with the STAR method. "Tell me about yourself." I'm a front-end developer who specializes in responsive web design. For the last two years, I've been working at Animal Rescue Organization as a web developer, where I help manage their web presence. I was part of a redesign initiative to make their site mobile- friendly. As a result of the redesign, they doubled their annual donation revenue. "Do you have any experience with Sass?" Yes. In my role as a front-end developer at Animal Rescue Organization, I used Sass as part of our mobile-friendly website redesign project. I used variables and mixins to speed up our development process and ensure consistency in design. Nesting and small, modular files allowed us to keep our project organized while managing a large stylesheet. Again, you can see you're identifying a situation or task, talking about the actions you took, and identifying the results. This is a great response if you have the experience they're asking about, but what if the answer is "no?" In that case, you want to answer honestly and then talk about another situation in which you quickly learned a new skill. I haven't worked with Sass, but I'm quite comfortable learning new technologies. Before becoming a front-end developer, I was an HR professional. By using online tutorials like CodeSchool and building a network of mentors, I was able to teach myself web development very quickly. Most recently, I learned how write vanilla JavaScript instead of relying on jQuery. As a result, my scripts have one less external dependency and load faster. Technical Interviews Unlike many other types of jobs, web developer roles often involve a technical interview. This can take many forms… A technical quiz, where you're asked about specific details of methods and approaches, or what the output of a specific piece of code would be. Talking through how you would approach a particular challenge at a high level (often just aloud or on a white board). Take-home assignments, where you're asked to complete a project and turn it in. A code walk-through, where the interviewer reviews code you've written and asks questions about it. In my opinion, the technical quiz is a particularly bad way to assess technical skills. And it's the one that's most at odds with how an ADHD brain works. In my day-to-day role, I never have to remember the specifics of how something works. I look things up every day. What's more important is that I know what kinds of things to search for, how to combine different methods to solve problems, and how to structure code for easier maintainability. The other three types of technical interviews do a pretty OK job of figuring out how well you can solve problems and think through different coding approaches. Sometimes take-home assignments are paid projects. Often times they're not. I want you to value your time and skills. In my opinion, a company that asks me to participate in a technical quiz or an unpaid take-home assignment does not value me, my time, and my skill set. It's a red flag that makes me less enthusiastic about working with the company. I also recognize that at different points in your career or life, being picky about those kinds of things is a privilege that you may or may not have, so take my statement with a grain of salt. Earlier in my career, I put up with a lot more interview nonsense than I would now. Interview Prep There are a few simple things you can do to prepare for an interview… Study your own resume. You want to know your own background (and outcomes) inside and out. I find myself referring back to two or three examples that best highlight the value I add over and over again. Research the organization. Make sure you know their products or services, how they make money, and any big accomplishments they've had recently. If you can mention them as part of the interview, all the better. Bring a cheat sheet. I like to bring a notebook with me and use it as a cheat sheet during the interview (yes, you can absolutely do that). I write down two or three of my best work examples in the corner of the page so that I don't get nervous, draw a blank, and completely forget them. In particular, the cheat sheet is the ultimate interview tool when you have ADHD. Your brain has a limited working memory. Trying to keep all-the-things you need to know in your head is tough on the best of days. During the stress of an interview, it's basically impossible. Having the important stuff written down for quick reference frees your brain to focus on the interview itself. When I'm answering questions, I'll usually glance down at it and reference a handful of the most relevant past experiences several times using the STAR Method. Questions to Ask At the end of an interview, most interviewers will ask… So… do you have any questions for me? I like to have a few of these written down in my notebook so I don't forget them. A lot of interviewers will feel like you're "not engaged" if you don't have any. Some stock questions you might ask… Why are you hiring for this role? Is it a new role, or are you replacing someone? What happened to the person who was previously in this role? (if it's a replacement for someone.) What do you like best about working here? What do you like least? What do you do to ensure diversity and inclusion in the workplace? What tools or processes do you have in place to prevent developer burnout? Can you tell me about the last time you had a developer who was struggling in their role? What did you do to ensure they were successful? Are there any specific areas of opportunity that you'd like someone coming into this role to focus on? (That's corporate speak for "what is the team doing poorly today that you'd like to see them do better?") If some of these feels like the kind of questions an interviewer would ask a candidate, they are! Remember, this is where you evaluate if the company is a good fit for you, too. Interviews work both ways. Don't be afraid to ask hard questions, and be ready to sniff out bullshit responses. What's next? If you're interested, I also have some resources or negotiating a salary that I can share next week. If you have any questions not covered in the series, get in touch and ask! Like this? A Go Make Things membership is the best way to support my work and help me create more free content. Cheers, Chris ​ Want to share this with others or read it later? View it in a browser.​ ​

Did someone forward this to you? Get Daily Developer Tips.

Don't want to get these emails? Totally cool. Update your subscriber preferences.

You can also unsubscribe from all emails from me, including updates to products you've purchased.

113 Cherry St #92768, Seattle, WA 98104-2205

Share :

Facebook Twitter Google+ Lintasme