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!

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.

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.

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.

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

Looks interesting!

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.

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

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.

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

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

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.

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.

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.

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

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

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.

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.

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

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.

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

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.

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

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?

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.

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

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.

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

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?

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

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

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

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:

https://www.quora.com/Whats-the-logic-behind-Google-rejectin...

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

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.

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

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

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

I've now run three tech companies and hired dozens of developers by having really intense, thoughtful conversations with them. I asked them to tell me war stories and encouraged them to share insights on how they solve problems.

I only rarely look at code, because it's self-evident when you're talking to someone that is passionate about programming + intellectually curious-to-hungry + an interesting person who demonstrates empathy and seems like someone you'd want to spend 7-9 hours a day with.

I hire like I'm trying to form a rock band: I don't tell them what to play, I give them permission to show me what they've got.

Here's the thing: the more we, as a class of developers, put up with these devolving interview processes, convince ourselves that this is somehow our failing and our inability to FizzBuzz in six languages with a sharpie and people watching... the more we allow it to be considered okay, and the more normal it will be to expect this nonsense.

I know that being cash-starved sucks, but you know what? If you walk into an interview and they bust out the markers and ask you to start sorting, I sincerely hope that we can collectively find the strength to laugh at them and politely tell them that you'd never waste your time at a company that insults your craft.

Find your pride and tell them why they missed out. If they want to understand what just happened, tell them to take you for a drink. If they are dicks about it, you really didn't miss out on a damn thing. I promise you that.

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

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.

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

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.

I liked this approach of hiring.

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.

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

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

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

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

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

Again, thank you.

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

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.

Thank you for your reply. I do intend to work further on my skills in order to get better!

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

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

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)

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.

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.

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.

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

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

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

JSR $FDED

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.

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.

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

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.

http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

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!

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

I've since learned to also follow along using the walkthroughs provided, since they provide answers to the most basic of questions that I would have asked.

I would suggest you have a golden opportunity here, tbh. You have identified an area of useful skills which you currently are lacking - and a source of info where to learn. That's good. More importantly than that, your fianceè is currently doing the course and is right at the start! If you sign up to CS50 now (it's free!), you have maybe 4-6 hours of lectures to catch up before you are at Ceasar yourself, and then you can work through this excellent course together!

You will learn lots, some of which may be very useful. As will your fianceè. And you'll both have a much easier and fun time having a partner to discuss the lectures and problem sets, helping each other out here and there, before having to reach out for assistance.

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

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.

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.

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.

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

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.

https://www.nand2tetris.org/

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)

https://www.coursera.org/learn/build-a-computer

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 best definition of complexity theory I can think of is that it's quantitative theology: the mathematical study of hypothetical superintelligent beings such as gods. Its concerns include:

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

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

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

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

And of course:

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

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

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.

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)

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.

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

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?

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.

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.

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.

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

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.

    hist = [0]*100
    for x in xs:
        hist[x-1] += 1

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.

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.

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 made the exact same comparison in my comment.

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.

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.

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.

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.

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

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.

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!

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.

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.

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

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.

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.

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.

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

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

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

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.

Let me paraphrase:

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

https://bigmachine.io/products/the-imposters-handbook/

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.

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.

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

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.

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?

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?

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.

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