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.
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.
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.
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!
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.
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.
- 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.
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.
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.
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.
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)
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.)"
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)
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. 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."
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?
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.
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.
Wait what? Where do you live that software developers are drug tested?
If you already know Python or Swift, it may be a decent next step for you after CS 50.
(2) Doing similar things over and over may not transfer experience to other things.
CS isn't as critical until you have to worry about efficiency, scale, or creating radically novel solutions. At which people you naturally will pick up more CS as you try to solve these problems.
Building something and building something that can scale are almost 2 completely different tasks. Asking questions like how much disk space will this take? How long will it take to perform a lookup? How do these factors change as the data grow?
Another area where CS becomes more important is when you want to come up with new abstractions.
To do what others have already done you don't need much CS knowledge because others have created libraries for you and have already established the design patterns. But CS becomes more important when you want to invent new paradigms and algorithms.
I like to compare it to some kind of manual work.
Programming is the tool. There's a hammer, or a screwdriver, or a saw. A good manual worker is able to use most of them. She may not have experience with all of them, but with enough experience she will learn to use new tools faster. The manual worker usually doesn't know much about creating those tools.
CS is like creating tools. You know what properties the tools should have, what materials they should use, etc. Most engineers are probably not as good in actually using them as the above mentioned worker.
So, being a good programmer does not mean being good at CS, and vice versa. What I'm saying is that it's totally fine. You'll learn (using the comparison again) what's the best material for a given tool for your current project as soon as you need it.
It used to really bother me, and I still am motivated and invest time and energy into building fundamentals, but I also realize that for some reason, despite this, I'm effective at my job and people respect my work. Meanwhile, people who took all the most advanced PhD and CS courses often are unable to get things done.
As I've grown a little older I try to spend less time worrying about these things, and realize more so every day how large the disconnect is between solving abstract puzzles, and working on a team to get things done.
Although I think the people that have both in spades are something else, and I have a deep admiration for them.
Break down the problem into smaller ones you think you can solve and start from there, the more practice at this the better you get at solving future problems. Maybe you even turn out to be really good at this and take up amateur theoretical CS in your spare time.
You should not solve those problems for her anyway. Help her with tools and such where necessary, but let her figure it out as much as possible. Don't do homework for her, it beats the purpose.
If the course is any good, the answers to questions are going to be easier when you attend lectures etc. If you cant see them, maybe let her explain you what was said there. Explaining someone helps to understand, so it alone would help her a lot to learn and understand.
Anyways, I’d say don’t get discouraged, learn new technologies, get out of your VB and .net and Microsoft cocoon and try new things. Maybe take a cs algo and distributed computing course and read up a book or two.
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
Taking one of the popular algorithm and data structures book and working through it, and actually doing the exercises, will improve your skills; specially, the ability to identify the shape of a particular problem.
Pure CS is very beautiful IMO, and rewarding to dive into.
Would I be a better developer if I’d learned that stuff?
Arguably, no. I’d probably be cock-sure and a bit of a dick. I know there’s a lot I don’t know and hopefully that keeps me humble. I’m always learning and I love it!
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.
I am pretty sure in 30 years all you current experts in CS will l be scratching your heads with the same.
It's useful to understand the basics so you develop an intuition, but don't stress if you can't actually solve the problems. You almost certainly won't need to use them in your career anyway unless you work in some incredibly niche areas.
As the article emphasizes: The labels themselves aren’t as important as the degree of awareness and understanding that each new “level” brings.
Most CS questions are a bunch of concepts that you rarely use in practice. Most development work is implementing your ideas in a way that works with other peoples code and the framework thats used.
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.
Act on it.
But if you don't, at least dont wonder why you are doing what you are doing and perhaps not something else. Or why you might not get into some other companies or or or.
Can your fiancee do your job? Or is your knowledge just divergent?
You're comparing two very different fields.
That said, you should consider learning basic CS. It will help you do a better job, and also make your job more enjoyable. And it's fun!
I will repeat that TDD will not give you the most elegant answer, but you will at least have an basic implementation. TDD just gives you one of protocols that you can use to solve problems.
(just another comment pointing out development vs. computer sciences)
My point is - computer science teaches you to understand the core of what computing is about, but don't for a second think that much of it relates to real world experience.
CS problems is like how to design a proper car and how a car really works.
I could give an example. Once upon a time a stumbled upon this classic article (which I re-read sometimes to feel better):
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
When I read this for the first time I have been literally shocked by sudden realization that I have coded some stuff in PHP but never knew it is such a crap.
It also taught me that I literally know nothing, that I am merely a stupid coder, not a programmer, so I undertook a serious study of CS fundamentals to be able to write an article like this in the future.
Now, after a few years of studying, I know a half-a-dozen of languages and I know crap when I see it. Ironically, what is going on with the Node ecosystem puts PHP3 into a shame. But it is natural, because most of JS coders have no CS background. People with CS background sometimes produce gems like Go or Erlang, while "mere coders" always produce things like PHP, J2EE and npm.
There is only one thing that I regret - it could save me so much time by not reading bullshit on the web if only I could find the right books (like Programming Erlang, Haskell School of Expression or On Lisp) and right courses (like Dan Grossman's and 6.001 2004 - the last course in Scheme) first. There is a huge, qualitative difference between a well-written gems like these and fucking crap some narcissistic idiots post in their blogs.
I have found the right books and the right courses by literally swimming thorough the sewers for years. A decent school will teach you the right principles, instead of irrelevant details, in ML or Scheme right from the beginning.