Ask HN: I've been a programmer for 6 years, and I can't solve basic CS problems

[cs0]

Hi HN.

My fianceè is currently enrolled on CS50 Introduction to Computer Science online.

I'm a programmer and have been for around 5-6 years, I started with VB.NET since I first started learning, then progressed onto Web Development at a large agency for 4 years (PHP, JS, React) and I'm now back with VB.NET.

I've worked with a few "complicated" (they were to me) projects in the past, but now I'm being tasked with guiding my fianceè with this course.

Some of the problems which she is expected to solve are pretty simple problems, but I just can't seem to get the hang of any of them on my own.

I would have thought that my last 5-6 years of experience would at least help me here. I can point out basic syntax errors and help with debugging, but when it comes to me trying to solve these problems on my own, I don't know where to start.

It makes me question how I was hired in the first place.

Sorry for the rant, but I was just wondering if anyone else felt like this.

[swatcoder]

Think of it this way: application development, software engineering, and computer science (and data science and ... etc) sometimes use the same tools but are all different disciplines.

Universities traditionally focused on Computer Science and their graduates would often need a lot of grooming before they could really be independently and reliably productive in the commercial words of application development or software engineering. Importantly, it was less grooming than someone who studied something like English or Sociology or History, but it was still a different discipline than what the job market demanded.

You jumped into the job market directly. You learned to develop applications, research API's, study trends, and participate as a team member in development workflows under commercial pressure. You don't know how to compose and compare sort functions for abstract sets of N elements because you never needed to. You just use sort().

And that's okay! Inventing new algorithms with theoretical significance is not your job! You have other skills and they're of much more immediate value!

[aphextron]

>And that's okay! Inventing new algorithms with theoretical significance is not your job! You have other skills and they're of much more immediate value!

Except when it comes to getting a job. Forget any of the rest of your skills, because we all know the only thing that matters when interviewing is an ability to recite CS algorithms out of memory and solve obtuse puzzles while pretending you've never seen them.

[guitarbill]

seconding this, creating value is orthogonal to knowing CS. see the creator of homebrew, Max Howell infamously failing to invert a binary tree in an interview: https://mobile.twitter.com/mxcl/status/608682016205344768?la...

[supercall]

What's the difference between application development and software engineering?

[throwawaylolx]

What are the differences you consider when making a distinction between application development and software engineering? It seems to me that application development is a subset of SE.

[tempestn]

I agree with you to some extent, but I do think sometimes this point of view is taken too far. Some basis in theory is useful, not so much because you'll directly apply something you learned in a CS class, but because it helps you learn how to think about difficult problems. Most real world work is indeed just putting pieces together to get the result you need, but there are occasionally things that really are difficult, especially to do efficiently. I think it could legitimately be a concern if an experienced programmer couldn't pass an introductory CS course.

To the OP, presumably your fiancé has study materials as well as just questions—why not audit the course, and learn how to solve the problems you're having difficulty with? (Then write a Tell HN and update us on whether you feel you learned anything useful!)

[peteforde]

Honestly, I'm appalled by some of the stories being shared in this thread; smug interview panels pressure-cooking candidates as they try to whiteboard obscure CS gotchas is a system perfect only for assholes and masochists.

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.

[rwhitman]

Amen, 100% this. Same methods here, same success rate.

I just had a long conversation this afternoon with a friend who manages a tech recruiter team and she was telling me how frustrating it is working for cash-strapped early stage startups who pass on perfectly talented & experienced candidates open to taking a salary hit - because they, in their inexperience, cannot fathom how to interview without subjecting candidates to a series of dehumanized and impossible puzzles that are only solvable by people who have dedicated themselves to puzzle solving.

Meanwhile established companies with deeper pockets, such as banks, scoop up these candidates to do humdrum back office software work because they use tried and true interviewing methods.. like talking to candidates.

I attribute most of the issue to inexperience on the hiring managers' part and pressure to hire only the "best of the best" from leadership. Coupled with developers' personal insecurities, lack of education on the fundamentals of management, echo chamber noise around code test culture and the incessant desire of engineers to abstract away any human elements of their work, the process has devolved into a toxic mess when it comes to recruitment and interviewing.

Hopefully the situation can be fixed at some point. But until then, I'll keep on scooping those 10xers by trading war stories over the phone, thank you very much...

[mcv]

Most companies I talk to do this: we talk, they ask questions, I tell about a couple of projects, I ask questions, they tell about their company.

Some want me to do an assessment, which is fine. But it's at home on my own dev machine, and not on some whiteboard.

I generally like these take-home assessments. The best had me write a game board in React on which you could place obstacles, and an adapted A* algorithm to find the shortest path through it. That was really fun. I'd never done something like that.

[robodale]

Holy fuck I'd work for you in a heartbeat.

[cloverich]

From my perspective on interviewing and talking to lots of dev's, I take at least some of the horror stories with a grain of salt. I've seen some "pressure cooker" scenarios really just be interviewers who were not very good at interviewing. Conversely, I've gone deep in conversations with a developer on how BS interview questions are, and while imaging some crazy graph algorithm or something they come out with "Yeah they tried to get me to implement a Set" (at a high level, in Javascript). That's not a challenging or obscure problem, this person simply lacked technical depth and was jumping on the bandwagon.

Which is all to say, I can agree in general with obtuse CS problems being a bad proxy. But I think asking someone you are hiring to write code all day to write code as part of the interview is reasonable, and at this point I'd be suspect if I were interviewing somewhere and they _didn't_ ask me to write at least _something_.

[james_s_tayler]

Just went through an interview today that is exactly in the style as you describe it. Gels with my ethos perfectly. I really value this kind of approach.

[hacker_vishwa]

-->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.

I liked this approach of hiring.

[huawhey]

Bingo. The reality is many people have no idea how to interview, so they fall back on the only thing they know: test taking in school, and studying for the test.

You don't want to just ask them to tick boxes, because first off some'll lie to you, and second, the dunning-kruger cases will lie to themselves. Can they communicate? Can they solve unseen problems? Can they do so comprehensively and rigorously? Do they know how to maintain a project for many years?

An interview method that can't tell the passionate hackers from the posers and pencil pushers is worthless.

[cs0]

Thank you to everyone who has replied to my rant.

I felt of low value for not being able to provide immediate help for most of the problems that she's being taught to work on.

Some of the examples (since some of you were asking for them): https://github.com/cs50/docs/blob/master/_pages/2018/x/psets...

https://github.com/cs50/docs/blob/master/_pages/2018/x/psets...

I realise that I may have written my original post a little hastily as I was feeling quite strong about having inadequate knowledge to solve these problems.

You've all been super nice to me, and I can understand where you are all coming from.

Again, thank you.

As an aside, the problem that I was stuck on earlier, I managed to solve through a bunch of trial and error, so I'm chalking that one up as a win for tonight.

[whack]

The examples you gave are very helpful in giving more context. I'm guessing that you're productive in your job, because you know the details of how to use language ABC, framework XYZ and the various patterns for solving common industry problems using ABC and XYZ. The part you seem to be weak in, is abstract problem solving. Ie, coming up with a pseudo-code algorithm that will accomplish some abstract goal that you've never come across before.

This requires a completely different skillset. You rarely have to come up with novel algorithms when building a CRUD app, hence why you've never gotten the chance to practice those skills. That said, it's definitely worth learning - if nothing else because it will help you in job interviews.

There's no shortcut to this. Go on leetcode or hackerrank or similar sites - or do all the homework assignments and projects along with your fiance. You're working out a brand new muscle, so it will definitely seem frustrating at first, but you'll get much better with practice.

[machiaweliczny]

I'm sorry to say this - but given this examples I wouldn't hire you if you can't solve so simple stuff.

You have probably problems with text comprehension because I don't know how you can't solve it.

It's not coding that's needed - you should be able to do it on "paper".

What are you really struggling with?

1) understanding problem setup (reading)

2) coming with solution to problem (search)

3) implementing solution in programming language (coding)

[hmmk]

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.

[TheFattestNinja]

I mean you had your share of tough love already in this thread. But: - The examples you posted are indeed very simple problems. Caesar is just about "can you scan two arrays at the same time" (and then do charString + charKey and some modulo). Luhn is just a step of non-obvious specification to follow.

- This is a different game than your day to day. Those two being easy stuff means nothing if you never played the game.

- Now you moved a "unknown unknown" to the category of "known unknowns". You know you have no competence in this category, and if you wish to improve in it you can do so. Or not, it's your choice. Before, you didn't have the choice. So that's good!

- It's not about the language. You can solve these in Java, C, Assembly, Haskell. Most training website for interview questions (like these) allow you to implement in any of the major languages. If you want to play the game and get better, I recommend Hackerrank (for structure) and TopcoderArena (for variety, since they give you a bit more fuzzy spec and you also need to identify the algo for the issue at hand). The latter is slow as balls though, and offers no solution (except the best submitted, which may be cryptic).

- This stuff takes time, and if you want to learn about things you'll have to book up. Cormen's "Intro to algorithms" or Skiena's Manual are the goto texts. They are thick. Take your time. Persevere.

[MBCook]

Is there a particular part of these problems that is stumping you? Perhaps breaking them down into smaller sub-problems? Where is it something else?

Based on your original description I was expecting something more heavy on straight CS theory. “how do you sort an unordered binary tree in place“ kind of thing.

[golergka]

Thanks for the provided examples.

If you have been working as software engineer for five years, but can't solve that task, that indeed makes me doubt how were you hired in the first place. I'm sorry if that sounds harsh; I appreciate your honesty and I would want to support you in your self-doubt, but I consider honesty to be more valuable in such a situation than being nice.

Caesar's algorithm in particular looks like a high school assignment, to be honest.

[commandlinefan]

Just FYI, you may want to hang on to your LUHN algorithm implementation - I’ve had to do that for work several times. That’s actually pretty real-world relevant.

[paradoxparalax]

I would recommend not getting scared looking for the whole bunch of specifications at once, Try to say or write the solution's steps in plain English letting only the most fundamental, as you were explaining the steps to a kid or so, Try to imagine yourself explaining/teaching in simple words is a good way to reason better about the problem. I started learning programming as a hobby/long-term-dream at almost 40 y.o. and it felt so hard to understand the most basic thing in Ruby, like what an Array is, for example, that it gave me literally a big headache and devastating disappointment, even almost cried...now I laugh remembering that :D There is an interesting book I saw then that I recommend, it's name is "the nature of code" , talks about examples of algorithms that appear in Nature and natural phenomena.

[chaostheory]

I think you just need to brush up on data structures: https://www.geeksforgeeks.org/data-structures/ (There are probably better resources like HeadFirst or Khan Academy)

Most of the problems you've listed become easy the more familiar you are with data structures. This is a more common problem for anyone outside the SV/SF bubble and I wouldn't worry. Just start doing homework and you'll be fine.

Once you're done with data structures, I would start checking out design patterns: http://shop.oreilly.com/product/9780596007126.do

Hope it helps

[triangleman]

These problems remind me of the ones on checkio.org. The difference being over there you get the benefit of using python--not that I already knew python but it's rather intuitive, plus you can run a million things through an interpreter to quickly understand how it works. These CS50 problems require C, which most mortals would have a much harder time working with.

In either case you constantly consult the language reference and standard libraries until you find something that works. The C reference at https://reference.cs50.net/ looks perfectly good.

To be honest I don't know how I would load a CC# into an array to compute Luhn's algorithm on it in C. In Python I know there are easy ways of doing that, because strings are automatically arrays in the first place (same as that Caesar cypher problem, Python makes it much easier to work with strings). I don't even know if that's the "right" way to do it, but that's what I would do in Python: Convert the number to a string, operate on it as an array, converting each character to an int as it goes, running the algorithm as given in the problem, back-converting to string and then back again to int as needed (like if I need to add the digits of a number together). Fine I suppose I could avoid doing that by taking modulos and if I didn't know what a modulo was I would divide by 10 for instance and then take a floor to get the first digit of a 2-digit number.

I have no idea if any of these methods are "correct", I would just hammer away at the code until the acceptance tests passed. It would take over an hour for each of these solutions, after getting into the zone, so let's say 2 hours. There you go, 4 hours of work to get through these two problems in C, let's add on a lunch break and we have a full work day. That will be $325 thank you. Oh I don't get paid to study computer science in my free time? Oh ok. I guess I will just bookmark CS50 and come back to it... some day.

Your wife is lucky she gets to study this stuff. Don't be so hard on yourself.

[echlebek]

I mean, I notice that these assignments seem to assume that you are using C. Are you using C?

You said that you have used PHP, Javascript and VB.Net. C is much harder to use than any of these, and exposes you to many concepts that these languages have abstracted away.

[bjourne]

Seems like the sibling comments have already doled out the tough love. All I can add is that I'm in a similar boat, having worked for a long time and now back at university to finally check out my degree... The material is much, much more challenging than I would have thought. Which is disheartening because I have so many years of experience and thought I knew most of what there is to know... So eh, don't give up! Working on those homework problems with your fiancee is a great opportunity to learn more.

[peterkelly]

Programming isn't the same thing as computer science, in the same way that writing isn't the same thing as journalism.

Writing code is the easy part. It's tedious, requires lots of practical knowledge and troubleshooting skills, but is for the most part a straightforward exercise. Computer science is about the theory. It involves solving problems in the abstract, using (and in some cases creating) new conceptual tools with which to think about, model, and solve a problem.

Many jobs in the software industry require only programming skills, and with those you can get along decently at any one of thousands of companies which are basically just building the same kinds of applications over and over again. But doing anything truly interesting requires venturing into the world of computer science, which requires years of study to master.

[klunger]

I think this is a bit of a false dichotomy. There are plenty of "truly" interesting software engineering jobs, no CS required. There is a lot that goes into designing a good CRUD app (yes, I said it). There are many trade offs, different basic architectures to choose from, different libraries, different design patterns -- all which have pros and cons to be weighed, based on the needs of the project (I speak as someone who makes spends a lot of time doing native Android CRUD work).

It really annoys me when people say "oh that stuff is so trivial, you need to be doing low level C++ optimization or whatever to be doing anything truly interesting or important." It's "Revenge of the Nerds"-type BS. But the truth is that jobs that "only require programming skills" can certainly be interesting if you take it seriously, and treat your craft with the respect it deserves.

[mcv]

Exactly. Computer Science is much, much more than just programming. Knowledge of many aspects of CS can certainly useful to programmers (depending on what they're programming), but it's perfectly possible to be a very competent programmer while having massive holes in your understanding of CS.

And for most programming jobs, real programming experience is far more important than a broad understanding of CS. With a solid grounding in CS, you'll be able to tackle more complex issues and maybe be more flexible to switch to completely different IT-related careers, but for most jobs, it's not necessary at all.

[sheeshkebab]

A bunch of bull shit. Working on something truly groundbreaking requires none of it - it does however require super broad and deep knowledge of things outside of CS and ability to do things/program when you have an idea.

[donkeyd]

> But doing anything truly interesting requires venturing into the world of computer science, which requires years of study to master.

What's the definition of 'truly interesting' though? I designed and helped build a SaaS product from the ground up. The product is quite revolutionary in its market and is getting interest from multiple Fortune 500 companies and smaller multi-nationals. I have 0 CS background and am fully self-taught. To me, however, this is truly interesting.

[gregorygoc]

That’s a good point. Now, how do you find interesting job which involves computer science skills?

[stcredzero]

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 working for a language/VM vendor.

2) Graph theory. Study BFS and DFS and implement them a few times to do things like solving a maze. Get comfortable with those until you can "run" them in your head when looking at a problem specified on paper containing a graph, and you can see uses/consequences. This will both keep you out of trouble and can be a starting point for further study.

3) Concurrency. Learn about race conditions and deadlock. Figure out some tools and patterns for dealing with them. Use them to write a chat server and figure out how to automatically QA it until you can break it.

4) Transactions. ACID. Read up on why you have ACID transations, and what can go wrong.

That right there is good for some huge percentage of what could really get you into deep trouble.

[topkai22]

I do have a CS degree, but I manage a software development team that is mostly composed of people with non-CS backgrounds. Having done this, I can assure you that you don't need to be able to solve toy CS problems to produce sophisticated, useful applications.

That's not to say a CS degree isn't useful- My observation is that a good foundation in computer science (algorithms, data structures, type theory, programming language, and systems) does help improve code quality and tends to be insurance against "hitting a wall" when problem solving, but my team members without CS degrees generally just as productive in delivering value. Its all learnable outside a university as well- one of the guys on my team with a liberal arts degree has picked up so much theory of the years I'd call him the "most CSey" of all our people.

The repeating problems I have with my team members lacking a CS degree general are misuse of type systems (IE- never creating interfaces, not inheriting, copy and paste reuse, etc...) , not doing functional programming right (or at all) in Type/JavaScript (this really stinks when Promises are involved), and a lack of awareness about performance consideration (hey! I think I found the problem! There is 9 levels of loop nesting, and each call inside the loop does a web request). These are areas my CS education really helped with, even if I didn't know it at the time.

On the flipside, the "CSey" crowd on my team (including some self taught people) sometimes lose productive chasing non-issues that don't conform to some platonic ideal we were taught (yes I know the array only ever has 3 elements in it, but I got the operation to run in O(n) time!).

In short, I'd encourage you to try to learn these toy problems and the concepts behind them as they do have value, but hardly a core requirement to deliver value creating software in most circumstances.

[nabla9]

Programming has become so generic activity that the word "programmer" tells very little of what people are doing and what their skills are.

From the description of what you have done, you are working in "software assembly" type programming job. You clue things together and get the job done. You know the API's and some standards. Most of the programmer jobs are what you are doing. It's very different from the classical algorithmic programming type jobs and programming.

People who build machines have wide variety of job descriptions: mechanic, welder, machinist, mechanical engineer, and so on. But somehow it's assumed that if you can do "web development", you can do do it all.

[cyphar]

There's a common belief that you can learn everything you need to program through practice. And that is true in the sense that you can eventually learn how to write working programs. But understanding the theory behind programming and algorithm design is a very different thing.

As a concrete example, while in high school I participated in programming competitions. One of the questions required writing a parser for a context-free grammar. Being completely unaware of recursive descent parsers I managed to fudge together an awful program with probably disgusting algorithmic complexity. After taking an "intro to CS" course (as an extra curricular activity), I immediately knew how to write basic parsers for CFGs correctly. It's not that I was suddenly much better at programming, it's that I now had learnt some theory that helped me know how to approach a problem.

You can't really "pick up" algorithms. You have to learn it through some kind of study (self-study is also acceptable). There are thousands of man-years that have been spent on algorithms. It's probably not a good idea to start out from scratch. In this respect, I would argue that programming is far closer to mathematics than engineering.

[Kinnard]

"The first lesson is that computational complexity theory is really, really, really not about computers. Computers play the same role in complexity that clocks, trains, and elevators play in relativity. They're a great way to illustrate the point, they were probably essential for discovering the point, but they're not the point.

The best definition of complexity theory I can think of is that it's quantitative theology: the mathematical study of hypothetical superintelligent beings such as gods. Its concerns include:

If a God or gods existed, how could they reveal themselves to mortals? (IP=PSPACE, or MIP=NEXP in the polytheistic case.)

Which gods are mightier than which other gods? (PNP vs. PP, SZK vs. QMA, BQPNP vs. NPBQP, etc. etc.)

Could a munificent God choose to bestow His omniscience on a mortal? (EXP vs. P/poly.)

Can oracles be trusted? (Can oracles be trusted?)

And of course:

Could mortals ever become godlike themselves? (P vs. NP, BQP vs. NP.)"

https://www.scottaaronson.com/blog/?p=56

[poulsbohemian]

Computer science is not the same as professional software development, even though it makes for a good educational foundation. Often even those of us who studied computer science are separated from it by enough years or abstractions such that we have to take a step back and think about fundamental problems when they are presented. So don't feel bad, unless you believe this actually indicates an area for professional growth.

Said another way - I haven't needed to write <sort> in twenty years, so if I had to, it would take me just as long as it takes you.

[haney]

I heard somewhere that a computer science degree is actually a history degree in how we have solved problems in the past. Programming is a creative problem solving process, but certain problems took decades to solve and it’s only by knowing the history that people are able to resolve some of these hard problems. Don’t beat yourself up for not knowing all of history and give yourself a break for not being able to immediately solve problems that took dedicated researchers their whole careers in the early days of computing.

[dep_b]

80% of all software is glueing frameworks together to do CRUD. There's an art to do that right as well, especially very large systems with lots of legacy. Readability, SOLID, safety. It's not something everybody has a talent for.

But it doesn't need particular deep CS knowledge. There are people that program for 30 years, get paid six figure salaries and "never needed that shit". And they're really good at their jobs. But sometimes (less often than it's required to pass for an interview) you're really expected to dig that deep because you need to solve problems that existing frameworks and libraries don't handle.

Background: learning basic CS stuff after 20 years of programming professionally. You will never learn it on the job.

[lmilcin]

Application developer is to computer scientist like car mechanic is to physicist.

You've been conned into thinking Computer Science prepares for Software Engineering. That's not true.

While you may need some Computer Science knowledge from time to time (and in fact there are some rare jobs heavy in Computer Science knowledge) almost all typical development and especially entry level software engineering jobs are all about knowledge and skills that are not taught at school.

You've spent past few years learning other important skills. You don't need to know how numbers are divided, you don't need to know how cuckoo hashing works and you don't typically implement A* from scratch to get your company's systems implemented.

I don't want to say it is not helpful to know these stuff. It certainly is. But to spend couple of years of your life getting in debt instead of earning money and useful experience -- that's something everybody has to ask themselves if they think to get into Computer Science as a way into software engineering.

[sowbug]

You've already gotten a lot of good perspectives. I have two tangential observations.

First: a lot of applied software engineering has the overarching goal of allowing developers to quickly build useful, stable, and secure products with relatively little knowledge of complexity principles or the implementation of the underlying system. Your successful career demonstrates the achievement of that goal. This is good. But it has absolutely nothing to do with your ability to build the tools you use, any more than a writer would know how to manufacture a pencil from raw materials. They're completely unrelated skills. But that was the whole point from the start of the profession!

Second: your spelling of "fiancée" is incorrect. The word comes from the French word fiancer, to betrothe. In French, you add the equivalent of the -ed suffix by changing -er to -é. Then for a female subject, you add another e. So "fianc" + "é" + "e" = betrothed woman. Using a è (backward accent) at the end of a French word isn't just wrong; it's more or less impossible (at least I can't think of a word that ends with è). Compare a snippet of JavaScript like if )a == 3) { b = 3: } You're an experienced JS developer, so you can spot the two syntax errors from a mile away. That's what "fianceè" looks like to a reader for whom accents are significant. Just stick with "fiancee" without accents, and you can't go wrong.

Sorry to hit you when you're down.

[Kaotique]

I'm a little annoyed by the people who call these simple problems. There are no simple problems. Calling something simple is very insulting and demoralising.

It really depends on your experience and knowledge for what is simple for you.

You can have 20 years of experience developing projects and acquired a ton of valuable skills but when I shove a whiteboard in your face and tell you to solve some algorithm it's completely new and not simple at all.

Just as someone with a lot of theoretical CS knowledge will struggle if I present them with a failing dependency tree of 30 thousands NPM packages. Good luck solving that when you have never done it.

[kvm]

I’m going to disagree with all the positive comments in this thread. I feel like they’re all “feel good” comments instead of being realistic. CS 50 is a freshman level introductory CS class. It’s not a theory class, it’s not a class teaching you how to implement sort behind the scenes.

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.

[cyberprunes]

As others have pointed out, a lot of application development rarely requires solving typical CS problems. One can go a long time building things without such formal knowledge. I agree with that and I'm glad that the field is available to anyone that loves to program regardless of schooling. BUT

The problem is thinking that "It's ok!" to spend your career in ignorance because your job doesn't involve inventing new algorithms or pondering theory. That's just lazy. I know, I did that for years too, not knowing why I should bother since I'm doing just fine without it! That is the arrogance of ignorance at work. I guarantee that you don't know how miserable you really are.

It's not about passing whiteboard interviews, it's about achieving a deep understanding of fundamentals. It will change and improve the way you think and approach problems. It will improve your software regardless of whether or not it involves an actual "CS problem" because your mind will be elevated. I did the same thing for years, I whined about "whiteboard interviews that don't effectively display my skills and unique gifts to do the job". It's a dumb mindset.

My advice as an internet nobody would be: Now that you've seen that you are struggling in this area, work on it! Don't let these people encourage you to remain ignorant. Advocating for ignorance is shit that propagates shit.

Ultimately, understanding the principles of your field will make you better. It's not about the damn whiteboard!

[WheelsAtLarge]

Interesting, I think a CS degree does not equal a programming job unless you prepare in addition to your CS degree.

CS programs focus more on the abstract parts of the field. For example, you can finish a programming project without having to program a sort function, this is a built in function in most languages, yet that's a basic part of a CS program.

I think generally there's a disconnect between what employers need and what CS programs provide.

Don't get me wrong there are jobs that could not be done without the knowledge CS programs provide but for the average programming job there's a disconnect and you'll have a hard time if you don't have that in mind.

So, yes, I can see how you can have a programming job without being able to solve a CS class problem.

[extragood]

You're restricting yourself from some opportunities by not knowing CS fundamentals.

Those are very common problems in programming interviews, and in those cases you would be disqualified.

If that bothers you (and the fact that you posted this question indicates to me that it does), then I would recommend taking the opportunity to learn along side your wife. You don't get the degree that way, but at least the knowledge is free. And your wife might like it, as a plus.

[beering]

I wonder if it can be analogized to a line cook (you) vs someone going to culinary school (your fiancee). In your day job you execute consistently and skilfully, but if you were put in front of a pantry full of miscellaneous ingredients and told to come up with a dessert you might struggle.