Added post about interviewing

.astro/types.d.ts

@@ -159,6 +159,13 @@ declare module 'astro:content' {
   collection: "blog",
   data: InferEntrySchema<"blog">
 } & { render(): Render[".mdx"] },
+"easy-wins-for-the-lazy-interviewee.mdx": {
+  id: "easy-wins-for-the-lazy-interviewee.mdx",
+  slug: "five-soft-skills-for-hard-tech-interviews",
+  body: string,
+  collection: "blog",
+  data: InferEntrySchema<"blog">
+} & { render(): Render[".mdx"] },
 "migrating-from-gatsby-to-astro.mdx": {
   id: "migrating-from-gatsby-to-astro.mdx",
   slug: "migrating-from-gatsby-to-astro",

src/content/blog/easy-wins-for-the-lazy-interviewee.mdx

@@ -0,0 +1,70 @@
+---
+title: Five Non-Technical Tips for Technical Interviews
+pubDate: 2024-11-07
+description: Technical interviews require soft skills too! Here are a few things that I'll do in a technical round to give myself the best shot at succcess
+imageDescription: An image of some software engineers working in an office
+heroImage: interview
+slug: five-soft-skills-for-hard-tech-interviews
+---
+
+Many tech companies separate "behavioral" and "technical" interviews into two separate calls. This makes it seem like a candidate's technical chops are the only thing being evaluated in a technical round.
+
+In reality, soft skills are extremely important, _even in a technical interview setting_, and need to be practiced too. 
+
+Here are a few techniques that I've found helpful. Hopefully you do too.
+
+## Play the Parrot 
+
+I'm confident that I understand a technical problem when I'm able to summarize it.
+
+After I've first read or listened to a problem, I'll often try to rephrase it back to the interviewer. I'll start by saying something like, "I'm going to repeat back this problem back to you, please let me know if I've got this right." And then I'll close with, "Is there anything that I missed here?" 
+
+Most interviewers will correct you if you get something wrong, which can end up saving your skin later.
+
+This approach can also spark conversation, which is great. Remember, solving the problem is only one piece (albeit the most important, usually) of the technical round. You're trying to make the case to your interviewer that they should hire you, and sparking conversation is almost always a positive, in my book.
+
+## Set yourself up for success
+
+Most technical interviews these days are conducted by default in online environments like CoderPad or StackBlitz. 
+
+If the company you're interviewing with tells you which tool they're using ahead of time, spend a few minutes getting familiar with it beforehand. This means learning the keybindings for compiling and running code, but also getting comfortable with how you're going to arrange it alongside Zoom, and figuring out any other operational tweaks you'll need to make to be efficient when writing code.
+
+However, when the actual interview starts, I'd also reccommend asking your interviewer if you can run the code on your machine, instead.
+
+Most companies are willing to let you do this, if you ask politely, as long as you aren't running an LLM. I'm significantly faster when I'm able to work inside of Neovim, and phrasing this ask in a polite way won't negatively impact your evaluation.
+
+For instance, try something like this: "I know that the problem is written in this CoderPad link, but do you mind if I copy and paste it into my local editor? I'm more comfortable editing code locally, if that's okay."
+
+## Handwave 👋
+
+Engineers are often told to "handwave" away difficult technical problems in a system design setting, but the approach is often de-emphasized in a technical (aka coding) round, too. This is a mistake!
+
+Often, there are "nice-to-have" parts of a solution that you don't have time to implement. This could be because the approach touches on bespoke techniques that you haven't mastered, like bit manipulation. There could also be optimizations that you don't have time to implement, like caching or tail-call recursion. Don't be afraid to acknowledge this, and move on. 
+
+Taking shortcuts in a technical interview is okay, as long as your interviewer is on board. It's sometimes even expected, and can reflect positively on you if you phrase it right: "This solution doesn't use caching, which could cause problems in a production environment when operating under heavy load. But implementing caching seems outside the scope of this problem, so I'm going to ignore it for now."
+
+In certain interview settings, you may need to come back and optimize the code later. For instance, in the FAANG circut, you may be expected to find a solution with optimal space and time complexity. 
+
+However, you're almost always better off finding a less-than-optimal solution and running out of time, than finding half of an optimal answer. Just make sure to verbalize these trade-offs, and get your interviewer to buy-in.
+
+## At the End, Talk about the Future
+
+You're never going to have enough time to code up everything perfectly in a technical interview. 
+
+There will often be a function you'd like to refactor, or an edge case you didn't handle. If you don't verbalize this to your interviewer, they'll assume that the code in your editor is what you'd ship to production when the meeting ends.
+
+Always allocate a few minutes at the end of a technical interview to talk about how you'd improve your solution. 
+
+I'll often talk about clarifying the separation of concerns, improving performance, improving code redability, or adding tests. Depending on the scope of the problem and how long you were given to solve it, you could even spend some time talking about how you'd improve the end-user experience. This last point is particularly important for frontend engineers.
+
+Some interviewers will ask these questions explicitly, but many won't. 
+
+Your interviewer can't see inside your head. Make sure they understand that you've thought about how to improve your existing solution, and wouldn't just ship that monstrosity to production.
+
+## Be Entusiastic, and Grateful
+
+Your interviewers have likely taken time out of their day to conduct your interview. As a candidate, it's easy to forget that they'd rather be doing other work, and that their time is valuable, too.
+
+Make sure to thank them for their time at the start of the interview, and at the end: "Thank you so much for taking time out of your day to conduct this interview, I know that this may not be the highest thing on your todo list, but I really appreciate it."
+
+Take some time to look up your interviewers ahead of time on LinkedIn, if you want to make this even more personal. Buying some goodwill with this acknowledgement can help your chances when they evaluate you as a candidate, and could even make it more likely they'll be willing to help you if you get stuck.