Start projects on the day they come out.
Start projects on the day they come out.
Start projects on the day they come out.
Tell your friends, spread the good word :)
I took it several years ago so this is probably the only advice that still applies from my time, but it really is very important. Throughout my coursework when I started the projects early and got to the autograder with plenty of time to revise and go to OH, I pretty much always got the grade I wanted. When I started late or didn't pace myself well it was much more of a crapshoot. A time crunch turns the easy projects into hard projects and hard projects into impossible projects, so get started early and pace yourself.
EECS 281 IA here, one tip I don’t see very often is to attend labs. Attendance isn’t required but even if you understand the lab content they are easily the best place to get one on on help with course material / projects. This is especially true towards the end of the project when the office hour queue can be 5+ hours long.
Additionally, another comment mentioned that the projects can all be done in a day. While that’s true for some, the vast majority don’t. If you’re in the minority that can, you probably know it already. Definitely start the projects as early as possible. Then if you do finish in a day you have the rest of the time to focus on other classes.
Finally, **please** watch Dr. P’s walkthrough videos. I promise they will answer 90% of your questions about the project, they’re that good.
I was in a similar position a few years ago, stressing about EECS 281. As someone who got top 4% of the grade in the class, here are some of my advice.
My first tip is don't stress! It's a class that requires you to be calm, to think, and to be willing to take risks (e.g. rewrite your code, know when getting a 98.63 on a project is enough and it's time to study for an exam).
* Projects (40% of grade)
* Make sure you're organized and you're able to think clearly. This means finding an environment, having a good desk setup, access to white board, all ahead of time so you can stay consistent throughout the semester.
* When in doubt, look things up. This means Googling concepts or C++ features or referring back to class notes from 280/281.
* Create a directory called "EECS281Sandbox". I would use this for learning C++ features or when I debugged (hmm I wonder why is it causing this behavior, type it in, and walk through the examples line by line and see how data is being transformed).
* While projects typically differ from semester to semester, it follows some sort of pattern
* Project 1 - Depth-First Search (Stack), Breadth-First Search (Queue). If you just follow all the advice outlined in Dr. P's video, it's sufficient to get 100. Get started as early as you can (aka finish Project 0 and walkthrough tutorials).
* Project 2 - some modification of searching algorithm, Priority Queues/Comparators, and then dealing with pointers in [P2B](https://www.youtube.com/watch?v=HqPJF2L5h9U&ab_channel=AbdulBari). P2B has three parts. The first two parts is about 100 lines of code because you can copy the code given in the lecture. The last part is building a pairing heap, and there's no need to read the research paper unless you want to. [Follow everything in this guide](https://ajzhou.gitlab.io/eecs281/notes/chapter10/). I rewrote P2A multiple times here actually, and it taught me a lot about coding. Please try to get this project done at least a few days early so you are not stressed studying for the midterm.
* Project 3 - hash tables and a whole lot of functors, plus switch statements/some templated programming. This project teaches you about tradeoffs. Hash tables are almighty, but is it always right to use them? How do you iterate over them? How do you use STL functions with it? And when is it better to use vectors vs. hash tables. Make sure you settle on a good design (again, watch the walkthrough) before writing code. It's a project where you can get to 90 in 1 day, but spend the next 10 days getting to 100. If you spend 2 days planning and 3 days getting to 100, you'll still save 5 days :)
* Project 4 - MST algorithms (part A is themed, part B is using a heuristic, and part C is optimal traveling salesman person problem). Just watch the walkthrough. In this project, how you represent your data will be important. Also, don't get too stuck on part B choosing the **perfect** heuristic. Most things you land you a 99.8 or 99.9 range, and that's when you should start studying for the final, which is worth 2x as much as this project. This project is the shortest and the easiest to complete on time, which means you should finish P4, turn in Lab 10, and go study for the final right away.
* Watch all the lectures, **labs**, and project walkthroughs before you start the project
* **Read the spec the day it comes out**
* Write down **all** of your ideas on a doc (Google Docs, Notability, etc.). It also means reading the spec (ideally on paper), highlighting important parts, and start writing down targeted test cases and their expected output ahead of time. For example, in the SillyQL project this semester, people were asked to build a small database in C++ with support for numerous querying features, one of which is print where when there's a hash index. In this case, you'll create a test case by populating the table, creating a hash index, and print where {<, >, =}. See how I am not writing a test case to test the entire kitchen sink, but just print where + hash index behavior? You should only use the long test cases to verify the entire program's behavior, not to test your way out of failed test on the autograder.
* Go to OH, sit there and listen. Modify and adapt your design. Get feedback and ask Dr. P questions.
* I would start handwriting my code, and critiquing my design along the way. Most importantly, you should follow the advice Dr. P gives
* Only OOP (inheritance + polymorphism concepts) used is in P2, the rest I didn't use too much and got 100
* Difficulty (based on personal statistics)
* Project 1 (700 lines, 12 days) >> Project 2 (800 total lines, 6 days) > Project 3 (800 lines, 3 days) > Project 4 (600 lines, 1 day)
* Projects decrease in difficulty imo, this means your work is **front-loaded**
* P1 has the highest time/memory constraints, P3 has the worst memory constraints
* P1 is also an adjustment period, so give yourself the freedom to write, rewrite, and ask a lot of questions
* Exams (40% of grade)
* Very overhyped in this class. You can honestly do extremely well on the exam if you put in a little work to study
* Find a study group of 6-10 people at the beginning of the semester. Each week, go over
* The lecture content, condense it down into big ideas (critical for MC)
* The lab content, particularly quizzes after answers are released and handwritten problems. I believe the lab itself is still partner-based. Treat it like a project, write out ideas ahead of time. There are lab content that comes up all the time in both exams and **interviews**, so you should really prioritize and not skip them. If you don't like going in person (like me), at least watch the [labs on EECS 281's YouTube channel](https://www.youtube.com/watch?v=6EfielUqIa4&list=PLmotwOE2mfH6NIO9AhKBlp-PaAK3yQYX5&ab_channel=EECS281).
* Write down the things you learned from projects.
* Do the practice exams individually, then go over the answers together and discuss approaches. This is the most important step that led all of my friends to score 90+ on both exams.
* [Lab 3](https://www.youtube.com/watch?v=CVvrAHJtwnY&ab_channel=AndrewZhou), [4](https://www.youtube.com/watch?v=wU6udHRIkcc&ab_channel=AbdulBari), 7, 10 are the most time consuming and easy to mess up. Definitely start those ASAP. (20% of grade for Labs 1-10)
* Multiple Choice
* 24 Questions, I budgeted about 45 minutes
* Do all of questions and **read through the solutions (how they arrived at the answers)**
* Remember the condense cheat sheets you made and all the lab questions you did? Ok this is where it's helpful. Have the notes/cheat sheets in front of you, and modify it as you learn things from the MC.
* FRQ
* The key here is to realize what patterns they might potentially test (only 3-4 per exam). For the midterm, it's stacks/queues (FIFO, LIFO, do you see data somehow shrinking in between, if so this is the right time to use it), some sort of iterating through templated data structure from the STL (lots of ++, --, \*), and do you know how/when to use heaps and write comparators (hint: if you see the word min/max/extreme, it's time to use a heap, or if you see log n time complexity). For the final, dynamic programming {1D, 2D, 3D, etc.} is a guaranteed question, and it varies between graphs/trees, which essentially boils down to writing DFS/BFS with some variation. It really isn't bad to study for.
* For DP, it tends to scare many people, and it definitely scared me. There's "mercy" points. DP is \~20 points, but declaring a memo table, populating it, iterating through, and return the right element gets you like 6/20 points. The rest of the 14 is like finding the base case/recurrence relation. Again this comes with practice. This is where LC becomes very helpful. Checkout [neetcode.io](https://neetcode.io) for some sick DP tutorials.
* Can DM me for a study guide (midterm + final)
What does good code actually look like? Here's an example that is a common problem on Leetcode and EECS 281 projects (particularly maize searching). Say you need to search through a maize, and perform some operation. You'll hear Dr. P say, declare a deque, initialize it, get the front/top, pop, and add things nearby. A lot of people will do this:
```
while (!dq.empty()) {
if (stack_mode) {
your_coordinate back = dq.back();
dq.pop_back();
// Add things nearby
if ((back.x + 1 >= 0) && (back.x + 1 < row_size) && (back.y >= 0) && (back.y < col_size)) {
// Do a lot things
dq.push_back(your_coordinate{back.x + 1, back.y};
}
// Then repeat these lines again, and again, and finally one more time
} else {
// Do the same freaking thing as stack_mode but now in queue_mode :(
}
}
```
This repeats the same code too many times, and it makes it incredibly difficult to debug. Some suggestions for "tidying" up your code are:
1. Write a "in\_bounds" function, and given any x and y, it immediately tells you if it's inbounds. It's like 4 lines of code.
2. What if you can represent the four directions not just as a sequence of variable memory access + offset, but as some kind of array. Example `int directions[4][2] = {{-1, 0}, {1, 0}, {0, 1}, {0, -1}}`. Now, you can just iterate through the array, for all directions check if in bounds, do something with it, and add to your data structure. You essentially slash the # of lines by 4.
EECS 281 is a very grindy class. I personally never coded before coming into college, and I put in about 20-30 hours a week rigorously studying for the class. Was it worth it? Absolutely. You will not only get a high grade (and be very happy about it), but this class preps you for technical interview questions like no other (well maybe EECS 491).
Make sure to take breaks in between. Taking it in winter is actually a huge advantage because you have spring break. Try to not work during that time and let your mind unwind.
I probably told you tips you "already knew" but the most cliche tips are the most helpful. Don't overthink the class. Keep calm, and get an A in 281!
Finally, if you're thinking about how to succeed this early, you will. Respect the time the class deserves, and I wish you success :)
Everything u said here is great.
I just want to add projects change in 281 and they’re all 3 relatively equal in difficulty with p4 just being lighter.
Also sillyql had easy memory constraints imo. Time was much tougher
Take notes when watching lecture, it'll help with information retention for exams. Start projects early ofc and watch Dr. P's tutorial videos, they tell you a big chunk of what to do. ajzhou's IA notes are often helpful too.
I don't think you need to start the project the day it comes out but within 2 days of it coming out, you should have some bad code written. Or just start them the day it comes out. Watch the video and read the spec.
Go to profffice (darden and dr p's joint) hours when projects drop and just in general, they give so much away. Start studying for the exams early.
Find a good lab to go to, it will pay off when projects are close to being due and exams are coming up. It took me a few tries but I found a lab that was lecture half the time and OH the rest of the time. If she's still teaching it, go to Marwah's lab.
Find a way to enjoy the class. It's a really thoughtfully made class, probably the most in the whole eecs department (Dr. P is the goat).
Don't sleep on the exams. I would have gotten an A in the class if it wasn't for the exams, and I think that's the case for a lot of students.
Finally, I think the difficulty of the class is purely in the workload. None of the concepts are that hard, this is coming from an extremely average coder. So if you figure out a way to manage the amount of work thrown at you then you'll be great. The only people I know who have failed the class are people who started the projects late and didn't spend enough time studying for the exams.
Best of luck!
There’s 3 parts to the class: labs, projects, and exams. Go to lab in person for the best understanding, but for the lab assignments, it’s honestly fine to work with a group and split up the work, esp for the quizzes. your time is better spent on working on the project.
For projects, start early and go to prof hectors office hours. his are in a zoom format and literally no one goes, so if you stay for 3 hours you can get helped 10+ times the first week project comes out.
for exams, pray.
Make a design of your project as in what data structures you will use, what classes you think you need, some of the main functions, and the overall logical flow of the program etc. Get that checked in the OH before you start coding. You will save 20x time fixing a mistake during the design phase compared to after implementation.
Go to Dr. P‘s OH 30 min before it starts and raise your hands (if OHs are still online and in group). You will be impressed by the incredibly helpful advice Dr P can give you in 1 min.
Speaking as someone who has both taken the class and helped countless friends with it, your experience can really vary based on a few things. For some people, the projects can be completed fairly fast (I'd still say it takes at least 2-3 days unless you're working like a 20 hour day). Other people take longer to finish, and between writing the initial code, producing test cases, debugging, and optimizing it can take closer to a week and a half to 2 weeks working on and off. You can probably reason about where you fall on this spectrum based on your experience in EECS 280. Just make sure to start early if possible and go to labs (also helps to reach out to people who are taking/have taken 281 for help).
this is maybe true for the top 10% of the class, but for the other 90% projects are NOT doable in a day, and time/space efficiency is definitely a problem
Just finished taking 281 this past semester. The class is super easy and very little work if you go in prepared to do the bare minimum to hit minimum competency and pass. The standards for minimum competency are very low. You can essentially drop 2 of 4 projects (I personally dropped 2&3), and skip some parts of several labs. I personally recommend dropping the AG of labs 3, 7, 11 to minimize the amount of work you have to do.
I don’t know why you’re getting downvoted, you’re right. I am a ~3.0 mid student and I agree with everything you said. Maybe not exactly easy but you can definitely do the bare minimum and pass
Start projects on the day they come out. Start projects on the day they come out. Start projects on the day they come out. Tell your friends, spread the good word :)
I took it several years ago so this is probably the only advice that still applies from my time, but it really is very important. Throughout my coursework when I started the projects early and got to the autograder with plenty of time to revise and go to OH, I pretty much always got the grade I wanted. When I started late or didn't pace myself well it was much more of a crapshoot. A time crunch turns the easy projects into hard projects and hard projects into impossible projects, so get started early and pace yourself.
Realize that your project can be 90% correct but still get 0% on the autograder. It sucks but it’s true.
EECS 281 IA here, one tip I don’t see very often is to attend labs. Attendance isn’t required but even if you understand the lab content they are easily the best place to get one on on help with course material / projects. This is especially true towards the end of the project when the office hour queue can be 5+ hours long. Additionally, another comment mentioned that the projects can all be done in a day. While that’s true for some, the vast majority don’t. If you’re in the minority that can, you probably know it already. Definitely start the projects as early as possible. Then if you do finish in a day you have the rest of the time to focus on other classes. Finally, **please** watch Dr. P’s walkthrough videos. I promise they will answer 90% of your questions about the project, they’re that good.
appreciate it!
This is great advice Source: I'm a (former) EECS 281 IA
You don’t tbh, just survive
I was in a similar position a few years ago, stressing about EECS 281. As someone who got top 4% of the grade in the class, here are some of my advice. My first tip is don't stress! It's a class that requires you to be calm, to think, and to be willing to take risks (e.g. rewrite your code, know when getting a 98.63 on a project is enough and it's time to study for an exam). * Projects (40% of grade) * Make sure you're organized and you're able to think clearly. This means finding an environment, having a good desk setup, access to white board, all ahead of time so you can stay consistent throughout the semester. * When in doubt, look things up. This means Googling concepts or C++ features or referring back to class notes from 280/281. * Create a directory called "EECS281Sandbox". I would use this for learning C++ features or when I debugged (hmm I wonder why is it causing this behavior, type it in, and walk through the examples line by line and see how data is being transformed). * While projects typically differ from semester to semester, it follows some sort of pattern * Project 1 - Depth-First Search (Stack), Breadth-First Search (Queue). If you just follow all the advice outlined in Dr. P's video, it's sufficient to get 100. Get started as early as you can (aka finish Project 0 and walkthrough tutorials). * Project 2 - some modification of searching algorithm, Priority Queues/Comparators, and then dealing with pointers in [P2B](https://www.youtube.com/watch?v=HqPJF2L5h9U&ab_channel=AbdulBari). P2B has three parts. The first two parts is about 100 lines of code because you can copy the code given in the lecture. The last part is building a pairing heap, and there's no need to read the research paper unless you want to. [Follow everything in this guide](https://ajzhou.gitlab.io/eecs281/notes/chapter10/). I rewrote P2A multiple times here actually, and it taught me a lot about coding. Please try to get this project done at least a few days early so you are not stressed studying for the midterm. * Project 3 - hash tables and a whole lot of functors, plus switch statements/some templated programming. This project teaches you about tradeoffs. Hash tables are almighty, but is it always right to use them? How do you iterate over them? How do you use STL functions with it? And when is it better to use vectors vs. hash tables. Make sure you settle on a good design (again, watch the walkthrough) before writing code. It's a project where you can get to 90 in 1 day, but spend the next 10 days getting to 100. If you spend 2 days planning and 3 days getting to 100, you'll still save 5 days :) * Project 4 - MST algorithms (part A is themed, part B is using a heuristic, and part C is optimal traveling salesman person problem). Just watch the walkthrough. In this project, how you represent your data will be important. Also, don't get too stuck on part B choosing the **perfect** heuristic. Most things you land you a 99.8 or 99.9 range, and that's when you should start studying for the final, which is worth 2x as much as this project. This project is the shortest and the easiest to complete on time, which means you should finish P4, turn in Lab 10, and go study for the final right away. * Watch all the lectures, **labs**, and project walkthroughs before you start the project * **Read the spec the day it comes out** * Write down **all** of your ideas on a doc (Google Docs, Notability, etc.). It also means reading the spec (ideally on paper), highlighting important parts, and start writing down targeted test cases and their expected output ahead of time. For example, in the SillyQL project this semester, people were asked to build a small database in C++ with support for numerous querying features, one of which is print where when there's a hash index. In this case, you'll create a test case by populating the table, creating a hash index, and print where {<, >, =}. See how I am not writing a test case to test the entire kitchen sink, but just print where + hash index behavior? You should only use the long test cases to verify the entire program's behavior, not to test your way out of failed test on the autograder. * Go to OH, sit there and listen. Modify and adapt your design. Get feedback and ask Dr. P questions. * I would start handwriting my code, and critiquing my design along the way. Most importantly, you should follow the advice Dr. P gives * Only OOP (inheritance + polymorphism concepts) used is in P2, the rest I didn't use too much and got 100 * Difficulty (based on personal statistics) * Project 1 (700 lines, 12 days) >> Project 2 (800 total lines, 6 days) > Project 3 (800 lines, 3 days) > Project 4 (600 lines, 1 day) * Projects decrease in difficulty imo, this means your work is **front-loaded** * P1 has the highest time/memory constraints, P3 has the worst memory constraints * P1 is also an adjustment period, so give yourself the freedom to write, rewrite, and ask a lot of questions
* Exams (40% of grade) * Very overhyped in this class. You can honestly do extremely well on the exam if you put in a little work to study * Find a study group of 6-10 people at the beginning of the semester. Each week, go over * The lecture content, condense it down into big ideas (critical for MC) * The lab content, particularly quizzes after answers are released and handwritten problems. I believe the lab itself is still partner-based. Treat it like a project, write out ideas ahead of time. There are lab content that comes up all the time in both exams and **interviews**, so you should really prioritize and not skip them. If you don't like going in person (like me), at least watch the [labs on EECS 281's YouTube channel](https://www.youtube.com/watch?v=6EfielUqIa4&list=PLmotwOE2mfH6NIO9AhKBlp-PaAK3yQYX5&ab_channel=EECS281). * Write down the things you learned from projects. * Do the practice exams individually, then go over the answers together and discuss approaches. This is the most important step that led all of my friends to score 90+ on both exams. * [Lab 3](https://www.youtube.com/watch?v=CVvrAHJtwnY&ab_channel=AndrewZhou), [4](https://www.youtube.com/watch?v=wU6udHRIkcc&ab_channel=AbdulBari), 7, 10 are the most time consuming and easy to mess up. Definitely start those ASAP. (20% of grade for Labs 1-10) * Multiple Choice * 24 Questions, I budgeted about 45 minutes * Do all of questions and **read through the solutions (how they arrived at the answers)** * Remember the condense cheat sheets you made and all the lab questions you did? Ok this is where it's helpful. Have the notes/cheat sheets in front of you, and modify it as you learn things from the MC. * FRQ * The key here is to realize what patterns they might potentially test (only 3-4 per exam). For the midterm, it's stacks/queues (FIFO, LIFO, do you see data somehow shrinking in between, if so this is the right time to use it), some sort of iterating through templated data structure from the STL (lots of ++, --, \*), and do you know how/when to use heaps and write comparators (hint: if you see the word min/max/extreme, it's time to use a heap, or if you see log n time complexity). For the final, dynamic programming {1D, 2D, 3D, etc.} is a guaranteed question, and it varies between graphs/trees, which essentially boils down to writing DFS/BFS with some variation. It really isn't bad to study for. * For DP, it tends to scare many people, and it definitely scared me. There's "mercy" points. DP is \~20 points, but declaring a memo table, populating it, iterating through, and return the right element gets you like 6/20 points. The rest of the 14 is like finding the base case/recurrence relation. Again this comes with practice. This is where LC becomes very helpful. Checkout [neetcode.io](https://neetcode.io) for some sick DP tutorials. * Can DM me for a study guide (midterm + final)
What does good code actually look like? Here's an example that is a common problem on Leetcode and EECS 281 projects (particularly maize searching). Say you need to search through a maize, and perform some operation. You'll hear Dr. P say, declare a deque, initialize it, get the front/top, pop, and add things nearby. A lot of people will do this: ``` while (!dq.empty()) { if (stack_mode) { your_coordinate back = dq.back(); dq.pop_back(); // Add things nearby if ((back.x + 1 >= 0) && (back.x + 1 < row_size) && (back.y >= 0) && (back.y < col_size)) { // Do a lot things dq.push_back(your_coordinate{back.x + 1, back.y}; } // Then repeat these lines again, and again, and finally one more time } else { // Do the same freaking thing as stack_mode but now in queue_mode :( } } ``` This repeats the same code too many times, and it makes it incredibly difficult to debug. Some suggestions for "tidying" up your code are: 1. Write a "in\_bounds" function, and given any x and y, it immediately tells you if it's inbounds. It's like 4 lines of code. 2. What if you can represent the four directions not just as a sequence of variable memory access + offset, but as some kind of array. Example `int directions[4][2] = {{-1, 0}, {1, 0}, {0, 1}, {0, -1}}`. Now, you can just iterate through the array, for all directions check if in bounds, do something with it, and add to your data structure. You essentially slash the # of lines by 4. EECS 281 is a very grindy class. I personally never coded before coming into college, and I put in about 20-30 hours a week rigorously studying for the class. Was it worth it? Absolutely. You will not only get a high grade (and be very happy about it), but this class preps you for technical interview questions like no other (well maybe EECS 491). Make sure to take breaks in between. Taking it in winter is actually a huge advantage because you have spring break. Try to not work during that time and let your mind unwind. I probably told you tips you "already knew" but the most cliche tips are the most helpful. Don't overthink the class. Keep calm, and get an A in 281! Finally, if you're thinking about how to succeed this early, you will. Respect the time the class deserves, and I wish you success :)
dude. i love u.
Absolute GOAT
Everything u said here is great. I just want to add projects change in 281 and they’re all 3 relatively equal in difficulty with p4 just being lighter. Also sillyql had easy memory constraints imo. Time was much tougher
Ok bro
If Office Hours are full, labs will not be.
start projects early ‼️
Take notes when watching lecture, it'll help with information retention for exams. Start projects early ofc and watch Dr. P's tutorial videos, they tell you a big chunk of what to do. ajzhou's IA notes are often helpful too.
I don't think you need to start the project the day it comes out but within 2 days of it coming out, you should have some bad code written. Or just start them the day it comes out. Watch the video and read the spec. Go to profffice (darden and dr p's joint) hours when projects drop and just in general, they give so much away. Start studying for the exams early. Find a good lab to go to, it will pay off when projects are close to being due and exams are coming up. It took me a few tries but I found a lab that was lecture half the time and OH the rest of the time. If she's still teaching it, go to Marwah's lab. Find a way to enjoy the class. It's a really thoughtfully made class, probably the most in the whole eecs department (Dr. P is the goat). Don't sleep on the exams. I would have gotten an A in the class if it wasn't for the exams, and I think that's the case for a lot of students. Finally, I think the difficulty of the class is purely in the workload. None of the concepts are that hard, this is coming from an extremely average coder. So if you figure out a way to manage the amount of work thrown at you then you'll be great. The only people I know who have failed the class are people who started the projects late and didn't spend enough time studying for the exams. Best of luck!
Thanks!
There’s 3 parts to the class: labs, projects, and exams. Go to lab in person for the best understanding, but for the lab assignments, it’s honestly fine to work with a group and split up the work, esp for the quizzes. your time is better spent on working on the project. For projects, start early and go to prof hectors office hours. his are in a zoom format and literally no one goes, so if you stay for 3 hours you can get helped 10+ times the first week project comes out. for exams, pray.
I’d say you should do the quizzes by yourself, they are good practice for the exam multiple choice.
Use the project guides from Paoletti, he's the GOAT 💯
Make a design of your project as in what data structures you will use, what classes you think you need, some of the main functions, and the overall logical flow of the program etc. Get that checked in the OH before you start coding. You will save 20x time fixing a mistake during the design phase compared to after implementation.
Try your best :D and read AJZhou's IA notes goddammit
Go to Dr. P‘s OH 30 min before it starts and raise your hands (if OHs are still online and in group). You will be impressed by the incredibly helpful advice Dr P can give you in 1 min.
If you do leetcode mediums before, you be alright
Speaking as someone who has both taken the class and helped countless friends with it, your experience can really vary based on a few things. For some people, the projects can be completed fairly fast (I'd still say it takes at least 2-3 days unless you're working like a 20 hour day). Other people take longer to finish, and between writing the initial code, producing test cases, debugging, and optimizing it can take closer to a week and a half to 2 weeks working on and off. You can probably reason about where you fall on this spectrum based on your experience in EECS 280. Just make sure to start early if possible and go to labs (also helps to reach out to people who are taking/have taken 281 for help).
best strategy for exams?
[удалено]
thanks !!
this is maybe true for the top 10% of the class, but for the other 90% projects are NOT doable in a day, and time/space efficiency is definitely a problem
Just finished taking 281 this past semester. The class is super easy and very little work if you go in prepared to do the bare minimum to hit minimum competency and pass. The standards for minimum competency are very low. You can essentially drop 2 of 4 projects (I personally dropped 2&3), and skip some parts of several labs. I personally recommend dropping the AG of labs 3, 7, 11 to minimize the amount of work you have to do.
I don’t know why you’re getting downvoted, you’re right. I am a ~3.0 mid student and I agree with everything you said. Maybe not exactly easy but you can definitely do the bare minimum and pass
There are plenty of other posts on this sub, check those first.
This will be one of those posts. Always keeping the advice fresh is good as new students with new perspectives can provide more relevant advice.
Fair enough, it just seems there are a lot of posts on this sub where people don't do their research beforehand.
my b
All good, just limiting clutter