171–180 of 309 posts
Most CS questions are a bunch of concepts that you rarely use in practice. Most development work is implementing your ideas in a way that works with other peoples code and the framework thats used.
I would agree that an algorithms class does not equate to success as a software developer, but if you’re having issues with an intro class, there are certainly gaps in your knowledge. They might not reflect in your current job but may reflect in the future. I’d recommend actually brushing up on your fundamentals.
Earlier quoted context omitted.
Have you reviewed the lectures and other course material or just jumped into the problem sets? A thing that may help: Approach this CS50 material as if you have no knowledge of programming. Set aside your preconceptions about both your ability and the nature of programming itself (to the extent that this is possible). Review the materials and read/watch all of it, even the things that you know . You may know them, bu…
At the beginning of the course, this was one of my problems. My fianceè would give me the specification of the program and that's it. I've since learned to also follow along using the walkthroughs provided, since they provide answers to the most basic of questions that I would have asked.
I would suggest you have a golden opportunity here, tbh. You have identified an area of useful skills which you currently are lacking - and a source of info where to learn. That's good. More importantly than that, your fianceè is currently doing the course and is right at the start! If you sign up to CS50 now (it's free!), you have maybe 4-6 hours of lectures to catch up before you are at Ceasar yourself, and then you can work through this excellent course together!
You will learn lots, some of which may be very useful. As will your fianceè. And you'll both have a much easier and fun time having a partner to discuss the lectures and problem sets, helping each other out here and there, before having to reach out for assistance.
Okay, I'll give you the "triage" presentation. It's a combination of "where to start" and "what I've actually used in industry." 1) Algorithmic complexity: Study why naively adding to the end of an array or the end of a string results in O(n^2), while doubling the size when you increase the storage results in O(n). That one tidbit has comprised some embarrassingly large fraction of the "consulting" I used to do worki…
Earlier quoted context omitted.
What exactly did you have trouble with? These really are simple problems, all you need are an understanding of loops, ASCII character codes, and basic arithmetic. To be honest, I'm surprised a seasoned developer of 5+ years can't do these, or at least have a decent stab at them.
Why would you expect the modern application developer to even know what ASCII is? There is a chance I wouldn’t know what ASCII encoding was if my exposure to programming didn’t start in the 8 bit era. C is foreign to a lot of self taught programmers.
I base my Opinion on it being a bad idea to rely on manual translation, and untill then I'll have learned to write code that does the translation for me.
Earlier quoted context omitted.
Your first paragraph hits the nail on the head. This is exactly me. Thank you for your reply. I do intend to work further on my skills in order to get better!
One (relatively) easy way to get better at it is combining a book and some real world uses with a project and a language suited for it. For example, you could take python or java (or C#, pretty much any general OOP language), and make a simple crud application. Then add a "reporting" page where you can see different results on for example uses of trees, sorting algorithms or storage data structures (like linked lists…
If you don't know his name, you should - he's written some of the best books on these algorithms and his MOOC is similarly rich in visualizations and concrete examples that help you develop the intuition for the algorithms. Also incidentally his doctoral advisor was Donald Knuth, who he evidently learned a lot from.
I've now run three tech companies and hired dozens of developers by having really intense, thoughtful conversations with them. I asked them to tell me war stories and encouraged them to share insights on how they solve problems.
I only rarely look at code, because it's self-evident when you're talking to someone that is passionate about programming + intellectually curious-to-hungry + an interesting person who demonstrates empathy and seems like someone you'd want to spend 7-9 hours a day with.
I hire like I'm trying to form a rock band: I don't tell them what to play, I give them permission to show me what they've got.
Here's the thing: the more we, as a class of developers, put up with these devolving interview processes, convince ourselves that this is somehow our failing and our inability to FizzBuzz in six languages with a sharpie and people watching... the more we allow it to be considered okay, and the more normal it will be to expect this nonsense.
I know that being cash-starved sucks, but you know what? If you walk into an interview and they bust out the markers and ask you to start sorting, I sincerely hope that we can collectively find the strength to laugh at them and politely tell them that you'd never waste your time at a company that insults your craft.
Find your pride and tell them why they missed out. If they want to understand what just happened, tell them to take you for a drink. If they are dicks about it, you really didn't miss out on a damn thing. I promise you that.
I will repeat that TDD will not give you the most elegant answer, but you will at least have an basic implementation. TDD just gives you one of protocols that you can use to solve problems.