Ask HN: I've been a programmer for 6 years, and I can't solve basic CS problems
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.
308 comments
[ 2.6 ms ] story [ 286 ms ] threadThis isn't reddit. Low effort comments are looked down upon.
Also due to the data structures provided in higher level languages you are often less aware of how long something will take to run which i find is a big part of many CS courses
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.
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!
[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?
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
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.
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
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?
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").
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).
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’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.
I'm hiring Ruby devs down in Costa Mesa, and I don't ask any algorithm questions :)
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 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...
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.
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.
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.
The crap I was asked was pretty insane to be honest.
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.
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.
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)
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 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 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.
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 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.
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 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.
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.
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.
So what are some examples of those problems? No one can really tell you if this is something unusual or not without having an idea of what the problems are. And CS courses and algorithms vary from pretty simple to actually really hard.
There is a considerable disconnect between programmers who have a CS degree and those who don’t.
I’ve run into programmers who’d never heard of the term “boolean algebra” before and knew about regular expressions but didn’t know what a state machine was.
For the most part it doesn’t matter, but it’s always a little surprising when you find someone who knows AWS very well and then you find a huge gap in their fundamental knowledge.
But yeah, those are gonna be tough to just come up with on the spot without actually studying them. On the other hand, OP could be talking about stuff like tree traversal and similar simple stuff that is also included in introductory CS courses.
Edit: OP chimed in elsewhere in the comments, it's not even about CS stuff.
A lot of "classic" problems are so embedded into CS professors that they don't even see them as problems anymore (lazy caterer, pick's theorem, etc) so if you didn't study these classics explicitly in school you have to discover them on your own.
(2) Doing similar things over and over may not transfer experience to other things.
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!
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.
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.
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.
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.
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.
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.
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
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.
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/
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.
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!
So... Maybe don't prematurely optimize?
If I get something wrong, my boss lets me know, I learn from my mistakes and ship out good quality software.
https://news.ycombinator.com/newsguidelines.html
Is this just me? I know it's self destructive to seek out negativity like that, but that curiosity just won't go away.
Read mine. There is more to what's going on than meets the eye. And if you email me (see profile), I'd be happy to illustrate just how carefully Dan controls his image.
After all, see your language here. There's nothing wrong with being curious. That's the whole point of HN.
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.
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.
Even completely ignoring ASCII, it is trivial to create a dictionary mapping integers to characters.
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.
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.
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.
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
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.
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.
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.
- 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.
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.
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)
Obviously I knew next to nothing about cryptography, and I did feel very smart about making a safer cypher.
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
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.
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.
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.
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.
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.
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/