Help Request
Understood the Python concepts but completely messed up the test
Fy DS student and I recently had a Python test that honestly didn't go as well as I expected.
The frustrating part is that I wasn't completely clueless about the questions. I understood the concepts, knew which syntax was needed, and could understand what the problem statement was asking me to do.
But when it came to actually applying everything and writing the code, I got confused. I started forgetting things, made indentation mistakes, got errors like ValueError and other errors etc. I didn't do good in test it was 15marks test for 1 hr.
For those who have been through this, how did you get better at applying concepts under pressure instead of just understanding them theoretically? Did you practise more problems, rewrite code from scratch, or follow some other method?
I'm still learning, and I don't want one bad test to discourage me. I just want to figure out how to improve so that next time.
You'll get better at writing code, by writing code.
Working under pressure is something you can work on independently from coding. Either by accepting you can fail and remove any pressure, or by training to work with the pressure.
Its practice. There are a lot of sites that will give you coding problems. Find one you like, give yourself a time constraint, grab a random problem and code without using any external resources you dont have access to for an exam.
Going from understanding concepts to being able to reliably code with them is tough for a lot of people. Practice and experience gets you muscle memory.
Thanks for that and one more thing I would like to ask in my college the teachers are usually making us write codes on paper/book. Do you really think that helps? I think writing code actually helps
Yes it actually helps, especially with the issues you're running into. Relying too heavily on the IDE to tell you when your syntax is wrong doesn't actually help you learn to avoid it in the long run and you'll spend more time fixing syntax errors than fixing the code itself.
Working things out on paper is often helpful. However, that seems more appropriate for pseudocode. As a grad student, I was a TA and a lab instructor and was pretty generous on what I would accept for hand written code on paper.
I am assuming "fy ds" means first year data science student? Presumably you are just starting to learn programming? It's not always easy in the beginning. Keep studying. Keep practicing application of the concepts you are leaning. Like so many other things, if you keep putting in the work, you will improve.
I don't see any attachments of the questions or where you messed up, but one bad test doesn't mean that you are doomed to failure.
What specifically did you struggle with, or what approaches did you use? For example, in the first problem, the steps would be:
Read the input.
Perform the conversion. (Celsius to Fahrenheit).
Classify the temperature (Hot, pleasant, cold).
Output the result.
This is kind of fundamental in any program. Take your problem and break it into smaller problems. Repeat this if the problem is really complicated and you need to decompose the smaller problems even further. Eventually you have a bunch of really simple problems. Solve those.
It would help if you posted the questions but one of the things that helped me a lot when first starting was breaking "problems" into component parts.
For example, if a project is requesting you to take in a user input, do something with it, then output it, make 3 projects instead, one that just takes user input, one that does something to a static value, and one that just returns something (usually "hello world" 😅 ) and make sure you understand each of those parts completely, then merging them together should be easier, through that effort you'll get more experience with indents and what values can and can't be used for different commands.
Yea so again, just for example, I would recommend you take the first one, and make a program that reads in a temperature (project 1) and then a program that converts a temperature from Celsius to Fahrenheit (project 2) then a project that outputs Hot/Pleasant/Cold given a constant (project 3), then once you've got those working combine them all (project 4).
You don't want to have to do this always but it's really good practice for just starting out to make sure you learning each part of the questions you're being asked.
People are often only talking about learning a language. But that already shows that they absolutely don't know what it's about.
The language you use is just the last step of expressing your ideas. You can express the same ideas in several languages.
So it's actually not about learning a specific language, but about learning to create algorithms or whole systems to solve problems. The specific language doesn't really matter. The algorithms and the system design (and more so, the data design) matters. If you know what you want you can express it in every language.
If you can program knowing a language mainly means knowing your way around the documentation.
Same with music: People always talk about the instrument they want to learn, but forget that they need to learn about music first. Knowing music theory is the base for handling musical ideas (that equals the ability to figure out algorithms) a specific instrument is just a way to express these ideas (like a specific programming language).
There is a big difference between knowing Python syntax and being fluent with the syntax so you almost don't have to think about it anymore when solving a problem.
Sometimes understanding the problem is more difficult than writing the Python code to solve it.
One strategy is to practice and memorize idioms for common scenarios, like setting defaults to None, list comprehensions, context managers, custom exceptions, etc So you don't have to think about them as much later and more importantly, code will look "weird" if you make a mistake. I remember the first time I heard 'even number' and automatically typed number % 2 == 0
7
u/bot_russian5490 1d ago
You'll get better at writing code, by writing code.
Working under pressure is something you can work on independently from coding. Either by accepting you can fail and remove any pressure, or by training to work with the pressure.