diff --git a/behavioral-interview/README.md b/behavioral-interview/README.md deleted file mode 100644 index c5d1aca..0000000 --- a/behavioral-interview/README.md +++ /dev/null @@ -1,190 +0,0 @@ -# Behavioral Interview Pre-Reading - -## Intro - -A behavioral interview has two parts - -- The general impression you make -- Answering a behavioral question - -## General - -There are some things you can easily do to demonstrate your genuine interest in a role: - -- Be on time and prepared -- Look professional -- Have good energy - -### Being on Time and Prepared - -In order to ensure being on time, you should actually arrive early. - -If you are going to a physical location - -- Be sure to plan to arrive at least 15 minutes ahead of time -- You can stop by a nearby cafe or simply wait in the building lobby -- Use your extra time - - Use the bathroom - - Check your appearance - - Put your phone/laptop on do not disturb - - Check that you have everything ready to go - - Laptop - - Pen/pencil, paper - - Copies of your resume (even though this is becoming outdated, it doesn't hurt to have this) - -If you are doing a remote interview, make sure your computer is ready to go - -- Choose a location where you - - Can be sure the internet connection is stable - - It is quiet - - You can sit comfortably -- Your phone and other notifications are silenced -- Extra programs and tabs closed -- Test audio and video on your computer and with whatever app they are using (zoom, google meetings etc.) -- If you will be using a video app, or other apps that you are unfamiliar with, take some time to get familiar with the basics (how to mute/unmute, turn video on/off) -- Make sure you are plugged in or have enough battery - -- Make sure you have good lighting. Interviewers should be able to clearly see your face -- Your background should be simple or blurred -- Your laptop camera is positioned in a way that you can look (nearly) directly at it, this gives the illusion that you are making eye contact with your interviewers - -### Look Professional - -Whether your interview is in person or over video, your interviewers should remember you and not what you wore. - -Keep it simple and neat. Choose clothes that fit properly and you feel good wearing. - -Avoid trying: - -- New haircuts the day before (at least a week, in case it doesn't work out as you'd hoped/you have time to correct) -- New lotions/fragrances/grooming routines the day of, if you are committed to updating your routine, practice it several times before your interview - -### Have Good Energy - -We all cope with feelings of anxiety differently. We may - -- Be a nervous talker -- Shut down and only give single word answers -- Excessively fidget -- Slouch and avoid eye contact - -These kinds of coping mechanisms can come across negatively in an interview. You can work on improving how you interact on an interview when feeling nervous. - -You should aim to focus your energy on - -- Being open - - Activity listen - - Ask questions - - Look straight ahead (not at the floor/keyboard) most of the time, if you are in a physical space, look around - - Make eye contact -- Have positive body language - - [Positive Body language with Examples](https://blog.udemy.com/positive-body-language/) - -The way to work on these things is to practice. - -You can practice by: - -- Using a mirror -- Record a video of yourself and watch it back -- As a friend or family member to ask you some sample questions - -Though the above activities may feel unpleasant, they can really help you identify where you struggle and what you need to work on. - -## Behavioral Interview Questions - -### What are Behavioral Interview Questions - -Behavioral questions use past behavior to predict future behavior. - -Behavioral questions tend to start with - -- Have you ever ... -- Describe ... -- How did you handle ... -- Give me an example of ... -- Tell me about a time ... - -And they usually are looking for an example of something that was one of these six options: - -- Best/worst -- Success/failure -- Effective/ineffective - -These questions are trying to draw out how you are with (in no particular order) - -- Teamwork -- Motivation -- Prioritization -- Time management -- Initiative -- Conflict resolution -- Problem solving -- Adaptability -- Leadership - -### How to Answer Behavioral Questions - -You want to find the sweet spot of giving enough detail and not talking too much to get to the answer. - -You also want to have some situations and your response to talk about in mind. But don't memorize answers. Coming across as canned (predetermined/rehearsed/memorized) will be perceived negatively. - -It may seem like this each question requires a unique approach, but you can follow a formula to help guide you to answer any of these questions. - -### STAR Method - -The STAR method is a way to organize the way you answer these questions that will make sure your answer covers all the salient points and allows you to have an answer that is short and impactful. - -1. Situation - - A brief description of the context - - Who, what, where, when, and how -1. Task - - Explain what you had to do - - What were the specific challenges - - What were the constraints (deadlines, resources etc.) -1. Action - - What actions did you take to complete the task - - Be sure to highlight your traits without needing to state them - - initiative, dedication, teamwork, etc. -1. Result - - How did it turn out? - - If it is possible to quantify with numbers (We were able to reduce costs by 10%), then be sure to do so - -If you are asked a question that doesn't seem to match you can work your way through a similar example or ask if you should approach the situation hypothetically. - -### Extra Tips - -- Be sure to keep the description of the situation brief and really focus on the action. -- Focus on what you did, not your team, not others -- Diplomatic in your responses, the details of your situation should illuminate where the problem was coming from - - Avoid - - I worked with all incompetent people who didn't care about the job - - Lean into - - I was on a team where missing deadlines happened weekly for most of my teammates - -### How to Prepare - -It's really important to not memorize an answer. When thinking of your own examples and responses, you can prepare by creating a table and using key-words and phrases, then, practice building the rest of your response on the fly. You should reference this table before an interview to jog your memory, but otherwise allow your responses to come naturally. - -| Example of | Situation | Task | Action | Result | Trait Demonstration | -| :-------------------: | :-------: | :--: | :----: | :----: | :-----------------: | -| Best/Worst | | | | | | -| Success/Failure | | | | | | -| Effective/Ineffective | | | | | | - -For trait demonstration, use the following list and make sure you have enough stories to cover these (a story can demonstrate multiple traits) - -- Teamwork -- Motivation -- Prioritization -- Time management -- Initiative -- Conflict resolution -- Problem solving -- Adaptability -- Leadership - - - - - - diff --git a/behavioral-interview/activity/README.md b/behavioral-interview/activity/README.md deleted file mode 100644 index fcbdb3e..0000000 --- a/behavioral-interview/activity/README.md +++ /dev/null @@ -1,44 +0,0 @@ -# Behavioral Interview Activity - -In pairs, conduct a behavioral interview. - -Give each person a few minutes to get ready before beginning - -## Rate your peer on the following criteria - -1. Preparedness - - - Were they ready to begin right away? - - Were there any interruptions that could have been avoided (phone or email notifications turned off) - - Blurred the background of their video (if needed) - - Person sitting somewhere where they have decent lighting - - If they needed to mute/unmute, they were able to do so quickly because they had shut down unnecessary apps/windows - -1. Has Good Energy - - - Were they focused on the conversation? - - Were they looking into the camera/making eye contact? - - Had positive body language - - Avoided checking the time/their phone other distractions - -1. Used the Star method - - Situation was described - - Briefly - - Clearly - - Diplomatically - - Task was described - - Clearly - - Briefly - - Action was described - - Clearly - - With enough detail to highlight positive traits - - Result was described - - Clearly - - Briefly - -## Sample Questions - -- Tell me about a time when you faced a problem you couldn’t solve. What did you do? -- Give me an example of how you resolved a conflict with a coworker -- What do you do when you have a lot of competing responsibilities? Do you have a plan for dealing with stress? -- Tell me about a time when you made a mistake or missed a deadline. What did you do to reorganize yourself in order to complete the project? diff --git a/behavioral-interview/assets/.gitkeep b/behavioral-interview/assets/.gitkeep deleted file mode 100644 index e69de29..0000000 diff --git a/behavioral-interview/lesson-notes/README.md b/behavioral-interview/lesson-notes/README.md deleted file mode 100644 index 50dc606..0000000 --- a/behavioral-interview/lesson-notes/README.md +++ /dev/null @@ -1,26 +0,0 @@ -# Behavioral Interview Lesson Notes - -## Learning Objectives - -- Be able to know what it takes prepare for an interview, in person or via video -- Be able to explain what a behavioral question is -- Be able to explain the STAR method -- Be able to prepare for a behavioral question, using the STAR method - -## Guiding Questions - -- What are things that a candidate can do to stand out in a positive way -- What are the things that can make a candidate come across in a negative way -- Why is it important to avoid creating canned answers? -- How does the STAR method help shape a great answer to a behavioral question? - -## In Class Activity - -- In small groups, - -Have fellows discuss previous interviews they've had - -- What went well -- What they wish they did better - -See if anyone would like to share what they have learned from their prior interview experiences diff --git a/pairing-on-take-home/README.md b/pairing-on-take-home/README.md deleted file mode 100644 index 52f787d..0000000 --- a/pairing-on-take-home/README.md +++ /dev/null @@ -1,174 +0,0 @@ -# Paring on a Take Home - -## Why a Pairing Activity? - -Interviewers are interested in how you work with others. Do you collaborate well? Do you take feedback well? Are you adaptable and open to the style of coding at their company? - -One way they can check for this is by giving a practical activity such as going over your take home challenge and then asking you to collaborate with someone to add a feature or update your code based on a code review. - -When asked to pair, the goal isn't to impress the person with your coding skills silently. Rather, it is to actively collaborate and incorporate ideas, suggestions, and code from the person you are paired with. Additionally, employers are looking to see how you approach a problem as well as how you communicate about code. - -## How to approach pairing - -On a take home, you will typically be the person in the "driver's seat" when it comes to pairing. This means you'll be making the decisions of how to move forward on implementing a feature. - -It's best to approach pairing in the same way you would approach a technical problem: identify the problem, make a plan, implement the code, and then reflect back. - -### Identify the problem - -First, you will want to make sure that you understand the problem you are being asked to solve or the feature you are being asked to add. For example, if you are being asked to add a signup form to a page, you will want to gain clarity around the design and any required features. Before you start coding, you should feel confident that you know what it is you're attempting to build. - -### Make a plan - -Before coding, it's useful to think through what exactly it is you're going to do. This could look like talking through the implementation with your pairing partner before starting, writing pseudocode to outline your potential code solution, or doing both. Making a plan _before_ you start coding will be helpful in making sure you've thought through everything. It also provides an opportunity for your partner to make suggestions or correct any misconceptions you may have. - -### Implement your code - -Now is the time for you to actually write some code. During this phase, you will likely be doing most of the typing. However, as best as you can, talk through what you're doing so that your partner can follow along. - -One of the benefits of doing a take home challenge is that you're often not required to have memorized every bit of syntax. If you get stuck or can't remember how to do something, feel free to ask your partner. In a real pairing situation, your partner should be willing to look up syntax and point out any small mistakes that could cause problems. - -### Reflect back - -Once the problem is solved or the feature has been implemented, it's time to reflect back on what you just solved. Depending on the type of challenge, you may be asked to just reflect on what could be improved or you may be tasked with refactoring your code. Either way, this is an opportunity to highlight your skill at improving code to be more readable as opposed to just getting it to work. - -## Ways to improve your code - -Coding design has to do with following some good principles like writing clean and clear code, "YAGNI", "DRY" and "KISS." - -Let's review these principles, so that as you talk through your code you can help identify some of the design choices you are making. - -### Clean Code - -Writing clean code usually refers to your ability to do the following: - -- Name variables and functions in a way that express intent and improves clarity -- Write and structure your code so that it requires as few comments as possible to understand - -For example, take a look at the following function which adds two numbers togethers. - -```js -// This function adds two numbers together and returns the value -const x = (y, z) => z + y; -``` - -The above function is _concise_ but lacks clarity. The function name (i.e. `x`) tells us nothing about what the function is. The comment is needed because variables `y` and `z` don't give any indication as to the data type that is expected. And, the order of parameters and how those parameters are used are flipped. - -Contrast the above function with the following: - -```js -const addTwoNums = (num1, num2) => num1 + num2; -``` - -This function is much better. The name of the function describes its purpose and the parameters names give some indication as to how it should be used. This code is still concise but is much more clear. - -For longer snippets of code, it's possible that the code will be difficult to read not because of poorly named variables but because of the unclear intentions behind the code. For example, take a look at the following code below which will increase a value stored in an object by a certain percentage. - -```js -function increasePrice (product = {}, percentageIncrease = 0) { - if (product.priceInCents && product.priceInCents > 0) { - if (percentageIncrease >= 1) { - throw "percentageIncrease must be between 0 and 1."; - } - if (percentageIncrease < 0) { - throw "percentageIncrease must be between 0 and 1."; - } - - product.priceInCents *= (1 + percentageIncrease); - } else { - throw "priceInCents is missing or formatted incorrectly."; - } -} -``` - -This function performs a lot of error handling to make sure the values entered are properly set. While necessary, these checks obscur the true purpose of the function which is simply to increase the `priceInCents` key-value pair. - -There are a few approaches you could take to improve the readability of this code. One might be to use guard clauses at the beginning of the function. A guard clause stops the execution of some code early on so that the rest of the function doesn't run. In addition to at times being more performant, it also has the added benefit of improving deeply nested code. - -```js -function increasePrice (product = {}, percentageIncrease = 0) { - if (!product.priceInCents || product.priceInCents < 0) { - throw "priceInCents is missing or formatted incorrectly."; - } - if (percentageIncrease >= 1) { - throw "percentageIncrease must be between 0 and 1."; - } - if (percentageIncrease < 0) { - throw "percentageIncrease must be between 0 and 1."; - } - - product.priceInCents *= (1 + percentageIncrease); -} -``` - -These changes improve the overall clarity of the function by moving all of the error checking to the front of the function. Even more can be improved by removing some duplicate code. - -```js -function increasePrice (product = {}, percentageIncrease = 0) { - if (!product.priceInCents || product.priceInCents < 0) { - throw "priceInCents is missing or formatted incorrectly."; - } - if (percentageIncrease >= 1 || percentageIncrease < 0) { - throw "percentageIncrease must be between 0 and 1."; - } - - product.priceInCents *= (1 + percentageIncrease); -} -``` - -The code above is certainly an improvement from the original code. However, you could reorganize your code even further by using helper functions. - -```js -const validateProductPrice = (price) => { - if (!price || price < 0) { - throw "priceInCents is missing or formatted incorrectly."; - } -} - -const validatePercentage = (percentage) => { - if (percentage >= 1 || percentage < 0) { - throw "percentageIncrease must be between 0 and 1."; - } -} - -function increasePrice (product = {}, percentageIncrease = 0) { - validateProductPrice(product.priceInCents); - validatePercentage(percentageIncrease); - product.priceInCents *= (1 + percentageIncrease); -} -``` - -This code uses helper functions to encapsulate the various error checking. Those helper functions are then used inside of the original function. - -In this specific situation, building helper functions may not be necessary. However, if those validation functions could be used again, this could be a great way to clean up the code. - -For more on cleaning up `if` statements, you may want to view the following video: - -- [Cleaner IF statements// Clean Code](https://www.youtube.com/watch?v=2QWMrEHoMFA) - -### Acronyms - -There are a few key acronyms that are helpful to keep in mind as you refactor or improve your code. - -#### YAGNI - -This acronym stands for "[You aren't gonna need it](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)." - -This saying is trying to convey that it is important to stay focused on the required features as opposed to setting up your code for features that may exist in the future. - -#### DRY - -This acronym stands for "[Don't Repeat yourself](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)." - -The intention behind this saying is that you should look for code that is repeated and, wherever possible, remove it. - -#### Kiss - -This acronym stands for "[Keep it Simple](https://en.wikipedia.org/wiki/KISS_principle)." - -The intention behind this saying is to prioritize simplicity over complexity when solving a problem. Being able to write things in a simple and clear way demonstrates more skill and depth of knowledge than writing a convoluted or confusing answer. It also makes the code more readable and maintainable. - -## Resources - -- [How to Pair Program](https://www.wikihow.com/Pair-Program) -- [7 Tips for Navigating a Pair Programming Session During a Job Interview](https://www.techrepublic.com/article/7-tips-for-navigating-a-pair-programming-session-during-a-job-interview/) diff --git a/pairing-on-take-home/activity/README.md b/pairing-on-take-home/activity/README.md deleted file mode 100644 index 7e058e5..0000000 --- a/pairing-on-take-home/activity/README.md +++ /dev/null @@ -1,71 +0,0 @@ -# Paring on a Take Home Activity - -You will be paired with another fellow. Your goal will be to add a new feature to each of your take home challenges. - -You will divide half the time working on your take home challenge as the driver, and your partner as the observer. - -Halfway through, you will stop and switch projects and roles. It doesn't matter if you finished adding the feature to your app. Be sure to add, commit and push wherever your stopping point is. Submit your project to Canvas. - -Be sure to use what you've learned about pair programming. - -## Tips for the Observer - -First, take a few minutes to have your partner walk through their project so you are familiar with the code and current functionality. - -Decide, together, what feature you'll be adding. - -Be on the lookout for: - -- YAGNI -- DRY -- KISS - -Assist by googling things and keeping the big picture in mind. - -Ask for clarifications of the code you don't understand. - -Help make design choices. - -Ask about design choices your partner is making. - -Provide constructive criticism that is actionable. - -**GOOD** - -- I think using `.map()` would work better than using `.forEach()` here because ... -- This code is hard to understand, I think better variable names would be ... -- Let's pause working on the CSS and go back to getting the form to work properly -- I think this should be two functions since this function does x and y, where it would be good to handle those tasks separately - -**Bad** - -- I don't like how you wrote this code (What don't you like about it? What can the driver do about it?) - -## Tips for the Driver - -Make sure you explain a lot and keep talking. - -Remember, you are not your code. Be sure to be open to constructive criticism - -## Rubric - -Assess your partner on - -- Ability to problem solve - - Able to understand the problem that you (both) are trying to solve - - Communicate how they are breaking it down - - Explain possible solutions -- Demonstrate code quality - - Was your partner making good design decisions as far as - - Variable names? - - Code organization? (in this case following RESTful routes, the file and folder naming conventions that you've been following in class?) - - Code correctness? Was there any consideration of potential errors or problems with the initial solution? Were error handling/edge cases considered in designing a solution? - - Choosing a good order of what functionality is being built and explain why (for example) the route would be built first, and then the database query (or vice versa)? -- Communication - - Were you able to follow what your partner was doing? - - Was your partner explaining what they were working on? - - Were you given opportunities to participate/work as a team? -- Openness - - Was your partner open to your suggestions? - - Did your partner incorporate any of your ideas? - - Did your partner accept any constructive criticism? diff --git a/pairing-on-take-home/assets/.gitkeep b/pairing-on-take-home/assets/.gitkeep deleted file mode 100644 index e69de29..0000000 diff --git a/pairing-on-take-home/lesson-notes/README.md b/pairing-on-take-home/lesson-notes/README.md deleted file mode 100644 index a469b54..0000000 --- a/pairing-on-take-home/lesson-notes/README.md +++ /dev/null @@ -1,18 +0,0 @@ -# Paring on a Take Home Lesson Notes - -## Learning Objectives - -- Know what interviewers look for during a pairing session -- Know the dos and don'ts of pairing sessions -- Review - - YAGNI - - DRY - - KISS - -## Guiding Questions - -- What do interviewers hope to learn about you in a pairing exercise? -- What are the challenges of working with an unfamiliar code base -- Why is YAGNI important to understand and consider? -- Why is SOLID important to understand and consider? -- Why is KISS important to understand and consider? diff --git a/take-home-challenge-1/README.md b/take-home-challenge-1/README.md deleted file mode 100644 index 3d12c1d..0000000 --- a/take-home-challenge-1/README.md +++ /dev/null @@ -1,147 +0,0 @@ -# Take Home Challenge 1 - -Take home challenges are a great way to show off your coding skills. Often you'll be asked to code something that you have not done before or to use a technology you have not explicitly been taught. It is a great opportunity to level up your skill level and learn more about how different developers work at their companies. - -Regardless of the outcome, take home challenges are opportunities to broaden your understanding of the tech field and refine your abilities. - -## What are Take Home Challenges? - -Take home challenges are ways to gauge your coding ability by giving you a mini-project or a more complex algorithm to solve on your own time. - -After you work on it, you will submit your work and then you will likely get a follow up interview to talk through your project. You also may be asked to continue to build out a feature with someone from the company, so they can learn more about how you work with others. - -Take home challenges can cover a wide range of topics and skills, from CSS to APIs to full stack applications. While many take home challenges allow you to choose the languages and tools you use, others will require certain technologies are present in the developed application. - -Take home challenges often have an estimated time for completion. This time is usually between 2 and 8 hours. Sometimes they will time you (send you the challenge at 10am and expect a submission by 2pm) and sometimes they will tell you to work on it over the span of 2 - 7 days. - -## Ending an Interview Process - -You have the right to decline a take home challenge if the challenge is very unreasonable. For example you can decline if it is expected to take 2 weeks of full-time work, if the company expects you to pay money to take some sort of test, or if the take-home is on cyber security and that is not your interest or doesn't match the job description. In the unlikely situation this occurs, politely tell them you are not interested in continuing and then the interview process will be over. - -Remember, the interview process goes both ways. Not only are they interviewing you to be a good fit, you are interviewing them to see if you would fit in with them. Walking away from an interview can be a tough choice, but you must set your best interests first. - -However, if the take home challenge seems doable but difficult, consider doing your best anyway. While company's should not take advantage of your time, they are unlikely to give you work that is easy. - -## Expectations - -Even though take home challenges give an estimated time, if they are not setting a strict time block, it will likely take you longer. Estimating how long a project will take is difficult, both for the people administering the take home challenge and for the people taking them. - -Usually there are some minimum expectations. Doing the bare minimum is usually not enough in a competitive job market. Most take home challenges will list additional features or other aspects of the project they are looking for such as having clean code or a responsive design. - -However, you also don't want to overdo it. If the challenges is supposed to take 4 hours, but you spend 40 hours on it, that typically doesn't go over well either. - -As we go through more tips and tricks, you will get a clearer picture. Additionally, we will give you some practice take home challenges so that you get a better idea of what they are like. With these practice challenges, you can talk to your instructor about expectations and clarify whether you have the right approach. - -## Getting Started - -### Read and Understand the Prompt - -The first thing you want to do when you get a take-home challenge is to read all of the instructions, carefully. - -Take notes, make bullet points, and write down any questions you have. - -Take home challenges are not only checking for your ability to code, but also check how well you follow instructions, how well you work on your own, and possibly, how you ask for help or clarifications. - -For example, imagine you are asked to build an interactive weather application but it is unclear whether or not you should use vanilla JavaScript, React, or another front end library to build the application. It's good to get clarification if there is an expectation (or preference) to build with a certain technology. - -### Plan - -Depending on tasked required of you, you may want to create wireframes or user stories. These are assets that you can share as part of your completed take home challenge. - -Don't plan or add extra features before completing the required functionality. It may feel exciting to add Google maps, but if it is not asked for, do not do it unless the required work is complete. - -Figure out the order of what you are going to build and then estimate the time you think each portion should take. This will help make sure you manage your time better. - -### Build a Hello World App - -It is tempting to jump in and build everything at once. Slow down and build a very simple app and make sure it is set up correctly. - -This is even more important if you are working with a language or tech you are less/not familiar with. - -- Use git and GitHub as the company recommends. -- Set up the configuration. - - Create a `README.md` and write down the instructions on how to get your app up and running. Reference a lab or project with good instructions to help guide you. - - Steps like running `npm i` should not be taken for granted, write out each step required, like a very simple recipe to follow. - - If a `.env` file is required, be sure to include steps for that and what the environmental variables should be. -- If it is supposed to be deployed, make sure to include a link to your deployed application, as specified. -- Follow all submission instructions carefully, making sure to send over the project in whatever format the company determines. - -Do not forget to `git add` and `git commit` once the basic app is working. Be sure to write descriptive commit messages. - -Be sure to `add` and `commit` often. Use branches when adding new features or if you realize you need to refactor the code. - -### Build the Rest of the App - -You should build your app in this order: - -1. Make it work - all basic required functionality. - -1. Improve your code quality. - -- Go back and proofread your code and make sure you fix indentation -- Improve your comments, improve your variable names etc., -- Use the same version of syntax (if you use `const`/`let`, don't sometimes use `var`, declare your functions in the same way (unless you have a specific reason not to in a couple places) etc.)) -- _Note:_ If you struggle with indentation and consistent code formatting, consider installing a linter/code formatter like `prettier`, adjust the settings so that it will automatically format your code for you on save. - -1. Improve the look of your application by styling your application to look like a professional website. - -- _Note:_ If this is a front-end focused challenge that comes with a specific mockup to match, be sure to spend more time matching the mock-up. Be sure to use the provided fonts and colors and any other provided specifications. - -1. Improve the overall functionality of the application. This could include handling edge cases or gracefully handling errors. - -**Bonus** - If it is an option, use tests/implement TDD. Especially if you know the company uses tests/TDD or if they have it as a stretch/bonus feature. You can look back at previous labs that had testing for examples. - -**Bonus** - Make it fast. This is typically not necessary for a junior level position, but if you can find ways to make the app faster, it is recommended. As you progress as a developer, this optimization should be something you definitely take into deeper consideration. - -### Common Mistakes - -- Not managing your time well and scope creep - - - Make sure you stick to your plan. If you are going over time, try to understand if it is because you are stuck or if you are trying to do too much. - - Maybe you thought you would add a cool CSS animation that was not asked for, and suddenly you have spent 3 hours trying to get it to work. Go back to the basic button so you can focus on the main goals of the task. - -- Don't try to learn too many things at once - - - If the app is supposed to be built in React, this is not the time to experiment with redux, mobx, graphql, and formik all voluntarily at the same time. Stick to what you know, at least until you complete the basic requirements for the application. - -- Make too many assumptions - - - If you are not sure, ask! - - Try to be sure you understand the challenge and ask for clarity as soon as you can. However, if you've missed something, you can always send a follow up email to clarify. - -- Being too creative with your code - - - Avoid your own unique code formatting. - - Avoid building a mobile app when you were asked to build something in the browser. - - Avoid using an obscure new technology that no one has heard of. Stick to the mainstream tools, libraries, and techniques. - -- Copying code - - - There are many tutorials out there that may show you how to build a weather app or similar to the project you are building. - - Never submit a tutorial. - - You can use a tutorial to learn things but then you should close the tutorial and code examples before building your own version. - - If you get caught using someone else's code, the interview will be over. - - If you submit something above your skill level and get the job, you will not last long at the job. - - If you end up using a small piece of code from Stack Overflow, make sure you can explain it. Or, rewrite the code in away that you understand. - -- Coding without preparation/planning - - It may feel like you don't have time to plan, but planning is what will help ensure you complete the task in a sensible way that adheres to the specifications. - -### Summary - -- Read the instructions -- Get clarifications -- Plan -- Build a simple hello world app and make sure all your configuration is set up (git/github, database, deployment etc) -- Create a README.md with clear steps on how to get your app up and running -- Make sure you build the most basic version of the app -- Polish the basic version -- Add a small write-up in the readme about the project - - Design decisions - - Examples - - Potential improvements - - [An example of a write up](https://youtu.be/DU0LAeq0Uc8?t=379) -- If you have time, try adding even more polish or a challenge recommended in the take-home assignment -- Submit it on time/early - -- [The Essential Guide to Take-home Coding Challenges](https://www.freecodecamp.org/news/the-essential-guide-to-take-home-coding-challenges-a0e746220dd7/) - **CAUTION** links inside this document for `Ultimate Guide` seem to be broken/ reroute to advertisements (Spring 2022) diff --git a/take-home-challenge-1/activity/README.md b/take-home-challenge-1/activity/README.md deleted file mode 100644 index 7110522..0000000 --- a/take-home-challenge-1/activity/README.md +++ /dev/null @@ -1,5 +0,0 @@ -# Take Home Challenge 1 Activity - -Prior to starting, [Watch this video](https://www.youtube.com/watch?v=DU0LAeq0Uc8) - -Your instructor will provide you with the link to the take-home assignment. diff --git a/take-home-challenge-1/assets/.gitkeep b/take-home-challenge-1/assets/.gitkeep deleted file mode 100644 index e69de29..0000000 diff --git a/take-home-challenge-1/assets/all-features.png b/take-home-challenge-1/assets/all-features.png deleted file mode 100644 index 0fb4bd5..0000000 Binary files a/take-home-challenge-1/assets/all-features.png and /dev/null differ diff --git a/take-home-challenge-1/assets/landing.png b/take-home-challenge-1/assets/landing.png deleted file mode 100644 index 48be7e7..0000000 Binary files a/take-home-challenge-1/assets/landing.png and /dev/null differ diff --git a/take-home-challenge-1/assets/multiple-searches.png b/take-home-challenge-1/assets/multiple-searches.png deleted file mode 100644 index e2856c4..0000000 Binary files a/take-home-challenge-1/assets/multiple-searches.png and /dev/null differ diff --git a/take-home-challenge-1/assets/single-search.png b/take-home-challenge-1/assets/single-search.png deleted file mode 100644 index 66088e8..0000000 Binary files a/take-home-challenge-1/assets/single-search.png and /dev/null differ diff --git a/take-home-challenge-1/lesson-notes/README.md b/take-home-challenge-1/lesson-notes/README.md deleted file mode 100644 index 8ae1d6b..0000000 --- a/take-home-challenge-1/lesson-notes/README.md +++ /dev/null @@ -1,55 +0,0 @@ -# Take Home Challenge 1 Lesson Notes - -## Learning Objectives - -- Understand what a take home challenge is and what level of work is required for it -- Explain the steps you should take for a take home challenge -- Understand why each step is critical for your success -- Be able to name some common mistakes - -## Guiding Questions - -- How do you compare to other candidates if you do the bare minimum? -- What is the issue with going way above and beyond with the required specs? -- If you want your app to stand out, what are the best things you can do? -- What are some challenges you've faced with previous labs/assignments and how can you learn from those challenges? - -## In Class Activities - -## Activity A - -**Prompt:** Build a weather app using the [Open Weather API](https://openweathermap.org/api). Submit within 3 days of receipt of this prompt by providing a zip file. - -Build a landing page that has a text input and submit button for a location. - -![](../assets/landing.png) - -After submitting a location, it should show a component with the location and current weather. - -In addition it should have weather for today, tomorrow and the day after tomorrow. - -Finally, there should be a list of previous searches - -![](../assets/single-search.png) - -After multiple searches the page should update to look like this: - -![](../assets/multiple-searches.png) - -Stretch features - -- Create a temperature converter widget -- Add icons for the weather conditions -- Show more details about the current weather - -![](../assets/all-features.png) - -Type out over slack sample email text you would submit to an an interviewer about 1-2 clarifications about what is required. - -Discuss as a class - -## Activity B - -Everyone should read the take-home challenge prompt. - -Fellows should be given some time to ask clarifying questions as a class. diff --git a/take-home-challenge-2/README.md b/take-home-challenge-2/README.md deleted file mode 100644 index 84d1cd6..0000000 --- a/take-home-challenge-2/README.md +++ /dev/null @@ -1 +0,0 @@ -# Take Home Challenge 2 diff --git a/take-home-challenge-2/activity/README.md b/take-home-challenge-2/activity/README.md deleted file mode 100644 index 86748a0..0000000 --- a/take-home-challenge-2/activity/README.md +++ /dev/null @@ -1,7 +0,0 @@ -# Take Home Challenge 2 - -provide link to private repo. - -Add students to private repo. - -Do not allow students to review activity ahead of time to better simulate the timeline/experience of an actual take home challenge diff --git a/take-home-challenge-2/assets/.gitkeep b/take-home-challenge-2/assets/.gitkeep deleted file mode 100644 index e69de29..0000000 diff --git a/take-home-challenge-2/lesson-notes/README.md b/take-home-challenge-2/lesson-notes/README.md deleted file mode 100644 index 8661321..0000000 --- a/take-home-challenge-2/lesson-notes/README.md +++ /dev/null @@ -1 +0,0 @@ -# Take Home Challenge 2 Lesson Notes diff --git a/technical-interview/README.md b/technical-interview/README.md deleted file mode 100644 index 42f4d02..0000000 --- a/technical-interview/README.md +++ /dev/null @@ -1,27 +0,0 @@ -# Technical Interview - -## Review - -At this point, you should have had some experience doing technical interviews with your peers and instructors. - -Let's take some time to review and refine. - -First, get ready to take some notes. - -Watch this [Amazon Coding Sample Video](https://www.youtube.com/watch?v=mjZpZ_wcYFg) - -Take general notes on pointers, then take some time to write down what you do similarity and what you think you do well and what you need improvement working on. - -Be ready to work on the things you have identified for your next mock interview. - -## Coping with Feelings - -Doing a technical interview can feel very anxiety-inducing, but you can do some things to help you prepare to manage your anxiety. - -1. Feeling anxious is normal, for an interview it's a symptom of caring, don't be too hard on yourself if you feel anxious -1. Instead of telling yourself you feel anxious, [tell yourself that you feel excited](https://www.theatlantic.com/video/index/485297/turn-anxiety-into-excitement/) -1. Let yourself excited for an interview! An interview is a performance, like speaking in public or singing or acting. You can get yourself ready by coming up with a phrase like [Fired up! Ready to go!](https://www.theatlantic.com/video/index/513629/fired-up-ready-to-go/) to help you feel more confident and channel the right energy -1. Listen to music that helps you feel confident right before going in -1. Practice some [power poses](https://www.ted.com/talks/amy_cuddy_your_body_language_may_shape_who_you_are) - -No matter the outcome, realize that you will come out of it with experience and more knowledge than you had before. Each time you interview you will get something out of it that makes you a better coder and a better interviewee. diff --git a/technical-interview/activity/README.md b/technical-interview/activity/README.md deleted file mode 100644 index 31e79f7..0000000 --- a/technical-interview/activity/README.md +++ /dev/null @@ -1,43 +0,0 @@ -# Technical Interview Activity - -## Do a Peer to Peer Mock Interview - -Earlier, you were assigned to group A or B - -Find a question to ask a peer from the opposite group in order to simulate a real world environment where you have likely not seen the question before - -- [Group A](https://github.com/joinpursuit/peer-mi-group-a) -- [Group B](https://github.com/joinpursuit/peer-mi-group-b) - -## Rate your peer on the following criteria - -1. Understanding the Prompt - - - Asks clarifying questions - - Verifies assumptions (e.g. “would input ever be null?”, “would input ever be larger than a 32-bit int?”) - - Demonstrates understanding w/ example inputs & outputs (and/or a diagram) - -1. Designing a Solution - - - Identifies multiple high-level approaches (e.g. brute force vs. more efficient solutions) - - Determines time & space complexity of each high-level approach - - Selects appropriate data structure(s) and/or programming approach (e.g. iterative vs. recursive) - - Plans out all steps of algorithm (in written words or pseudocode) before coding - -1. Implementing a Solution - - Writes valid, syntactically correct code for the full algorithm (unless the interviewer cuts them off early) - - Uses proper indentation to make code readable - - Selects descriptive names for variables/functions that follow standard casing conventions - - Manually tests code by verifying output for sample inputs - - Able to track down bugs effectively without resorting to “guessing” what is wrong - - Solution handles edge cases -1. Presentation - - - Verbalizes thought process throughout - - Uses sufficient vocal volume - - Maintains positive tone and body language throughout - - Utilizes all available whiteboard space, or includes ample comments if coding remotely - -## Give Feedback Based on Criteria - -Using the above rubric, give feedback to your peer that you interviewed. diff --git a/technical-interview/assets/.gitkeep b/technical-interview/assets/.gitkeep deleted file mode 100644 index e69de29..0000000 diff --git a/technical-interview/lesson-notes/README.md b/technical-interview/lesson-notes/README.md deleted file mode 100644 index 48f7c41..0000000 --- a/technical-interview/lesson-notes/README.md +++ /dev/null @@ -1,38 +0,0 @@ -# Technical Interview Lesson Notes - -## Learning Objectives - -- Review strategies for technical interviews - -- Watch this video together: Watch this [Amazon Coding Sample Video](https://www.youtube.com/watch?v=mjZpZ_wcYFg) - -Use this rubric to discuss the interview and how the interviewee demonstrated the things that are being measured - -## Rate your peer on the following criteria - -1. Understanding the Prompt - - - Asks clarifying questions - - Verifies assumptions (e.g. “would input ever be null?”, “would input ever be larger than a 32-bit int?”) - - Demonstrates understanding w/ example inputs & outputs (and/or a diagram) - -1. Designing a Solution - - - Identifies multiple high-level approaches (e.g. brute force vs. more efficient solutions) - - Determines time & space complexity of each high-level approach - - Selects appropriate data structure(s) and/or programming approach (e.g. iterative vs. recursive) - - Plans out all steps of algorithm (in written words or pseudocode) before coding - -1. Implementing a Solution - - Writes valid, syntactically correct code for the full algorithm (unless the interviewer cuts them off early) - - Uses proper indentation to make code readable - - Selects descriptive names for variables/functions that follow standard casing conventions - - Manually tests code by verifying output for sample inputs - - Able to track down bugs effectively without resorting to “guessing” what is wrong - - Solution handles edge cases -1. Presentation - - - Verbalizes thought process throughout - - Uses sufficient vocal volume - - Maintains positive tone and body language throughout - - Utilizes all available whiteboard space, or includes ample comments if coding remotely