How can we port our CS problem-solving strategies beyond traditional technical settings? During the second part of the semester, we'll tackle some case studies, taking inspiration from Waypoint 5: where could the algorithm be?
"Algorithms" broadly defined could appear outside of a traditional computational setting. When looking for algorithms, you should ask:
What problem is being addressed?
What is the input/output?
What is the instruction set?
Who is doing the "computing"?
What resources are constrained/used/optimized?
Describe an algorithmic challenge, using the following prompts:
Identify a problem that you have faced or are facing outside of the traditional computer science curriculum. Perhaps it is an interview for a job, an internship search, the question of how to network.
Focus on yourself as a "computer" -- what is your instruction set?
What questions do you have? What do you feel you already have a defined procedure for?
Scenarios
networking
internship/job search
logistics of moving
optimizing time/efforts during crunch times
Precisely formulate the problem
It can help to give sample input/outputs
What is the most specific scenario you can articulate?
Does it help to frame it as what your close friend would share with you?
Propose an approach
What "instruction set" are you working with?
Are there subproblems that you can identify?
Can you take inspiration from how a similar problem has been approached? From your own experience or others?
Check "correctness"
Try on different perspectives -- have you missed something?
Consider the analogy of a debugger -- you can set a breakpoint, then evaluate whether to step out/in/over across your approach's steps. Here, you might go back to a sample "input/output" scenario and pose some "what if" questions. For example, "what if I panic partway through an interview and stop speaking?"
Analyze the "complexity"
Are there different "costs" associated with different instructions?
What are you trying to optimize?
Are there essentially absolute constraints that make an approach infeasible?
Thinking through "hypotheticals"
When we're programming, we are trying to predict how our code will be executed.
Changing abstraction levels (zooming in/out)
When we're debugging, it could be as superficial as a misspelled variable name or as deep as the mishandling of memory.
Identifying/abstracting patterns
Working lots of examples gives us insight into how to solve the "general" case.
Preparing for exceptions
We're always looking for where things will "break" -- what happens if we access an index not in the array bounds, what if two processes are trying to modify the same part of memory, where are the edges of what is possible for a computer.
In pairs/trios:
Take 3-5 minutes to formulate the "problem"
I suggest coming up with 1-2 specific scenarios where networking could occur.
Take 5-7 minutes to brainstorm a procedure. What sequence of steps could you take?
This may vary for each of you, so you will start to define your own specific procedures.
You may find some steps are straightfoward, some are "black boxes" (you know that it is possible to do, but not sure how to implement it). This might help identify subproblems to zoom into.
You could consider: each writing/describing your own and identifying differences/similarities.
Take 2-4 minutes to check "correctness."
Can you break your procedure on other inputs?
What exceptions could arise?
Try on different perspectives to help identify moments you might not have thought of initially.
[Time-permitting] Analyze the "complexity."
Is this procedure feasible?
What are the costs?
You might find that the cost values and feasibility change from day to day, not just person to person.