- Questions will not fully clarify, you will be asked to do so - Always ask interviewer for feedback - Should I make more tests? - Always communicate with interviewer thought process and analysis - I think the runtime will be this The key objective at the very end is to make the most performant / efficient answer. Don’t try to get to this immediately. Get it working first, then make it efficient. ### Mock Test ### Trends 1. make a simple form 2. make a request to an API 3. show the output ### Tips - Ask for feedback throughout - Do you have any further suggestions before I start implementing? - Do styling/CSS last - Practice RTK query for crud operations get, post, delete, update. ### Steps - Identify -> Elaborate -> Converge -> Implement **I’ll take a couple of minutes to frame my thoughts, and then we’ll discuss** - Clarify question, understand problem - The best candidates will spend a little bit of time asking clarifying questions. - Think of edge cases already - What’s going to be tricky or weird? What’s straightforward? Figure out the basic pieces that are easy to do, execute said basic pieces, then figure out the hard stuff. - Think of possible solutions and acknowledge their efficiency - Choose the best solution - Explain how your solution will work with a high-order approach - Components needed and how they will interact - Wait a second to see if they nod - Brute force solution - Optimize if needed - (verify against tests) - Add comments if needed The key objective at the very end is to make the most performant / efficient answer. Don’t try to get to this immediately. Get it working first, then make it efficient. 99% of people I interview don’t make it to the full end of the exercise, and that’s OK! I’m not looking for you to complete it 100% perfect and squeaky clean. Just because you didn’t complete the challenge doesn’t mean you won’t get hired. ### Looking for Do you know the basics of JavaScript and React? Can you take feedback without getting defensive or argumentative? How do you approach problems when first presented? When requirements are fuzzy or unclear, what do you do to rectify this? ### UMPIRE acronym 1. **U**nderstand Clarify/Ask Questions/Run through examples 2. **M**atch to known subcategory of problem (e.g. sliding window) 3. **P**lan your implementation (discuss overall plan, tradeoffs you made and justify them if needed) 4. **I**mplement 5. **R**eview and test your code for correctness 6. **E**valuate your code (Runtime/Space asymptotics) and point out possible improvements (edited)