Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: I've been a programmer for 6 years, and I can't solve basic CS problems
404 points by cs0 on Nov 13, 2018 | hide | past | favorite | 296 comments
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.

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!

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

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.

I’ve been a professional developer for 20 years and have never had to recite CS algorithms or solve obtuse problems.

My last three jobs I had to whiteboard an architectural diagram of a system, come up with a 90 day plan to create a software development team (I didn’t know I was applying for a lead position), and describe how I would introduce Devops, redundancy, traceability, etc into a system

The closest I came to a CS style interview was my second job out of college when I had to explain high level different data structures. That was actually important since we were writing cross platform, C that had to be highly optimized.

I’ve gone on lots of interviews with only two rejections - the rest I took my name out of the running once I got the job.

I came up as a traditional computer geek - learned how to program in Basic and assembly on an Apple //e in middle school, fell in love with C, spent way too much time on comp.lang.* groups etc.

One of my best friends who I worked with across three jobs graduated from one of those infamous for profit schools, for years wouldn’t know an algorithm if it hit him in the face, but spent a lot of time on side projects, reading best practices from books, etc. and is one of the best architects I know.

Since we're sharing anecdata, I'm a professional developer and still use recursion, building/traversing various types of tree data structures, and a few other CS degree requirements.

That said, for algorithms (e.g. sorts, etc), understanding what the options are and trade-offs is certainly more useful than knowing how to implement them, since there's a good chance someone has implemented it already in your language of choice.

What percentage of developers do you think are solving “hard problems” compared to ones that are just doing CRUD apps or yet another SAAS app?

"Hard problems" are risky business ventures. In my career, we've done a couple of things that would be considered "hard", but in each case we've leaned heavily on papers published in academia. The best example might be when the team I was on did shape recognition from hand drawn shapes to shape objects in a drawing application. I've occasionally been asked to solve some hairy caching/concurrency problems, but again I've gone straight to the literature.

My brother worked in a company that was doing circuit board design (simulating crosstalk, etc). Their work was highly theoretical, but they had electrical engineers doing the research (and were actively collaborating with a university). His job was 99% implementing code.

I feel that programming is more about handling complexity than it is about solving other problems. You sometimes dip your toes into solving problems in other domains, but the biggest value you can give as a programmer is in creating a code base that is both simple and sustainable (and keeping it that way). This is the hardest problem I've ever worked on by far. It dwarfs any of the other problems I've tried to solve. I sometimes get a bit depressed that others don't consider it a "hard" (and therefore interesting) problem.

In my experience, less than 5% are actually writing algorithms and solving harder problems. I work at a consulting firm with 100 or so developers, and most seem to do "simple" stuff most of the time.

The most complex thing I have heard of is someone who wrote a kalman filter thing for some part of a nuclear reactor. To me it seemed hard since I don't understand the math, and apparently people around him was happy with his solution.

Also here in Sweden I don't think the CS algorithms are very important at all when getting a job. I have just not seen it that much, which is sane since nobody seems to really need it anyway...

I googled kalman filter https://www.bzarg.com/p/how-a-kalman-filter-works-in-picture...

Looks interesting!

And obviously the standard CS books tell you little about numerical and stability issues you get to solve to have an actually really working and accurate Kalman filters.

It might be touched upon in doctoral or post-doc courses...

Whereas electrical engineer gets drilled about noise, stability and uncertainty all the time. Rarely even about mathematical chaos and chaotic systems.

The big secret is that everything is a CRUD app. It doesn't mean that the C, R, or U steps can't involve hard problems.

I had to implement a quadtree from the ground up, because existing solutions didn't work, when working as an SAP consultant on some dashboarding tool (I also had to know what a quadtree was!)

I now work in a generic unsexy role doing release engineering. About half my job is generic software engineering, but the other half is comparatively academic. I was reading academic papers on Aho-Corasick derivatives last week and writing statistical tests in jupyter notebooks this week.

And my interview questions are generally inspired by problems I've had in my work, just normally somewhat simplified since the way I phrase them justifies the need for a specific class of solution much more clearly than whatever nonsense I encountered in the first place.

I would risk to say 95-5% Mostly researchers are creating those solutions for hard problems, and, in the industry, only a few have to bash them. The rest of us are concerned with keeping APIs responsive and getting that damn button the correct shade of blue.

Sometimes boring CRUD apps turn into interesting CS problems due to the data model and ways that the customers expect to visualize the data, while keeping the application responsive.

No idea, but based on other comments here it seems that a significant number of HN users who commented here are in the CRUD apps and/or yet another SAAS app category.

Literally just pushed this up yesterday https://github.com/pmarreck/mega_xml This is the first time I've been able to convert one tree data structure encoded as a binary string into another form native to the language at hand, in a functional language. One of the hardest things I've ever done as a developer lately, having no CS degree (I did take some electives, though) and just learning-by-doing.

> I’ve been a professional developer for 20 years and have never had to recite CS algorithms or solve obtuse problems.

I'll see your twenty and raise to 38 on the same basis. In fact no one I know has ever had to solve the algorithm problems that seem so common now (in the US at least). The nearest I came to it was in a previous career as an electronics engineer where the interviewer gave me the circuit for a simple common emitter amplifier and asked me to describe it's characteristics. He was very apologetic afterwards and said that experience had taught him that recently qualified electronics graduates often had so little practical experience that he could not afford to employ them as it took them too long to get up to speed; so he used this simple test, and it was very simple, to sort out those who could be gently shown the door immediately to avoid wasting his and their time.

I am guessing you don’t work in the Bay Area.

Nowhere near it - and neither do most other developers in the US.

Wasn’t trying to imply that’s the case. I’d love to move out of the Bay Area, just to get away from the whole “leetcode or GTFO” interview style, but the fact that there are so many opportunities around here keeps me here for the moment. Well, that and I can actually make enough money to pay my student loans while living somewhat comfortably and saving a little money. If I knew anyplace that had decent weather where I could do those things, I’d be looking at the next flight out.


That is just Plano. There are arguably more opportunities around each of North Dallas and Addison. The cost of living here is a third of the bay area and that isn't including the size of house. This is why California is bleeding 60k people a year to north Texas.

Yep, quite the burgeoning tech scene in Phoenix as well. Compared to California it's quite affordable if one can put up with four months of pretty extreme heat per year.

Houston, Austin, and San Antonio have quite a few jobs and decent cost of living, too.

Give SoCal a shot. You can get very competitive salaries when compared with NorCal right down here, and the cost of living is not quite as bad.

I'm hiring Ruby devs down in Costa Mesa, and I don't ask any algorithm questions :)

You should email me. It's in my profile. I have... questions. :)

This is something I'm struggling with right now. It seems like there are endless opportunities but are they really opportunities if you can't get past the "leetcode or GTFO" barrier? And even if you do get past it that only gets you in for a full day of being grilled on other arbitrary measures with zero feedback as to why you didn't get the offer. I feel like spending time trying to be able to solve these coding "challenges" only detracts from time I could be spending learning more useful ways to code or actually, you know, building applications.

I've had two successful exits since the early 2000's, most recently one that of a company that I built, wrote the product for and sold to a company in 2014 (all modern web based stacks, technologies etc). The last one, I ran engineering which had 25 developers and we shipped a brand new product to market and I helped sell that company (the company that bought me out) to a larger company. All the while, still writing code, building product, etc.

I had a three year earn out, finished that and decided to get back into the workforce and get a job at a senior or above level (thinking Director, Manager, etc). Guess what, not only did my age hinder me (I'm 53), but my lack of CS math background seemed too in an interview process. Various interviews had me solving what I consider not only impractical, but almost silly puzzles / math problems that not only didn't apply to the company I was interviewing with, but didn't apply to anything real-world -- it felt like it was a way to:

- Weed me out because of my age - Make the company seem like their vetting process was "Google like" and "trendy" - Make the interviewer feel entitled or the company be "elite" in their process

Part of me realizes that some of this is to see how well someone problem solves. I get that. However, I had one interviewee actually bungle up the questions, in fact, I had to point out at one point that it appeared that they described the problem wrong. When I got my answer wrong, and then asked for the answer, the interviewee clearly realized he setup the whole problem incorrectly.

Oddly enough, this is the part that bothers me the most. I've been asked many times for my GitHub. I have lots of solid examples to see my work. I've also been asked to do a programming challenge, which almost always I nail 100%. But it's always these "trap" CS challenges that I feel are used to eliminate someone based on either HOW they solve it or a way to justify them out and not hire them based on other factors (age, fit, etc.)

I actually had one that was a whiteboard session where the CTO asked me to solve the problem on the board "using code of your choice", so I stated, "Look, since I know multiple languages, I'll use pseudo code to walk through the problem and explain the answer"

When he described what he wanted me to solve (badly I might add), I wrote the pseudo-code on the board and described the problem as being solved by using regression. Which was 100% the right answer but because I chose to use pseudo-code not say, Python or JavaScript -- he told the recruiter, "he couldn't solve the problem I was looking for him to solve." When pressed by the recruiter about the solution, he gave a link to the problem in his Github, which of course was verbatim of what I described but in Python -- using regression.

What I've learned from this is that I should contract and consult. Most of these smaller companies want what they want in the way of an employee and are seeking the 10X developer, culture fit and someone in their own age group...

As has been said here many times, these puzzles test for corporate compliance, not for problem-solving ability. You're being assessed on your willingness to spend x months studying to a certain industry-wide norm, and to then pliantly follow interview instructions to reproduce one of the stock answers on demand in the format requested.

If you deviate from the rather arbitrary requirements you will be considered a no-hire.

Other industries have a formal study, exam, and professional certification process. Developers don't. [1]

In the absence of that, these interview play-throughs are treated as an ad hoc substitute. They're a passable fit for generic ass-in-chair juniors, but a very poor fit for anyone looking for good seniors or a CTO.

[1] In the UK you can become a Chartered Engineer via the British Computer Society. I don't think there's anything equivalent in the US, and I'm not sure how many shops in SV even recognise Chartered Engineer as a professional qualification.

Brilliant comment. Shouldn’t you be building startups yourself instead of trying to fit into these teams? I think your skill set speaks for itself.

Recently I joked with the interviewers over Skype screen sharing that I probably wouldn’t be fast enough to get a pair programming exercise done with 3 of them watching me. And that often these things you either see right away or struggle with. They all laughed and agreed.

I wanted to test a particular function after setting everything up, installing jest etc. But was told not to because deconstructing xpath was an implementation detail. No one could see what was wrong with my working and all three of them said it’s the way of working and not if you happen to get the answer on the day.

Of course they failed me saying I was too weak at programming. I won’t be doing coding over Skype screen sharing again and with more than one person in the room, it’s just too stressful and random.

I've done many startups and I have to say I love it, but the struggle to fund it properly (to it right) is what turns me off. I'd rather bootstrap myself (these days) and go the "indie hacker" route and not have to deal with fundraising -- build a product myself, sell it and roll it all on my own. That wasn't possible 20 years ago, it is now.

So yeah, I've focused on the executive level, CTO, VP, etc, But with that, you have to either give up coding and just manage or go to a tiny company to be the "key player", but then you're typically at a smallish company with little to no funding. I've been doing that lately, I'm at a small start up running engineering, but I'm an "employee", not a founder.

There seems to be a clear bias with VC companies against someone my age and background. Not to say I don't have a network I could probably work and get funding, I could. But I also wanted to get back to square one and work with people again and NOT have to deal with things like Healthcare, stock options and "hey, that person needs a week off because their cats sick." -- I'd rather just CODE and learn more, enjoy the art of buildings things without the pressure of an investor looming over you.

I've made enough money to be comfortable, but I still need to earn a living -- I haven't made that "FU" money and my wife laughs and jokes that for as much success we've had, even if I did get the "FU" money, I'd still want to work 70 hours a week and write code... ;-)

About your Skype coding comment. Yeah, new trend is to "pair" with someone online in an interview process and go through programming challenges. I'm OK with that, but I don't work well that way. I work better in a situation where I can think and spend the time myself on the problem. My brain isn't wired for "fast and rapid", it's more of a "trial and error" until I get it working, then later on optimize and make it better. I do terrible at that first pass, always been more of an interactive developer who starts with something that works and then over time perfects it. That style SUCKS on a pair programming exercise.

If it helps any, I’ve been one for 10, and I hadn’t seen any problem like it until I started applying to startups.

The crap I was asked was pretty insane to be honest.

well your experience is highly atypical.

Good for you, but your interview experiences would be atypical these days

Right. Having my own companies and hiring people over the last 20 years has jaded me. lol

you most definitely seem to be. i’ve both had and seen interviews requiring solving by hand various encryption algs using only a whiteboard. maybe you don’t require it but there are plenty of places that do

As a self-taught programmer who doesn't have a CS degree, my experience has been that this is not a significant hurdle to any workplace that I would seriously consider applying.

Where do you find jobs to apply to? I am also a self-taught programmer without a CS degree, and it seems that a surprisingly large portion of companies use obtuse algo/whiteboarding interview questions. My objection is less that I don’t know or can’t learn them and more that it seems like a waste of time to prep for stuff that isn’t useful.

Those companies aren't hiring, they are just sifting market for rock starts. I have seen this in numerous places already — when a company has enough product leaders, but still enough money/time to hire a couple more, they begin whiteboarding people. Several years later those product owners will leave, and suddenly the interviews are reduced to "you worked with <insert technology name>? Know what <insert technical term> is? Accepte^W erm, I mean we will contact you tomorrow!"

Several weeks after passing the interview you start asking colleagues about their own interviews. And everyone has wastly different experience. Some were hired after being harrassed for hours. Others got job thanks to friendly tip...

this is false, you can’t blanket companies like this. the job i’m currently at required me to find all palindromes in a set of strings. the company makes media management software.

As a self-taught programmer who doesn't have a CS degree, my experience is substantially different. There are many places where I would seriously consider applying (FAANG) that this would be a significant hurdle.

I've taken to competitive programming as a way to prepare myself, but I'm a long way away from being at a level where I'm comfortable applying to the companies I'd like to work for.

I think a lot of people like you and I pretend to make the choice of, "I'd never work there" when the reality is, "They'd never hire me", and it does everyone a disservice to continue to perpetuate that lie. It's not a problem or a negative thing that FAANG would never hire me/you, it's just the truth.

FAANG would never consider hiring you or me as-is, but if we worked really hard for awhile, they would. This has nothing to do with our ability to do the job they'd hire us for, but that's the game, they want their candidates to be good at the game, and I'm at least willing to play. You aren't willing to play, and that's fine, but don't pretend like you're being the discerning one here.

As a person without the degree that works at one of these companies, I can honestly say that it's incredibly difficult to get in. What I haven't seen anyone talk about is how it haunts you constantly. Not necessarily coming from other people, but knowing that if someone wanted to call you incompetent, it'd be on you to prove otherwise since you dont have the degree to back up your knowledge. I wish I could go back and get a CS degree just to tame the thought that it could all fall apart so easily.

Exactly, you took the words right out of my mouth. I'm 6 years in as a web dev and still feel the downsides of not having that paper. There is that constant, need to prove feeling that lingers in my mind. I'd love to work for a big company but I am stuck in my country. Visa approval requires that paper to prove you're skilled. Stuck with opportunities that pay really less, compared to Europe/USA. Don't know about you but, I recently decided to bite the bullet and join a CS degree on the side. Going to be tough 3 years, but it'll be worth having that paper once in for all.

> Visa approval requires that paper to prove you're skilled.

There are ways to go around that - in some countries, US among them, you can count some years of specialized work experience in the field in lieu of formal education ("degree equivalence" - I believe). I got a work visa in Canada on that basis, and later L1, H1B, and finally a green card in US, without any degree.

With respect to US specifically, google for "USCIS three-for-one" for more on this.

Yea, but was it a relatively easy process? I've heard of USCIS too, but the process looks complicated.

I don't really know - in my case, it was all handled by my employer and their lawyers; all I did was gather the documents they told me they'd need (basically whatever is necessary to prove said work experience).

So how much do you earn there?

I am self-taught and work at Apple and the interview process is team by team. My team doesn't care whether or not someone has a CS degree and we don't ask algorithms questions. We care a lot about software engineering as a craft, though, and ask architecture questions.

Of FAANG, I only know of Google having a standard interview for all software engineers across the company (and one that is algorithms-heavy).

Plug: If you do iOS engineering, we are hiring: https://twitter.com/conradev/status/1035244142488506368

I am self-taught, no degree whatsoever. I didn't have a problem landing a job at Microsoft regardless, with a few years of mostly C++ experience under my belt. Wouldn't even say it was hard. And no-one at work had asked me if I have a degree, ever since that first interview.

Now, that's not FAANG, technically speaking (although FAANG was always about stocks, not job culture). But for what it's worth, I've had recruiters from Google, Facebook and Amazon try to lure me over. None of them indicated that my lack of degree is an issue for them.

Maybe that's team-specific, I don't know. But it's certainly not true that they'd never hire someone without a degree.

I think people are over-emphasising the importance of a degree when it comes to CS (obviously some workplaces filter by "do you have a degree" but I wouldn't want to work in such a place -- clearly they don't care about you as an engineer).

Sorry to be a bit old-fashioned, but a degree isn't the most important part of going to university -- it's the education you get. I would argue that it is very difficult for someone to learn about data structures and algorithmic complexity (+ algorithm design) without taking a university course or doing some pretty intense self-study. It's not something you can pick up on the job. And this is knowledge that I think more folks in our industry should have.

So you might be doing totally fine without a degree, and that's great, but I imagine that you also have some CS knowledge that OP doesn't have -- and maybe you picked it up from somewhere or did some study on your own to gain it. If I was a hiring manager I wouldn't filter on degree, I would filter on some sort of working knowledge of CS (and, for reference, inverting binary trees on a whiteboard is not an example of "working knowledge").

Oh, absolutely. When I say "self-learned", that includes bits and pieces of CS. E.g. I wrote a BASIC-to-C++ transpiler back when I was 14; and to do that, I had to learn things like recursive-descent parsing, for example, or how hashtables work (because I wanted my dialect of BASIC to have them) etc. None of it was from CS courses or books - just looking stuff up on the Internet as needed, often reading others' code. This kind of learning from experience is not a well-organized process, and the results were often a lot messier than they really needed to be - and would likely be with more formal education like SICP! - but it works.

I need to tap your brains. Contact please

I think you may be selling yourself a little short.

Many, though perhaps not all, FAANG interviews do not involve needing to know THAT much CS trivia. The common topics (for many interviews, it depends on the company, and at non-homogenized companies, on the team) are:

- What’s a graph? What are some interesting strategies for walking a graph? Any gotchas to look out for?

- What is algorithmic complexity? How do you measure it? Why does it matter?

- Are you conversant with middle-school level arithmetic and geometry?

- Can you describe the strengths and weaknesses of the 4-5 most common simple data structures?

- Can you listen to problems as they’re described, and ask good clarifying questions (the most common problem is here, people didn’t bother to take the time to ask clarifying questions)?

- Once you’ve nailed down the problem, can you structure a few nested for-loops with relevant tests and perhaps a few simple auxiliary data structures?

- Once you have a potential solution, do you test your work? Do you skip over your mistakes pretending they don’t exist? Do you take hints when your mistakes are pointed out to you?

- Do you admit when you don’t know, then try exploring anyway?

Seriously, this is the entirety of what I see most FAANG interviews covering. If you’re a competent self taught programmer, you need to study a tiny bit about data structures and algorithms, stay calm, ask lots of questions, and just execute.

I get that there are lots of horror stories out there, and I genuinely feel for people who get super anxious when asked to work with an audience.

But if anxiety isn’t your problem, I encourage people to try different teams/companies if they’ve mastered what I’ve listed. FAANG really don’t want to put the bar absurdly high, they want a relatively easy level of CS knowledge.

Hey, just wanted to say I think you have a very fair perspective here, and I'm not sure why you got downvoted (perhaps your comment was perceived as rude.)

I'm actually not interested in working at FAANG. I don't want to live in California, I don't want the long hours, I don't want the stress, and the products and culture are not very interesting to me. The salary is pretty much the only selling point IMO.

However, you make a fair point: If I _did_ want to get into one of those companies, I would need to study CS (academically or non-academically).

I have to point out something that I haven't seen anybody say here -- there is a huge amount of variety in the difficulty of these sorts of interviews.

I assume that all FAANG interviews for entry-level software devs are akin to the standard Google interview, for which you are expected to study your ass off. I have not interviewed for one of those companies, but of course I know how much people study for them, and it disgusts me. However, I have had plenty of interviews which did have an algorithm-type section (the majority of interviews I've had have had something like that), and I no longer hate on companies for doing _that_. Plenty of the problems are relatively easy, once you figure out how to talk about them -- and being able to talk through your work is a legitimately valuable skill.

But, companies that expect applicants to put in the kind of work Google expects in order to stand a chance truly are not companies I want to work for. To some extent, it's just shitty; this "game" is mostly a test of how much time you have to spend. That cost is a lot higher for people who are less well off, which irks me, but that's true of most things in life.

The thing is, you talk about being "willing to play" the game. I don't want to work in a company of people who played that game.

First -- Playing the game means sacrificing important things; you can't spend all your free time studying which data structures to use for esoteric string manipulation problems, etc. AND spend all your free time learning the fine point weaknesses of different databases, good programming patterns, etc. By the time I started interviewing for my second job, I'd nearly burned myself out making certain I was learning how to do things right, learning how to be a good programmer. My free time was spent polishing the things I was working on and endlessly reading about how to do it even better. And then I was able to go into interviews for the jobs I was interested in and do what you're suppose to be able to do in most other interviews (programming or otherwise); actually talk about the company, their pain points, possible solutions they hadn't thought of but I had experience with, etc. At that time, I could not identify anything but the simplest algorithmic complexities... but to learn more than that would have been to choose studying useless information over useful information.

Second -- What makes a person willing to play the game, when there are plenty of other companies with interesting problems to solve and good salaries (maybe not AS good)? I can't help but feel there is a cult-like love of these big companies (or maybe it's the desire to prove oneself, since only RealProgrammers work for Amazon). And I don't want to work with a bunch of people who are extra excited about something I just don't value.

Maybe I haven't been reading the right stuff, but I just don't see the appeal. I don't particularly care for any of them as companies. Sure, if Amazon decided to pursue a pilot project aimed at providing its customers with low-carbon-footprint foods, I might want on board that project -- but not just to Amazon as a whole. Yes, these companies are large and well-known, but I don't particularly care if it's one million or one billion people who download an app I worked on. I know that getting a job in one of those companies doesn't mean you're going to do something interesting or big. I've had classmates get jobs at Google and I've worked with Google employees on certain projects, giving feedback etc. There's nothing I've seen about their jobs or projects that were particularly amazing or wonderful, except for the part where you then get to say you work(ed) for Google.

To play devil's advocate, "which data structures to use for esoteric string manipulation problems, etc" is the kind of thing that interests me (and presumably some others) a lot. If I wanted to go for a FAANG interview I'd love to brush up on the algorithms and data structures stuff that fascinated me in college and I haven't had much cause to think about since. There are certainly other things I'd rather be doing, but it wouldn't at all be a miserable chore like you're describing. So maybe they're looking for people who think about these problems more like I do (and I'm not by any means saying I'd pass the Google interview) and less like you do. They have the pick of the litter after all.

On the other hand, there's the well-known story of the Harvard MBA answering Orkut support tickets so Google probably doesn't need that level of talent. But if they can get it, why not?

> 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

This attitude only seems to exist in companies that are seen as 'top n'. Want to stop interview in this manner? Stop applying to these companies.

Unfortunately if you want to get the paycheck that comes from these types of companies, you have to play their games. You can't complain the interview system is broken and then only apply to jobs that offer 150k total comp and have brand name recognition.

For every FAANG with a broken interview system, there are 5 other decent companies with intelligent people that don't do this crap.

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

I have yet to see a definition of what “invert a binary tree” even means.

I think "mirror" is a more intuitive description of the problem, but essentially you reverse all of the left and right subtrees. This Quora question [1] has a few different approaches listed.

[1]: https://www.quora.com/What-is-the-algorithmic-approach-to-in...

That doesn't sound like "inverting". If that is what it means then it is indeed a bad name.

I always thought it means making one of the leaf nodes a root of the tree. Physically, it would look like taking one of the leaf nodes with your fingers and "hanging" the tree off of it.

Inverting means inverting the sort order. The easy answer is to encapsulate the tree in a new structure and add a Boolean flag called “inverted,” since you’re just reinterpreting the meaning of left and right children.

What you describe is called “rotation,” and is used to rebalance.

invert: to reverse in position, order, or relationship

I'm confused. Doesn't the operation described in those answers just rename each node's properties, but leave the topology of the data structure unchanged?

Meaning one could just have the code accessing the tree swap which names it accesses, and the tree would behave as "inverted" with no actual need to invert anything?

It's when you swap the left and right branches of every node, e.g.:

    def invert(node):
        if node is not None:
            left = invert(node.left)
            right = invert(node.right)
            node.left = right
            node.right = left
        return node

Or simply

    node.left, node.right = map(invert, (node.right, node.left))

Coalescing those four lines onto one is fine, but writing:

    map(invert, (node.right, node.left))
is definitely not simpler than:

    invert(node.right), invert(node.left)

Indeed - I just wanted to write it in a form that could easily be mapped to languages which don't support multiple simultaneous assignments :)

I read it, tried it out and it didn't took me long to understand and solve that issue.

If you hack around for a long time and you never ever felt the need or motivation to understand very simple tree algorithms, okay. But don't rant when a company like google expects that from you.

He also answered, after a few years on a website about it:


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

You can apply software engineering to develop an application, but you can also do application development without any proper software engineering.

Software Engineering is a design discipline, management discipline, and engineering discipline. Application development is (principally) the act of building an application by writing code. It doesn't require design, management, or engineering discipline to accomplish. But it's better if you've done those things (minimally, the engineering and design portions).

At the same time, a junior software engineer may not be responsible for anything but the writing of code, where others have determined the design and engineering aspects and are conducting project management for them. Or with only limited responsibility (such as developing tests for the aspects they're responsible for developing, which is a part of the engineering discipline: V&V).

In practice, the main difference is the pay / relative "rank" within a company. Employer's perspective: Want to hire a software engineer but don't have the budget? Create a new role, call it something else, now the pay difference is justified.

Context - I'm a software engineer by title but my job is application development. Which is hard, mind you! It looks like simple coding but it involves prioritizing, making smart decisions, and making all stakeholders happy.

I've worked in both of those environments, where my titles were literally "application developer" and "software engineer". In the former, we did a lot of things without process and worked on a wide variety of applications and in the latter I worked in an Agile environment focusing on a core product.

As with most HR departments, it could be a classification required for salary, which also highly depends on work experience and not necessarily school background.

- Someone who's job title is much fancier than otherwise necessary

Nothing. It sounds like this person is inventing their own dichotomies.

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.

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!)

I think I have my geek bona fides, but, studying subjects like Domain Driven Design, Clean Architecture, Patterns of Enterprise Application Architecture etc.

The hard problems that I think most people end up solving are more often business, people and process problems than computer science problems.

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.

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

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.

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

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

What's the point of reimplementing a set though? It already comes with the language, and the language's implementation is probably miles better than what you'd come up with anyway.

I'd be more interested to know whether the candidate knows what a set is, and how it differs from an array or an object, and when might it come handy. But reimplementing what already comes with the language? A waste of time, and (hopefully) not representative of the work they'll be doing day to day.

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.

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

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.

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


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.

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.

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, hash maps etc). The crud part can be your familiar part where you have a good feel of what's what, and the report/test/whatever page can be your sandbox to see how your experiments deal with your data.

One of the books I found helpful was Data Structures and Problem Solving Using Java by Mark A. Weiss.

A softer start can be found with http://interactivepython.org/runestone/static/pythonds/index...

If you want something using languages you already know, that's fine too. Say for example you wanted to simply know how to build a tree, or more generally a graph. Those concepts may sound big or complex, but they are only as big or as complex as you want them to be allowing you to build a simple version (i.e. a class that is a node in a linked list, and it holds just a number as a value and the next node for your list as a pointer or value or whatever you like). It's something you could do in 10 lines of code just to get yourself started. Building on top of that is a whole lot easier than jumping straight into AVL trees and A* path finding algorithms.

Starting light, say, making a few things yourself in a language of your choice will get you a good feel as to what you want to explore and how easy it is to grasp the concepts, for example:

- linked lists and doubly linked lists

- binary trees (binary doesn't mean binary data, don't worry)

- sorting (check quicksort, shellsort, bubblesort on wikipedia for starters to get an animation for an idea what it is)

- heap

- stack

- (priority-) queue

If you prefer watching videos/working through a MOOC for this stuff, I can highly recommend Robert Sedgewick's Algorithms I on Coursera: https://www.coursera.org/learn/algorithms-part1

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.

Take a look at "How to design programs"[1]. It teaches a systematic way of attacking/solving problems.

[1] https://www.htdp.org/

I went through this too! I'd definitely recommend giving it a go if you're up for it. You may have those moments of utter confusion, but you'll definitely learn a lot!

Good job in putting it tactfully. I think you have it exactly right, there's a different skillset used in interviewing often, abstract problem solving - that really is different than the skills to write a crud app.

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)

I have to agree with you. Especially the ceasar cipher example is literally about following the steps, everything is outlined in an almost step-by-step fashion. The only part of the exercise that might be new to OP is programming in C - but the algorithm itself is stupidly well explained and the bullet points literally tell them what to do. It's as if they read the first paragraph and decided it's some arcane voodoo magic so it's not worth reading any further.

It might sound a little bit too harsh, but I totally agree with you. Furthermore, provided examples are missing search step – there's no need to come up with solution, because solution is explicitly specified in task description.

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.

A modern application developer should be at least vaguely familiar with Unicode, so character encodings should not be an entirely foreign concept.

You should be able to use a search engine to figure out what ASCII is, though. That's fair game to expect. The text document mentions ASCII, so it's not like a developer would be left without a clue.

In this modern time, no one needs to know what the ASCII code for @ is, but I think it is logical to expect people to know that some encoding exists and that letters can be mapped to numbers.

Also, all the ASCII you need to know to solve the problem is explained at length in the problem description.

I couldn't tell you offhand how to convert between an int and an ASCII character.

...But if you give me a second...

Now that I've typed "ascii character codes" into google, I can tell you how to convert between an int and a character.

You don't have to memorize everything. Well over half of our job is knowing how to find information quickly.

Remember the context, this is an introduction to computer science course. The slides for the lecture for that week most likely explained everything you need to know to solve the problem.

Even completely ignoring ASCII, it is trivial to create a dictionary mapping integers to characters.

ASCII does still map to the most commonly used parts of Unicode, so there is that. I would agree that I wouldn't have the foggiest idea what most of the ASCII character codes are if I hadn't cut my teeth on archaic stuff like QBasic; I remember a lot of silly little toy assignments doing rot13 or manually upper and lowercasing strings. But they do come up from time to time when you get into, for instance, JS keydown/keyup events. But any competently designed modern API ought to at least have named constants for this kind of crap

Don’t ask me why I remember that the lazy non performant way to put a character on the screen in assembly was to store the ASCII number in the A register and


The fast way was to copy the bytes directly to the $400-$7FF address space and figure out the non contiguous memory map -> screen yourself.

(After a "...I never used that in QBasic!", google explained that this is for the 6502)

I'm right now trying ti get around being made to learn ASCII for vocational school (some certification is useful to pass automated recruiters).

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.

We probably underestimate how many people out there are just copy/pasters. No offence OP but I hope you dont work on anything that handles money/user data/requires security.

I do! I develop bespoke add-ons for the accounting software Sage 200. Fear not, my work is peer-reviewed by my boss who has 35+ years experience in the field.

If I get something wrong, my boss lets me know, I learn from my mistakes and ship out good quality software.

I just replied above, but I've never been amazing at being able to figure out how I should be using for loops to solve problems quickly and efficiently.

I do tend to make things harder for myself, as my boss and fianceè have told me before.

I usually end up with a very convoluted solution which I end up coming back to and refactoring the next day.

I was actually going to recommend exactly that - I find that, when I have a problem that I’m having trouble solving, just brute-forcing the damned thing helps me focus on the hard parts of the problem, and then I end up rewriting things in a “better” way that I’m actually not ashamed to put my name to.

Correct first, then simple and fast later. With more experience you'll be able to devise simpler, correct first solutions that you can then speed up later.

I'm curious, what sort of approaches do you take to your programming tasks at work? Is it more like e.g. writing SQL where you'd think more about relating sets of data rather than looping over individual items?

There's an old Kent Beck quote that fits here... "Make it work. Make it right. Make it fast." Your approach fits that.


I've seen so many projects where the developers have taken this to heart way too much. The problem is they use it as an excuse to give up after stage 2 thinking stage 3 can come along when it actually becomes a problem.

The thing is that performance issues tend to creep up on you so slowly that you don't realise it until you have a very important client with tons of data screaming at you to fix it now. To fix it then you have a huge architecture issue because the whole system is so inefficient. So rather than rewrite the entire code base to actually be efficient you are forced to hack in some kind of caching solution. Then your problems multiply.

Make it fast from the start. Premature optimisation being the root of all evil is a lie!

I'm not sure you two actually disagree, but rather that you're thinking on different scales. Make it right, then make it fast is usually talking about specific snippets of code, rather than the whole program, so your whole program should be "made fast from the start" because you went through the process of making it right and then making it fast on the components themselves.

Yes, that's a great way of thinking about it!

If you do that you'll write great, fast code but it'll take you longer to do it. That's great if you have unlimited resources, but try doing it in a startup where failing to ship in a month means your whole business fails.

So... Maybe don't prematurely optimize?

What is your hypothesis on where that lie comes from?

Ok, it's a bit of an exaggeration and obviously depends a lot on what your definition of premature is. I guess the statement is actually a tautology, by definition premature means too soon. I just see people who think that any optimisation at all is bad, whereas in a lot of instances optimisation as you are writing the initial code is not premature. In my experience...

I mean the question also is whether OP has done any programming in C before. If the majority of your expierience is in VB.NET and web technologies I can see this being a major hurdle aside from the actual algorithmic problem.

I don't think C is the issue here but mental shift . I have suffered from same situation in the past. He should just spend time and interpret the question, internalize it , and then code it

You don't even need to understand ASCII. You can hard code an array of all the letters in the alphabet, search for a given letter and replace it with the letter 13 places ahead in the array. If you were really lazy and didn't want to worry about the logic for rolling over when going past Z, you could even rewrite the first 13 letters at the end.

I have no trouble believing that there are many developers out there with no understanding of character encodings. Because I have seen many applications where the handling of character encodings is nothing but kludges upon buggy ad hoc kludges.

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.

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.

> heavy on straight CS theory. “how do you sort an unordered binary tree in place“ kind of thing.

I was having a related conversation earlier, and feel like I'm reprising the same argument for a new audience, but... I don't see what is either Computer Science or theoretical about that. It seems like an eminently practical task: Handling things in a tree structure, sorting items, and doing work in-place to conserve resources are all very concrete, real-world aspects of writing software. You might not need them in _every_ case, but they aren't really "theory" in any real sense.

If you’re a bog standard “dark matter developer” using high level languages or writing your typical SAAS app, you wouldn’t need it.

I turned down a job offer where the interviewer was more concerned about whether I could write a merge sort on the board (I did), than whether I could design a system. It told me a lot about the kind of people they hire.

I spent my first 12 years as a developer doing a lot of bit twiddling in C writing cross platform code with nothing but the standard library, but these days if someone asked me how to sort I would call a library function. Heck even C has a built in sort function.

But those issues are all totally orthogonal to my point.

You can argue that someone doesn't need something, that it's the wrong level of abstraction, or that it's not an appropriate interview question. I even agree to some degree. But that still doesn't make those "CS theory" subjects.

If you are writing a webapp in PHP you need none of these things.

I've never been so great with figuring out loops to iterate over things and the like.

And some of the questions being posed (which are all expected to be solved in C) are a little tricky for me to figure out on my own without some of the niceties which I have been exposed to in higher level languages.

Perhaps the hardest of these was the Credit Card Validation example.

I was stuck for such a long time on trying to figure out how to utilise an array with for loops to multiply every second number of the card backwards.

This is Introduction to Computer Science and all of this is from week 1, so I was pretty much falling at the first hurdle.

Can you solve these problems in your language of choice then? How can you write business logic at work without loops?

I tried looking up various solutions in languages which I knew a lot better, so, and example of one of these would be Go.

The logic was there, but I still couldn't understand most of what was going on, unfortunately.

Through trial and error, I eventually managed to get something working.

>How can you write business logic at work without loops? It's not that I don't use them, it's that I have a hard time figuring out how to use them in the context of solving the problem.

Personally, I would feel trying to find the solution by parsing other people's code would be way more complicated than just coming up with your own solution.

I would forget about C, though, and try to do it in a language you already know to begin with.

To be honest I also find it very difficult to relate, as especially the Cesar Chiffre seems like such an easy problem. I only have to read it and my brain already maps out the solution. (I guess you could call it a No-Brainer, except that it seems to be a "Brainer" :-)

I honestly can not imagine how you usually code.

However, I want to say I remember my first year of studying mathematics. Many of the exercises also seemed very hard back then, but looking back on them the following year, they actually seemed quite easy (well, most of them). So practice and experience really can work. No guarantees, though.

Personally I like "Project Euler" for programming problems: https://projecteuler.net/ I actually had questions pop up in interviews that I had previously solved on project Euler.

I would be very interested to hear about some examples of real-world contexts that have proven tricky. As much detail as possible is preferable.

Incidentally I describe my problems with math almost the exact same way - virtually nonexistent fundamental understanding, and so huge issues with abstracting out even the simplest real-world tasks. (My wake-up call was when I was basically just mashing buttons on my calculator one day when I realized I didn't know how to compute how much of X I could buy given that it was $Y per weight.)

Have you tried writing it out on paper as a flowchart? Sounds old school, but can help with visualising what's happening.

Loops become super simple when you see them as series of steps with a yes/no question of whether to stop or go through your steps again.

Draw up some boxes for every variable you think you're going to need, give them labels and add the labels to the flowchart.

This then allows you to run through the flowchart step by step changing the values in each box as you go.

> Figuring out loops

Maybe you're making it too complicated. The reason for loops is simply that you need to repeat an operation. Call it repetition if that helps.

- for x;y;z - repeat a specific number of times, or need an index #

- for x in y - iterate over container

- while x - repeat while a condition is true

- do while x - like while, but run at least once.

So, imagine we have a string and need to add 1 to each character. The second bullet above looks best, first if the language is lower level.

From this description it seems you have problems with implementation.

You probably lack in "coding"(maping solution to code) department - it's totally normal in language you don't work in day to day. You are probably less skilled in implementing simple, lower level abstractions - understandable given your background.

I have more exp than you - recently I was helping friend with python ML code - it took me 40 mins to code 20 lines. I don't feel bad at all, because even though I knew solution, to write it in python I had to google for each line and read docs to know range handling, dsl of libs, array comprehension syntax, lambdas etc.

Good news is that it's easy to get proficient fast by doing such exercises. I can recommend codewars.com

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.

Thanks for your reply.

To be honest, I'm only just able to write a program in C, which is the required language for these CS50 tasks.

I've never been asked to do this kind of work before, so I had no idea where to really start.

The walkthroughs provided in the course gave me a high level overview to the solution required, but being able to translate that pseudo-code, if you will, was the part which I was completely stuck on for a while.

I felt like I should have known at least how to start off solving this problem using prior knowledge I had gained through commercial experience, but I was wrong, and none of my experience thus far was able to guide me in the direction which ended up with an answer to the problem.

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, but exercise the discipline to persist through them and practice the material.

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'm glad to see this OP, as my post was initially going to be pointing you towards the support materials, eg.g Caesar: https://www.youtube.com/watch?v=ergRKv3DglI

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.

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.

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.

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

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.

The solution is C is essentially same as the one you outlined in Python.

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.

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.

Wtf? The second problem, listed after the Caesar cipher, is to reverse the hashing algorithm used for passwords on Linux.

What? How is that even remotely fair to ask as a challenge alongside something like the caesar cipher? One of these is a children's task while the other is a professional cryptographer's task. Am I missing something here? I'm sure it must not be terribly hard to do, but it's still so disproportionate to the previous task that I'm shocked.

You're not reversing anything first off, it looks like you're just call crypt(3) with every potential password since they put a five character cap on it. 600M or so combinations, so pretty trivial, but feels fun. I'm actually all for this assignment, it makes you feel all hacker typer.

Secondly, it's DES. DES hasn't been viable for almost two decades now.

There is very good advice and suggestions here, but IMO this thread is also distinctly "noisy" - lots of discussion and sharing, but very little in the way of a coherent go in this direction!.

So, I'd like to offer a couple of things that may be of immediately actionable, relevant assistance: SICP and NAND2Tetris.


SICP - the Structure and Interpretation of Computer Programs - was designed as an entry-level theory-first approach to programming. If you want to drown your brain in abstraction and get oriented quick, this will help you do that. It's very dense; expect to read it slowly, and also don't force yourself to block on one specific spot until you've understood it. If you can reach some sense of logic and order that lets you get through CS questions without breaking a sweat, who cares if you had to read the textbooks backwards or out of order.

I explicitly recommend SICP because you can find PDFs and EPUBs of it online (it's quite an old/classic book). I see a lot of book recommendations on here that I can't follow up on due to insufficient throwaway budget.

Plus, studying SICP with your fianceè will put her in a significantly better position to ace her CS courses.

I found this HTML rendering: http://sarabander.github.io/sicp/ (google will very readily find PDF and EPUB copies, but this version seems nice)


NAND2Tetris explains every step of a CPU from the electrons up (as opposed to the top-down orientation taken by eg JS, VB, etc), and has you build a toy CPU.


Unfortunately I've just discovered that this course, which used to be a little more open, seems to have closed down somewhat. Either that or I misunderstood and it was never an open course.

This being said, searching for "The Elements of Computing Systems" - the reference textbook for this series - is finding a PDF pretty quickly. The book itself is apparently listed on Amazon, so perhaps the PDF version could provide an idea of whether it would provide any value.

This course is taught in many CS classes IIUC, so studying this with your fianceè will also leave you both in a better position.


Also - I've been wanting to see how well I can explain pointers and so forth for a while now. Ping me if you like.

(I seem to be atrocious at email/IM-style communication, FWIW, so this may go horribly wrong)

There's also a Coursera MOOC on Nand2Tetris:


They sure make it sound more complicated than it really is... I'm a self taught developer too, so I get where you're coming from :-)

In javascript I would solve it like so: "HELLO".replace(/./g, character => String.fromCharCode(character.charCodeAt() + 1))

This would result in "IFMMP".

Basically it's just a matter of shifting charcodes.

Your solution would not work for all cases. For example, shifting "JAZZ" up by 1 should result in "KBAA" but your program would output "KB[[". You also need to handle wraparound at the ends of the alphabet.

Hi! Yeah, you're right! This was a 1-minute quick'n'dirty solution :-)

I'm pretty much in the same boat as you, so to speak.

I had a lot of fun playing with a few of these problems: https://adventofcode.com/

I'm not sure if they are classic CS though.

When I learned about the CAESAR cypher, I wrote a program called ENIGMA that changed the number of places shifted with each iteration.

Obviously I knew next to nothing about cryptography, and I did feel very smart about making a safer cypher.

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.

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.

But low-level C++ optimisation _is_ straightforward, if you're familiar with the CPU architecture. The issue is that most of the people don't want to deal with it since it's one of those areas which is not easily transferable to other domains.

It is the highly-technical BS. Just like saying high-frequency trading is an enterprise that requires incredibly smart people. No - it doesn't. It requires loads of niche knowledge that you can't apply anywhere else.

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.

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.

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

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

I work in CAD and my experience is similar to the guy who works in the games industry. I invent new algorithms pretty much all the time. It's a more conservative environment culture-wise. "Science programming" (when all your clients have PhDs and work in academia and you do models of something or other or interpretation of experimental results) is also very intellectually challenging and the CS skills are a HUGE differentiator. It's not for everybody though as in those jobs you rarely work with other programmers or have good code to learn from.

Games industry. I work as a C++ programmer on the engine team and I have to think about really strong CS fundamentals almost daily - like, not many other industries care about performance so much that you care about aligning your variables to squeeze everything out of your cache, or have a strong opinion about kernel vs user level mutexes because 15ns vs 5ns locking time is actually critical and your algorithm is going to fall apart if you miss the next CPU quantum. Especially with programming for consoles, your CPU architecture knowledge needs to be really top notch, and I would say doing a masters degree in CS has helped a lot.

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.

Could you explain why adding to the end of an array results in O(n^2)? From what I can find, it appears to be O(1). If you increase the size of the array by 1 each time and copy the old array elements over, wouldn't that be O(n) to copy the array plus the additional add, O(n+1) which is just O(n)?

Could you explain why adding to the end of an array results in O(n^2)?

If an operation does that n times, then it's O(n^2). It's very common for self taught programmers to write operations that do the naive addition many times. There have been entire consulting trips caused by basically that, including, so I heard, the one that brought a consultant into the Chrysler C3 project and sparked the invention of Extreme Programming.

4th one should be elective :-P

I disagree. I'm not asking for one to implement ACID transactions. Rather, just understand why people did it. I'm building a system which is relaxed down from ACID, which depends on idempotency and a single coordinator process to keep a cluster of servers from trampling on each other.

You need to know the rules and the reasons behind them if you're going to start "breaking" them. Otherwise, you're just acting in ignorance.

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.

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.

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.

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


I thought complexity theory was based on the fairly intuitive Turing machine model (of computation) and not religious concerns

Ideal Turing machines, god, what's the difference?

Scott Aaronson gets a bit carried away sometimes :)

Doesn't he have a license to get carried away?

I'm not sure, would have to check with the home office.

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.

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.

Knowing things like binary trees, heaps, B-trees, queues etc. are not history. They are fundamental to writing applications. Using one data structure or a particular sort method will make your application much faster. Supposed you have had a billion elements to sort, but you knew every element in that array is between 1-100. I mean a bucket sort would be much much faster than using a quick sort.

> They are fundamental to writing applications.

That's funny, I must not have written any applications in the past 14 years. (Seriously though, I read one algorithms book when I was 16, and used those algorithms approximately... five times... in the past decade and a half)

Serious question: How do you know that in the applications that you have written in the past 14 years, there aren't any spots that could be considerably improved in runtime behavior and cost?

I remember being a programmer before studying formal computer science, I definitely wrote some slow and bad code that I just didn't know could be much better, and/or simpler.

This remains a serious problem on my team- Over half my team members don’t have CS degrees. They get an enormous amount done, but there is often a perf or maintainability cost.

I have no intention of swapping them out because they ultimately provide enormous value, but it’s noticeable.

Is it the algorithmic efficiency that's the problem, or the ability to scale the application?

I've seen things some people wouldn't believe. mod_perl 1.4 on Apache 2.0 handling 350,000 hps dynamic traffic on twenty archaic 1U's. Five tiers of caching, serialized objects on local disks, NFS in production. C-beams glittering in the dark near the Tannhäuser gate. Who cares about inefficiency if it scales?

Putting aside the damage that issues with correctness can cause, the problem is exactly that if you e.g. wrote something that grows with n^2 instead of n log n, you cannot scale by "brute force" anymore, as the inefficiency very quickly outgrows the amount of resources you can add. Seriously, your thinking that "algorithmic inefficiency" can be countered by "scaling" is almost proving the point.

CS is by far not just about runtime complexity, but it's one thing that can bite you.

Also, all the components you mentioned were likely written, at least in significant parts, by people knowledgeable about computer science.

Scaling an application's operation does not directly relate to its algorithm's efficiency, is my point. Of course a really inefficient application can eventually become unusable, but even terribly performing applications can be "worked around" and thus scaled higher.

Say your app is using bubble sort. Egads!!! What a shit design. Clearly this is going to become a nightmare in real world scenarios. But wait - we can theoretically get to O(n) if the list is already nearly sorted. How can we achieve this? By monkeying with the dataset, queueing and batching operations, invalidating operations that take too long, artificially limiting the number of requests per second, or just passing the request to a completely different app depending on use case. It sounds insane, but if you can perform any of these things quicker than redesigning your app, so that it can continue performing under load, that's an example of "scaling" despite the application's poor performance.

Another example is the "scalability" of application development. Say you have an application which is basically O(1), but one day you find a bug in it. Even after you write and commit the one-line fix for the bug, if it takes you between four hours and two days to deploy it to production, or the validation process takes a month... You still have a bug in production for hours, days, or weeks. "Scaling" the development process can significantly reduce the amount of time needed to solve problems, or complete new features. It can be more beneficial to be able to ship code faster and more reliably, even if it isn't the most efficient code.

but even terribly performing applications can be "worked around" and thus scaled higher. [...] How can we achieve this? By monkeying with the dataset, queueing and batching operations, invalidating operations that take too long, artificially limiting the number of requests per second, or just passing the request to a completely different app depending on use case.

And that's a good thing? Part of my point is that this can be avoided, or at least have a higher probability of being unnecessary, if the proper basics were learned.

Wouldn't you wish the author would have just known how to properly sort a list[1] in the first place?

"Scaling" the development process can significantly reduce the amount of time needed to solve problems, or complete new features. It can be more beneficial to be able to ship code faster and more reliably, even if it isn't the most efficient code

Agreed to that, but as said, computer science is not just about runtime complexity. Knowing computer science might help you avoid those situations, or resolving them quicker.

I know that shitty stuff can work, even work "well enough", but going back to my original comment: Maybe it could work much better, simpler, more profitable if that's your favorite metric, with just the application of some basics, if they are known.

[1] Noting that "sorting a list" is a stand-in for all sorts of tasks that benefit from CS-knowledge.

Yes, absolutely it all could work better with CS knowledge. But CS is also definitely not a prerequisite to having functioning apps that can scale well.

CS can help you design the software equivalent of a Formula 1 race car. But most of us only need to work on things ranging from a Honda Civic to a semi truck. It's interesting how little of an education you need to work on a semi truck, even though it's a complex machine that does a tremendous amount of work, compared to the education you need to work on Formula 1 cars.

In the US, we have a big lack of tech talent, and I think part of the reason is the way people propose the requirements or education required to do these jobs. If it's a Honda Civic-level programming task, people shouldn't go through the expense and difficulty of a CS degree.

I think we managed to get on the same page then, I can agree to all of that.

It’s algorithmic efficiency and at a basic level- things like 9 levels of nested loops, each loop pass generating an http call (admitadly some of this is the platform we are using fault)

How do you ever know that there aren't spots that can't be considerably improved? Does it matter that much? Any inefficiency apparently wasn't bad enough to stop it being shipped.

I actually struggle more with not treating every problem like some algorithmic puzzle to be solved in one pass with O(1) extra memory and just writing stupid, slow, straight-forward code.

It's certainly good if you know how trees and linked lists are implemented, but as you point out most app devs are working on a higher level of abstraction. All of that nitty gritty implementation details are already available to application developers in convenient, well tested wrappers. You can easily go through your entire career without ever having to worry about how doubly-linked lists or B-Trees actually work.

> most app devs are working on a higher level of abstraction.

Until they don't, because for some reason the abstraction cannot be applied in a particular scenario (or actually could be, but it's not understood), or just does not scale anymore.

I believe that parent's point is that knowing things like binary trees, heaps, B-trees, queues is exactly like knowing history - in the example problem you give, you're not supposed to invent a solution and design an algorithm, you're supposed to know the (many!) historical approaches to historical problem, know their properties so that you can pick the most appropriate one, and directly use these methods (invented by others, studied by you) as-is instead of inventing your own solution from the basics.

My point wasn’t that they aren’t important, just that the OP didn’t need to feel bad about not learning about them yet. It was meant more to point out that learning the history of how other people solved problems can inform the way we approach new challenges, but that everything was unknown before it was discovered.

You are, in this case, better off just using the ultimate bucket sort: shove it into a histogram.

    hist = [0]*100
    for x in xs:
        hist[x-1] += 1
Epsilon algorithmic knowledge required.

>history degree in how we have solved problems in the past.

I like that, that's a cool way to think about it.

I've often thought it should be called "computational" science or maybe "skills in logical problem solving." Regardless of whether one pursues a career in software, a computer science degree is really good at teaching a person how to think.

Djikstra called it "computing science"

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.

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.

I'm happy I studied EE to work in Software/System Engineering. I always found it more helpful to think in terms of complex systems.

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

:) I made the exact same comparison in my comment.

Have not read your comment but it felt very natural and was first thing that came to my mind.

Car mechanics like software developers require a lot of tacit knowledge to be good at their jobs. It all feels like riding a bicycle, intuitive. It is difficult for me to understand a person that does not understand how computers work but when confronted by a person that does want to know it is difficult for me or even impossible to figure out where to start. I think that it is because I don't even have the experience being taught how things work, all my experience is about figuring it out by myself.

Same goes for mechanics. When asked "how do you diagnose any particular problem with a car" you will not get an answer because diagnosis is skill in itself and it is very intuitive and hard to describe.

My CS degree focused on business applications. Not only did it touch on algorithms and data structures, it delved into database architecture and GUI design. Your degree may vary.

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.

I completely agreè on your first remark!

> Just stick with "fiancee" without accents, and you can't go wrong.

Unfortunately you can... I've seen many uses in modern English where people assume it is the double e at the end that makes the final vowel pronouncable in French, with no mental model of what the acute accent is there for nor what the second e signifies, and hence described their male fiancé as a "fiancee". After all, fiancé (male) and fiancée (female) both sound the same in English, and if you spell "fiance" correctly but without the accent, it looks like it should be read as "fee-awnss".

In all though, I think this is a useful metaphor for the OP's question: as a working programmer, creating value for a business by building applications without having to understand what's going on inside the computer, he should be able to expect that his tool (editor/development environment) would not only autocorrect the spelling of fiancée for him, but in case of doubt perhaps pop up a wizard to politely enquire whether he was engaged to a man or a woman and adjust the output accordingly; meanwhile his betrothed is busy learning the rules of French grammar and orthography and asking him to help her understand how and why his tools work the way they do - something which he is, quite rightly, oblivious about.

Of course, if I found myself in the same position, and had the time to spare, I would try to work through the same course materials alongside her because my curiosity would see it as a fantastic opportunity to learn the CS principles that I never picked up in college; then when she or I got stuck on something, I could add the contextual experience I'd picked up from years of 'surface level' business programming to gain a different perspective on the course content and hopefully fill in what's missing. Just like, for example, if I had years of truck driving experience I may have a little more insight into engine maintenance than someone who doesn't, but it doesn't make me an expert in that area.

Failing that, I'd explain honestly that our two disciplines have nothing in common other than vaguely being "connected with computers", then try my best to help her out in the same way I would if she was learning law or history or chemistry - just keep asking questions about the parts she does understand, the precursors to the problem she is up against, then try to reason it out loud with her and more often than not, the act of explaining in words the prior steps will help her to crystallize some insight in her own head that will fill in the gaps.

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.

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

Honestly that problem is kind of self created. The amount of trivial NPM packages is mind blowing.

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.

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!

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.

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.

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.

Most software development is in house stuff, and most of that is very procedural. You don't need a CS degree to do it.

Half of the rest of software development is embedded stuff for PLC or basic software needed to get a piece of hardware working. It is done by EE types that barely have an understanding of the language, much less data structures and algorithms.

Your experience and level of expertise is the norm. And, it's perfectly fine if it gets the job done!

The beauty of technology is that you don't need very many technologists to create something that ordinary folks can use. The field is very far along now so there's many levels of skill, from the guy that can create an AR engine from whole cloth down to the businessman who can do very advanced stuff within excel ...

Here is an angle which seemingly no one mentioned: "I'm being tasked with guiding my fianceè with this course" What if the right way to help them is to do nothing, and let them work through it on their own? It's an exercise for a reason.

I've been a programming since I was a kid in the 80s and for money since the late 90's and I'd struggle with what a computer scientist would consider simple problems.

It's a mismatch of domains.

Computer science !== Software engineering (though obviously there is overlap).

In practice I find that at least 50% of my job is getting requirements out of people's heads into a structured form I can explain to the high speed idiot.

The rest is working methodically, testing and documentation.

I work in the enterprise domain though so obviously YMMV if you are in machine learning, graphics programming etc.

Programming is a vast field with a huge number of sub-fields, find one you are good at and excel in that and let someone else worry about writing the compiler.

That's akin to being a whiz at high school calculus and expecting to breeze through rigorous courses in real/complex/functional analyses. Possible if you're a prodigy.

You already got the practical programming down. Now if you take a course titled "intro to proofs" or "intro to discrete math", you'll be well prepared to kick any CS class' ass.

This isn't too surprising. There's a lot of CS stuff that is rarely used in practical programming so you can get pretty far without knowing it.

> but when it comes to me trying to solve these problems on my own, I don't know where to start.

How do you expect to know where to start when you haven't been taught anything yet? Your short resumé does not indicate that you have any background in Computer Science. That's not bad, it's just different.

It's certainly not required. I work with a guy whose degree isn't in CS, and he's a fine coder. He doesn't know the theory, but he's paid enough attention over the years that he knows what works, what the pro/cons of the various data structures are — he understands the code that well enough to understand why. (And practically, that's probably more beneficial.)

The CS backing can definitely help, though. We've had plenty of problems at my job that involve writing a parser for often very tiny languages. Having an understanding of CS theory here — the various language classes, what an FSM is and where it is useful, etc. — definitely helps. However, often the language at hand is simple enough that a handrolled parser that skillfully uses a few regular expressions to get the job done suffices just as well. Googling for a parser library and just using that suffices, too.

Or we have to build a somewhat custom file format, or parse a somewhat custom file format. I've interviewed a fair number of candidates that are not comfortable reading or writing bytes to a file. (And of course, this is not the only question we judge them on. But very few candidates in my experience only miss a single question.) They've worked on innumerable "RESTful" APIs, but seem to have no idea how HTTP works; they've done server side Linux/unix/etc. development all their life, but never worked on a command line.

I hold a CS degree, and what grinds my gears is when it is just dismissed outright. As an example, I've had a coworker who was trying to determine what order various interdependent tasks needed to be accomplished in; to anyone who has been through graph theory, this is simply a topological sort, and there's a rather trivial algorithm that you arrive at in the course of studying graph theory. But at the suggestion of "this problem is a topologicial sort; X is a decent library that implements it", I get told "Now, I don't want to go down some PhD CS thesis rabbit hole." Right.

> fianceè

"fiancé" for a man[1], fiancée for a woman[2]. (Pronounced the same.)

[1]: https://en.wiktionary.org/wiki/fiancé#English

[2]: https://en.wiktionary.org/wiki/fiancée#English

As another example I've found of where the theory is helpful: I have often seen two dimensional data put into a relational database, where the person wants to query over a range of values on both dimensions. (I.e., they want to find everything inside of a rectangle, were you to graph the points.) Broadly, I've found these fall into two categories:

1. Lat/lng positions (find all rows where lat between [lat1, lat2] and lng between [lng1, lng2]

2. start time/end time pairs (find all rows where the event is in or overlaps this range)

Then those two dimensions/attributes are put into what is often a B+ Tree or similar index. B+ Tree indexes can really only efficiently query on one range, and only if every preceding attribute in the tuple that the index is built from is specified exactly. The first example w/ lat lngs is particularly bad.

But a lot of developers working w/ databases have no idea what a B+ Tree, or even any tree really means. They get that it's a tree, and that it's ordered. But there's a gap between that and somehow being able to think it through and arrive at the fact that the database must either:

1. walk a lot of rows that aren't going to match (they typically do this)

2. or do a hell of a lot of range scans (they typically do not do this, and it's not really always possible)

Often I find that they think it is </>/= with each attribute individually, when it is really more like the tuple being indexed as a whole has a < operator implemented for it (by the database). Thankfully the analogy of find all people whose first names start with "Th" in a index ordered first by last name usually clears it up somewhat fast, but it took me a while to find that analogy.

(My CS degree included a course on relational databases. We covered everything from theory, such as relational algebra — operations on sets of tuples — to concrete implementations such as PostgreSQL and how to efficiently store indexes/data on disk. The professor I had was absolutely amazing, though I did not really realize this at the time.)

Learn a different language. I would recommend C, Forth or Lisp for stretching your brain.

Solve challenging problems; databases, interpreters, whatever floats your boat.

The only way out of the matrix is to keep pushing boundaries, repeating the same old with different frameworks is the blue pill.

I spent 10 years doing web development that eventually lead into a few years of systems and network programming before I went to college for a CS degree. Many CS problems were still challenging even with all of that experience.

It's an unfortunate fact of life: You don't know what you don't know ;-) Especially as a programmer, you have to have the attitude that there is no shame in not knowing, or not being able to do things. 30 years or so in this industry and there are lots of things I'm not good at. In fact, as I spend more time, I discover more and more things that I don't know at all.

I've used this analogy before. When you first start, imagine that you are standing on the ground. There are lots and lots of things you can see. There is a lot to learn. Eventually, you get pretty good at everything you can see. But as you get better, hopefully you start travelling upwards. It broadens your horizons and you can see more.

Often this is an unsettling feeling. You think, "I've worked so hard, and there is still more???" Some people give up, "I'm fine doing what I was doing. This other stuff isn't necessary!" However, this will lead to an early exit from this career. Being a programmer is about always learning and always expanding. Things change so fast and you have to keep up.

As you learn more, you keep travelling upwards, expanding your view even more. It's amazing because when you thought there was a lot when you started, as you move upwards, the amount of new stuff you can see starts to accelerate. It's easy to get overwhelmed. Don't worry, though. Just pick stuff you are interested in. Don't rush. You have plenty of time. However, don't stop either.

Eventually, you will get so high that the earth is just a round ball. For a long time nothing will seem to change. You'll probably think, "I've learned everything! I'm amazing!". And then you will run across the moon. "Woah... I know nothing". That's what it's like when you start to get more senior. You keep expanding your view, but things don't seem to change, until you see some new island of stuff that you never really imagined before. Again, it's easy to give up and to think, "I'm a senior developer and I'm world class in X. What do I need with the moon?" But that's a trap. It's the easiest way to ensure that you are seen as the strange old doofus in the corner using crappy, ancient techniques. Learning, learning, learning every day for the rest of your life. That's what being a programmer is.

I hope that helps!

Hah, you must be the one who wrote the system I’m now rewriting.. :) just kidding. I went through the same thing- I thought I was a pretty coder too till they hit me with the towers of Hanoi problem in college. When I saw how simple the solution was to that problem, the scales fell from my eyes!

Me too. I even invented slightly famous stuff.

It's like this:

There's reality.

Then there's a map of reality which is, for obvious reasons, pretty fucking far from reality.

Then there's the map of the map, which is delusionoid-squared.

In this case you are dealing with the level2 map. Most of us don't take it too seriously.

This is the best answer.

Let me paraphrase:

"The map is not the territory. It's not even close."

"The Imposter's Handbook" might be something worth checking out...


I think I may have felt this once or twice in my career.

I'm 15 years in now. I study type theory and use formal mathematics to model software systems. I don't have any degrees. In my day job I lead teams writing mostly Javascript to build web services and APIs for moving data around. I teach a small group Haskell once a week at lunch. I speak at conferences big and small. I still wonder at times if I know what I'm doing or whether I deserve to have opinions about anything or blah blah blah.

It doesn't help having voices around you all the time that call your skills, experience, and knowledge into question. You have provided value to someone if you're still a practicing software developer. You know how to work in a team, solve problems, and have developed a sense of taste for what problems are worth solving. You understand the tools you use and have an intuition for their strengths and weaknesses. Maybe you even have some experience getting other developers to work together on a large project. That's useful stuff. You are a useful person.

Does learning theory help? I think so. Once I stuck with type theory I started to see structure and abstractions in code I couldn't before. Learning how to formalize programs has allowed me to think about the correctness of complex systems in precise ways in order to discover "bugs" in my designs. These have also helped me find more ways to write simple, reliable code.

Most of professional software development is knowing what's out there and connecting them together. It's basically data plumbing. There's nothing wrong with that, running water and sewage are two of the pillars of civilization!

The problem is that lots of companies have high opinions of themselves and even if most of their work is plumbing and plumbing supplies, insist on having a hydrographer and a physicist on staff in case they really really need an R&D program that can produce a O(k) B-tree or some nonsense.

I think you are seriously underestimating how valuable you are.

CS 101 data structures is all fun and great but the majority of businesses out there exactly require the skill set that you have.

Sure there are positions that demand deep knowledge on how algorithms but those are few..

You needn't to look further than Google itself.. they have many engineers that can apparently solve BigO problems, yet they fail to deliver a simple email client that works..

You deliver business value to companies, help them grow, create jobs and make profit.

This is something you should be proud of

My spouse started a bootcamp last year and I've helped her with many algorithm assignments. Even though I have a CS bachelor degree I still struggled with a lot of the algorithms exercises out there. It requires practice and there are actually a lot of subtleties that you don't experience while working on software projects.

A lot has to to with mathematics as well. You can work on projects with hundreds of thousands of dollars and face zero mathematical problems.

I spend a lot of time, dozens and dozens of hours, helping her with these algorithms on paper, whiteboard and writing them in code. I also struggled along with her through online algorithm and coding interview platforms like Hackerrank. Solving these algorithm is difficult and often ridiculously theoretical and out of touch with the daily routine of a software/web developer.

My spouse was very worried about not being able to solve these problems. She was scared that she will have to solve these things during the internship, but of course there are no mathematical algorithms to solve when you are working as a frontend developer.

I think the trend of mathematics during development courses and theoretical algorithm exercises during interviews are not doing us any good. Most companies are not Google and you can be a very valuable developer for 99% of the companies out there without being a whiteboard algorithm expert.

I'm curious, is it the norm for people who do online courses or bootcamps to get help from their spouses? Is it not unfair for those students that are unpaired? I was in university (and thus not really in the pairing off mindset) last time I seriously studied a brand new field but I never got a romantic partner or even a friend to help me directly with my assignments, it would have felt like cheating in a way... but since online courses are targeted to adults maybe it's expected and they see it less academically?

Are academic students getting help from fellow students, a tutor, a teacher or their parents also cheaters?

Do you consider tennis players with a coach also cheaters? The player still has to play the match by themselves.

Are developers who ask for help from a colleague also cheaters in your eyes?

No, definitely not (at least on the latter two; my school did say take home assignments had to be done independently, if graded. People did get help on the ungraded assignments, though I didn't).

I wondered if bootcamps/online were more like in the adult world (where it's basically always OK to get help) or like traditional degrees (where everything graded has to be done on your own unless a team project). You are saying it is more the former, I suppose.

I just wanted to know if everyone did it. Like are most people in bootcamps friends or spouses or children of working programmers? or are there also people doing this "out of nowhere" like at community college?

The point of studying data structures and algorithms that you may not use on a day-to-day basis is that they make you learn to think abstractly about problem solving. That is the whole point of getting an undergraduate degree in CS. I'm sorry that you have trouble with this stuff OP, it would be a good idea to do the cs50 course with your wife until you're comfortable with this stuff. I'm sure it will pay dividends in your future.

I don't think it's really just you. Most academia seems to have a hyper-focus on algorithms and data structures. I don't know what kind of jobs they're expecting people to apply for - I'm not writing an implementation of the C++ STL, and I'd argue most of the time it's a mistake to write your own data structures with such a great ecosystem of existing implementations.

Don't get me wrong. It's great to know how binary search works, or to understand algorithmic complexity - those things come in handy. But you probably don't need to know how to find the largest palindrome in a string and you almost definitely shouldn't be writing your own hashmaps in real world code. Most people would benefit a lot more from domain specific knowledge. How do system calls work? What's a load balancer? etc, etc. Even being domain specific, a lot of the ideas can be applied outside of the context it was created in, and so knowing these things is incredibly useful.

Thankfully, most of the interviews I've had have focused a lot more on real-world situations and topics. Maybe academia will some day catch up and at least balance the focus out a bit.

I would just start toying around with these problems, there's lots of sites out there that aggregate them for you (personally I like https://reddit.com/r/dailyprogrammer). Solving these kinds of problems really are different from your usual day to day on the job coding activities. I'm by no means the best at solving these things, but the more I do it the easier they are going forward. They are useful mostly just for fun or for preparing for interviews where people might do this crap to you. There's actually a yearly code challenge called Advent of Code (https://adventofcode.com/) that is starting in December that you can try (though they can be kind of tough). You basically just have to keep doing them and do harder and harder ones and it gets easier, your bag of tricks starts to grow and you realize "Oh, this problem is pretty similar to the problem I did last month, I'll start out with the same approach"

Seems like you discovered a gap in your knowledge, congratulations, you're one of the lucky ten thousand [0]!

It might be a good idea to pick up a book about algorithms (others are posted here) or follow an online course yourself to learn about these things. They might give you some insight into problems which you might encounter during your job.

On the other hand, solving algorithmic problems is not equal to 'software engineering'. You have to think about more than solving a (theoretical) problem in isolation and you've build up skills on that area of the past few years. From source code management to soft skills, these are things a compsci degree won't necessarily teach you.

From personal experience though, I find that my background does help me (at times) with solving problems at work. But apart from the utility of learning compsci, consider that it might be fun to learn so and just give it a go.

It doesn't make you less of a web developer by not knowing it though, so don't be too hung up on it. It's just different, as others have pointed out.

[0]: https://www.xkcd.com/1053/

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

It is called imposter syndrome. It is very real and very common. As a JavaScript developer I encounter this among my peers all the damn time.

First, consider what it takes to be a professional software developer. The requirement is to pass a one time drug test and successfully answer questions in a 30-90 minute interview. Done.

Consider, conversely, all other white collar professions. They have licensing, certifications, educational requirements, and legal compliance. There is greater oversight and compliance to become a truck driver than a software developer.

The closest uniform indication of competence (if you can call it that) most software developers experience is demonstrating experience with a tool or framework. To me this says you more than new and probably better than negligently incompetent. It doesn't tell me that you are an excellent specimen of solving original problems.

Secondly, I suspect you go to work, achieve your assigned tasks, and then forget about programming until the next day. This is problematic because in most cases there isn't much expected of software developers in the corporate world. Most of us are glorified and over-paid button pushers. Achieving conformance to nearly thoughtless tasks that could be better performed by software is not an indication of professional growth. There are many times I have encountered QAs who seemed far more brilliant at problem solving than the developers they were checking.

This is one reason why more ambitious software developers contribute to open source. Their day jobs are boring with no growth potential, but their software hobby is extremely challenging and solves real problems.

> The requirement is to pass a one time drug test

Wait what? Where do you live that software developers are drug tested?

A drug test and criminal background check are standard at every place I have ever worked. The current employer is a super giant fortune 25 company

I've been writing a book series that's partially targeted for programmers like you: those who know how to code but don't know CS. It's called "Classic Computer Science Problems." You may want to check it out:


If you already know Python or Swift, it may be a decent next step for you after CS 50.

Applications are open for YC Summer 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact