add pseudo directions

Author: mnfmnfm

Diff for: Pseudocode.md

@@ -0,0 +1,99 @@
+# Pseudocode
+
+## What is pseudocode?
+Pseudocode is fake code. This includes a combination of words and fundamental codelogic written out to complete an algorithm without any worry of the syntax.
+Pseudocode is language agnostic, which means anyone, regardless of their language, can read and understand what is going on before converting it into their language of choice. 
+
+There is not an 'official' syntax of pseudocode, just standard guidelines. Pseudocode is designed to stay lightweight and flexible allowing for many dialects to be used. 
+
+
+| Symbol        | Meaning           |
+| ------------- |:-------------:|
+| Not Equal    | ≠ |
+| Equal     | =  |
+| Greater than or equal to | ≥      |
+| Less than or equal to | ≤      |
+| Greater than  | >   |
+| Less than  | <      |
+
+#### Pseudocode does not have
+- colons (:)
+- semicolons (;)
+- curly braces for code blocks ({})
+- parenthesis (other than method signature declarations)
+
+#### Pseudocode does have
+- backwards arrows to set a value (←)
+- indentation to specify scope
+- equal sign for comparison (=)
+- keyword "DECLARE" when creating a variable in memory (no need to define type)
+- keyword "OUTPUT" when writing out to the console
+- keyword "RETURN" when returning a value out of a method
+
+### Example 1
+
+```
+ALGORITHM FizzBuzz(n) 
+//INPUT ← a non-negative integer n 
+//OUTPUT ← no return, output string
+for i ←  0 to n do 
+	if i mod 3 AND i mod 5
+		OUTPUT ← "FizzBuzz"
+	else if i mod 3
+		OUTPUT ← "Fizz"
+	else if i mod 5
+		OUTPUT ← "Buzz"
+	else
+		OUTPUT ← i
+```
+
+### Example 2
+
+```
+ALGORITHM Factorial(n)
+// INPUT ← non-negative integer
+// OUTPUT ← product of factorials
+if n ≤ 0
+    RETURN 1
+DECLARE number ← n * Factorial(n-1)
+RETURN number
+```
+
+
+### Example 3
+
+```
+ALGORITHM BubbleSort(A[0…n-1])
+// INPUT ← An unsorted array of orderable elements
+// OUTPUT ← array sorted in nondecreasing order
+for i ← 0 to n-2 do
+	for j ← 0 to n-2-i do
+		if A[j+1] < A[j] SWAP A[j] and A[j+1]
+
+```
+
+### Example 4
+
+```
+ALGORITHM SumOfLLValues(l)
+// INPUT ← Singly linkedlist with at lesat 1 node
+// OUTPUT ← non-negative integer
+DECLARE current ← l.Head
+DECLARE sum ← 0
+
+while current.Next ≠ null do
+    sum ← sum current.Value
+    current ← current.Next
+    
+RETURN sum
+```
+
+### Example 5
+
+```
+ALGORITHM Countdown(n)
+//INPUT ← non-negative number
+//OUTPUT ← none
+for i ← n down to 0 do
+	OUTPUT ← i
+```

Diff for: Testing_Workflow.md

@@ -0,0 +1,99 @@
+# Writing Unit Tests
+
+## Questions Unit Test Should Answer
+1. What are you testing?
+1. What should it do?
+1. What is the actual output?
+1. What is the expected output?
+
+## Shoulds of Unit Testing
+1. Should test a single aspect of a component
+    - Usually this means test should contain only a single assert
+1. Tests should not rely on running in any particular order
+1. Should be able to run repeatedly with same results given same input
+1. Should be fast
+1. Should be run often
+    - Many tools allow tests to run on file save, or even after every keystroke!
+1. Prefer simple assert statements
+    - Frameworks often contain advanced, and sometimes very handy, assertions. 
+        - E.g. `assertRendersTemplate('home.html')`
+        - These are awesome, but use sparingly. Simple asserts are usually more readable.
+
+
+## Example Tests
+
+### Given a function like...
+```
+def sum(a,b):
+  """ sum two numeric arguments """
+  
+  if isinstance(a, (int, float)) and isinstance(b, (int, float)):
+    return a + b
+
+  raise TypeError('argument must be int or float')
+```
+
+### Test the 'Happy Path' cases
+```
+def test_should_sum_two_integers():
+    expected = 3
+    actual = sum(1,2)
+    assert expected is actual, "sum of 1 and 2 should be 3"
+```
+
+```
+def test_should_sum_two_larger_integers():
+    expected = 1333332
+    actual = sum(1234567,98765)
+    assert expected is actual, "sum of 1234567 and 98765 should be 1333332"
+```
+
+### Test with less obvious values. E.g. zero and negative numbers
+
+```
+def test_should_sum_negative_numbers():
+    expected = 3
+    actual = sum(5,-2)
+    assert expected is actual, "sum of 5 and -2 should be 3"
+```
+
+### Test default argument values as needed
+
+```
+def test_should_handle_single_argument():
+    expected = 2
+    actual = sum(2)
+    assert expected is actual, "sum of 2 and nothing should be 2 because 2nd argument defaults to 0"
+```
+
+### Test acceptable argument types
+
+**Note:** Different languages handle floating point precision differently. Adjust your assertion as needed.
+```
+def test_should_sum_floats():
+    expected = 5.0
+    actual = sum(3.5,1.5)
+    assert expected == actual, "sum of 3.5 and 1.5 should be 5.0"
+```
+
+```
+def test_should_sum_integer_and_float():
+    expected = 5.5
+    actual = sum(3.5,2)
+    assert expected == actual, "sum of 3.5 and 2 should be 5.5"
+```
+
+### Test unsupported argument types
+
+```
+def test_should_accept_only_numbers():
+    # consult docs for how your test framework handles testing exceptions
+    with pytest.raises(TypeError):
+        sum('1',3)
+```
+## References
+
+- [What Exactly is a Unit in Unit Testing?](https://www.blinkingcaret.com/2016/04/27/what-exactly-is-a-unit-in-unit-testing/){:target="_blank"}
+- [10 Tips](https://dzone.com/articles/10-tips-to-writing-good-unit-tests){:target="_blank"}
+- [5 Questions Every Unit Test Must Answer](https://medium.com/javascript-scene/what-every-unit-test-needs-f6cd34d9836d){:target="_blank"}
+

Diff for: Whiteboard_Workflow.md

@@ -0,0 +1,99 @@
+# Whiteboard Challenge Workflow
+
+This file contains details on what is expected when completing a whiteboard challenge. Please refer to the visual as a guideline to what content is required for each whiteboarding challenge.
+
+![Example Whiteboard Image](assets/DataStructuresWhiteboard.PNG)
+
+## Overall Guidance on Whiteboard Workflow
+
+The steps in this document are meant to show you one solid workflow. It's a structure that works for most people to help them solve whiteboarding problems effectively.
+
+As you get started doing whiteboards, we suggest that you stick to the steps we recommend, in the order that we recommend. Once you gain more confidence in the process of whiteboard interviewing, you are welcome to deviate from this process *at your own risk*. If you find that pieces of the process do not work well for you, or make more sense in a different order, that's allowed! And during an interview, you should always be prepared for an interviewer to ask you to complete steps in a different order than you're used to, or to ask you to clarify your thinking even when your normal process would move on. Listening to and working with your interviewer is always the best option, and you should expect that not every whiteboard interview will go the same way.
+
+For an example of an instructor solving a whiteboard (quickly) with a modified version of this process, see [this YouTube video](https://youtu.be/9KAy1AampQc?t=1386){:target="_blank"}.
+
+### 1. Problem Domain
+
+Re-iterate the problem domain that you have been asked. This can be done either verbatim from the initial question, or a summary in your own words, whatever makes more sense to you.
+
+### 2. Visual
+
+Draw out what the problem domain is and visually solve the problem. Label all of the appropriate properties, define your input and output, and show how you will approach the problem towards a solution.
+
+(It's common for people to switch up the ordering on visuals/problem domain depending on the problem; sometimes, drawing a picture helps you understand the problem better, at which point you can write out the problem domain.)
+
+### 3. Algorithm
+
+The algorithm is a breakdown of what you need to achieve. This should be a bulleted list or a general overview of what you plan to implement later in the interview.
+
+The most practical way of creating an algorithm is often to focus on the example input/output in your visual. You should consider the steps that your algorithm will take to use the input in moving towards the output. This process of working through the problem yourself, and noticing the steps you take along the way, should naturally help you flesh out the steps that will be part of your algorithm.
+
+### 4. Big O
+
+Analyze the space AND time efficiency of the algorithm that you just proposed. You should revisit this analysis throughout the interview as you make updates to your algorithm during pseudocode/code/stepthrough.
+
+### 5. Pseudocode
+
+Write out pseudocode that defines your algorithm! Use the [pseudocode cheat sheet](./Pseudocode){:target="_blank"} as a guideline to what symbols are acceptable.
+
+### 6. Code
+
+Write out syntactically correct code in the language of your course to solve the problem presented. Your real code should be based off of your pseudocode.
+
+### 7. Test
+
+There are two main parts to testing. First, walk through both the problem domain and your solution to make sure that it both works and is efficient. This should be a careful, line-by-line stepthrough of your code, where you track variables in a written table along the way. It's very normal to start the stepthrough, realize that you have a bug in your code, and go back to your code to try and fix the bug; in this case, make sure to go back to careful stepthrough for any modified parts of your code.
+
+Secondly, you should talk about how you would test this code if you were writing unit tests. This means listing out a variety of test cases; your goal is to show the interviewer that you know what kinds of tests are useful to ensure that a function is working. At a minimum, you want to list out:
+- a standard input and output
+- a standard input that has a different output than your first listed i/o
+- some edge cases in how the data is structured; you'll probably list several of these (the array is already sorted! the tree is very unbalanced! the string is just the character 'a' twelve times! etc.)
+- the input is null/negative/zero (the "normal" edge cases)
+
+## Examples of What That Looks Like
+
+In the best possible interview, you might have all of the ideas that you need and be able to move in this perfect linear order. In most interviews, though, you won't have that perfect flow from step 1 linearly through to step 7.
+
+While no two interviews will look the same, here is one example of a normal interview process:
+
+- Step 1: You write down the problem domain as the interviewer reads the problem to you.
+- Step 2: You draw a picture of what that input will look like and write down what you think the output will be.
+- Step 1 Again: The interviewer corrects you: your proposed output is incorrect. You revisit the problem domain.
+- Step 2 Again: Now that you understand the problem better, you come up with a more representative visual.
+- Steps 2 And 3: You develop your algorithm. You show with arrows in your visual how you'll transform the input into the output, and write down a bulleted list of steps as you go.
+- Step 4: You analyze the runtime and space complexity of the algorithm you just proposed, using big O notation.
+- Step 4.5: The interviewer asks you why you've chosen to use a particular data structure instead of some other choice, and how that impacts your runtime and space complexity. You reason through the use of that data structure vs. alternatives verbally with the interviewer, and decide your choice of data structure was good, and you'll continue using it.
+- Step 5: You decide your algorithm has some ambiguity, so you start writing pseudocode that matches your algorithm.
+- Step "Oh No": You realize which part of your algorithm was imprecise; there's more going on in this problem than you realized. You go back to your visual and algorithm and try to work through how this new realization fits in.
+- Steps 2 And 3 And 4 Again: You figure out how you'll work through this issue, and add that into your arrows and your bullet points. Since you've changed your approach, you also change your estimate of the runtime/space complexity.
+- Step 5 Again: You keep working through your pseudocode.
+- Step 6: You write out syntactically correct code that matches your pseudocode.
+- Step 7: You start stepping through your example input from Step 2, walking through your syntactically correct code line by line.
+- Step "Oh No" Again: You realize as you step through that your code doesn't actually generate the output that you expected.
+- Step 6 Again: You debug your code and get it working on your example input.
+- Step 4 Again: Since you changed your code while debugging, you re-analyze runtime/space complexity.
+- Step 6 Again: You finish your stepthrough on the example input, and it's now generating the correct output.
+- Step 7, Continued: You list out test cases that you would want to test this program on.
+- Step 8: Whatever your interviewer says!
+
+## Advanced Whiteboard Interviewing: Making this process your own
+
+After practicing whiteboard interviews, many people find that they want to modify this process. Here are some common things students want to do, and our analysis of those options.
+
+### Skipping or Shortening the Problem Domain
+
+It's possible to have a successful whiteboard without writing the problem domain on the whiteboard first. It's often okay to just write a few notes of the important pieces of the problem and use a visual with example input/output to verify with your interviewer that you understand the problem. Be aware that some interviewers will not correct you if you are working on the wrong problem, so it is *extremely* important that you verify the problem domain verbally, even if you don't write it on the whiteboard.
+
+### Shortening Algorithm, Pseudocode, and Actual Code
+
+We include all 3 of algorithm/pseudocode/actual code because, for many people, each of those steps helps to refine their algorithm. The first iteration of the algorithm helps get ideas of thoughts down on the whiteboard; the second iteration helps ensure that those ideas will translate well into code; and the third iteration allows you to focus on your language's syntax. If you are a person who writes an extremely exact code-like algorithm, or if you are very comfortable with your language's syntax, you may find that the pseudocode step slows you down without providing any benefits. In that case, it's fine to skip the pseudocode step.
+
+### "Skipping Around" between Algorithm and Actual Code
+
+**It is almost always a bad idea** to figure out half of your algorithm, write code for that half of your algorithm, and then figure out the rest of your algorithm. If you have half a strategy, but have no idea how to do the second half, you'll often need to change the first half of your strategy once you figure out a complete algorithm. You run the risk of coming up with the start of your strategy, taking the time to write out code for that part of your strategy, coming back to thinking about your strategy, and realizing you need a different strategy and no longer need the code that you wrote. It's best to have some idea of how you'll solve the entire problem before you start writing code.
+
+There's one exception: sometimes you have the majority of your algorithm, and you're confident it will work, but you're not sure about some small piece (whether the loop should run n or n-1 times, or whether to use a HashTable or a HashSet, or something else insignificant compared to the "interesting" part of the algorithm). In that case, writing out your code and then coming back to the tiny-question afterwards is usually a good strategy; a good stepthrough will help you know the right solution.
+
+## Writing Headings on the Whiteboard
+
+Some people love writing the headings "Problem Domain", "Visual", etc. on the whiteboard to help them remember the steps they want to take. Other people find that feels robotic, and that they naturally flow among different parts of the whiteboard during problem solving. Either strategy is reasonable, as long as you're consistent (either lots of headings, or no headings).