typo; throught -> through

docs/etiquette.md

@@ -16,7 +16,7 @@ As always, this is not an exhaustive list of ways to have good interview etiquet
 - **Thank people for their time.** Being an interviewer is hard and coordinating interviews is hard. Thank everyone (recruiters, coordinators, interviewers) for their time and assistance. It's the right thing to do and also reflects well upon you.
 - **Be friendly, gracious, and positive.** Attitude is so important in interviews. We often spend so much time thinking about cracking coding challenges that we forget that we're interacting with a human. Try to act like someone your interviewer would want to work with on a day-to-day basis.
 - **Don't be critical of the company or its processes.** When asking questions about how the company or project operates, you might find something that strikes you as not being a best practice. That's okay—there's actually probably a good reason they do things the way they do and, if not, maybe you can help fix things! But what you _shouldn't_ do is start telling the interviewer they need to fix their processes. This actually happens! Don't do it unless the interviewer explicitly invites you to (e.g., "we're having trouble doing [x] given the constraints, I'm wondering how you would approach the problem.").
-- **Know about the company, its values, and what you would be working on.** Every company wants to feel special. It's worth it to take 30 minutes or so to read throught a company's values and learn about whatever product you'd be working on.
+- **Know about the company, its values, and what you would be working on.** Every company wants to feel special. It's worth it to take 30 minutes or so to read through a company's values and learn about whatever product you'd be working on.
 - **Be honest/forthright.** It can be pretty obvious when you're making up a scenario to fit a question. Hopefully you have examples for each behavioral question, but if not, it's okay. Do your best to redirect to a hypotentical answer instead (e.g., "I'm not sure I have a great example of this from my past, but how I would generally want to approach a situation like this is...").
 - **Ask questions that demonstrate your interest in the role.** Ask questions about how the team operates, how the product fits into the organization's vision, and really anything else that makes you seem interested in the role. Note: I hope you actually are interested in the role, but at the very least you should make sure you _appear_ to be interested.