This is a list of trivia to get you through a coding interview conducted by a clueless HR department that equates engineering skill with remembering answers to test questions. Nothing more.
None of the stuff in the list will actually teach you how to apply these techniques nor when to apply them (and when to stay away!) - which is much more important to know than to remember how to balance a red black tree or to sort a list.
The algorithms you can always look up - and frankly, how often does an average engineer implement something like that today instead of using a library? However, knowing when to use which technique or algorithm is absolutely essential.
What am I missing completely is foundations of mathematics. There is some on combinatorics (good) and some geometry in the optional parts, but where is numerical mathematics? Linear algebra? Basics of statistics and calculus?
With the "big data"/AI crazes going on you will be dead in the water if you don't know at least the basics. Not to design the algorithms (that will be still way over your head) but to at least have a shot at understanding what you have to implement! Nobody is going to explain you how to multiply matrices or calculate a covariance there.
Stuff like geometry and linear algebra is absolutely essential also for people programming computer games, anything related to virtual/augmented reality or robotics.
Statistics is needed anywhere dealing with data but especially in AI, machine learning and computer vision.
And basics of calculus are pretty much everywhere.
So while the list is pretty useful as a reference, the title is seriously misleading.
I can't see any of the "basics" stuff like calculus, algebra...
BUT, it is truth that most of the enterprises are fine having a programmer rather than a Computer Scientist... Probably most of them can't even tell the difference.
Here are the curricula recommendations that the ACM has for a software engineer, extracted and reformatted from https://www.acm.org/binaries/content/assets/education/curric... . The min/max expresses a weighting scheme for each of the knowledge areas
min max Knowledge Area
5 5 Programming Fundamentals
1 3 Integrative Programming
3 4 Algorithms and Complexity
2 4 Computer Architecture and Organization
3 4 Operating Systems Principles & Design
2 4 Operating Systems Configuration & Use
2 4 Net Centric Principles and Design
2 3 Net Centric Use and configuration
0 3 Platform technologies
2 4 Theory of Programming Languages
3 5 Human-Computer Interaction
1 3 Graphics and Visualization
2 5 Information Management (DB) Theory
1 4 Information Management (DB) Practice
2 5 Legal / Professional / Ethics / Society
2 4 Information Systems Development
1 3 Analysis of Business Requirements
0 3 E-business
3 5 Analysis of Technical Requirements
2 5 Engineering Foundations for SW
2 3 Engineering Economics for SW
4 5 Software Modeling and Analysis
5 5 Software Design
4 5 Software Verification and Validation
2 4 Software Evolution (maintenance)
2 5 Software Process
2 4 Software Quality
2 3 Comp Systems Engineering
0 3 Digital logic
0 4 Embedded Systems
2 4 Distributed Systems
1 3 Security: issues and principles
1 3 Security: implementation and mgt
1 2 Systems administration
1 4 Systems integration
0 1 Digital media development
0 1 Technical support
min max Knowledge Area
2 4 Risk Management (Project, safety risk)
4 5 Project Management
0 2 Digital Signal Processing
0 1 VLSI design
3 5 Mathematical foundations
3 4 Interpersonal communication
(I have omitted areas with min=max=0 for software engineering. The original table also includes weights for related fields. Eg, "Functional Business Areas" is an important topic for those going into Information Systems, but not for software engineering, "Scientific computing (Numerical mthds)" is weighted 0/5 for CS, but 0/0 for software engineering, and "Electronics" is weighted 5/5 for a computer engineer but 0/0 for software engineering.)
- Calculus 1-3
- Linear algebra 1-2 (though condensed into one course)
- Differential Equations (including partial differential equations).
I preferred reading the textbooks over going to class, so I can speak mostly from experience.
- Stewart Calculus
- Linear Algebra - Gilbert Strang
- Paul's online math notes for Differential Equations (PDF is formatted better than the website)
- Discrete Mathematics - Epp
These works are meant to be read in their entirety. Now by reading these, I mean read them, work through the examples youself, and do most of the practice questions at the end of the chapter. I'd also recommend supplementing with Khan academy, which is often better than many university lectures.
It's no small amount of reading, is genuinely difficult, and without difficult exams at the end of semester you may not retain the info. Also, consider the list a foundation for Mathematics in engineering less than something that will improve your work immediately.
That said, totally doable if you move slowly, take the time to understand the material, and be okay with working through using formulas that don't make sense at first.
Example life skills:
-Balancing a checkbook or verifying an account balance (addition including negatives, ex. e-commerce)
-Tipping (be familiar enough with percentages to eatimate a few simple ones in your head)
-Baking (fractions, multiplication/division)
The only thing not covered is basic algebra, solve for X type stuff. If you can convert Celsius and Fahrenheit either way given one equation, you're golden.
Most of don't need set theory or calculus. We need rudimentary math that should be in any 101 course.
If you're going into some sort of engineering such as fluid dynamics or maybe deep financial territory like banking, then maybe you need some calculus. Otherwise, just be good at the 101 level.
You don't need real computer science theory until you're already a seasoned programmer, at which point you need a refresher anyway. Beginning programmers spend more time setting up environments and breaking down poorly written requirements, than traversing binary search trees by hand.
I wish someone would have explained to me what it's like finding work in CS before I took the degree, how "entry level" positions can often mean 4+ years experience, how Interview questions often have little to do with the job and everything to do with memorization.
Going to school to become a good programmer is wasting money. Going to school because you want to work a field that rewards having a degree, and starting relationships where someone is waiting for you to get your degree and hire you when you finish, is smart.
First year students: go talk to your lecturers, starting from your first semester!
I am asking to see if your comment is geared at the specific program, or if you just don't give any value to getting an equivalent degree via an online platform?
Just kidding, but it's clear what the intent is here.
Even if you plan to devote your entire career to honing technical skills, the work around marketing one's self is also worth developing at least a little bit. It'll make it easier to position yourself in a community and to help others understand your ideas.
The extent of socializing that should be “learned” is recognizing things that may be confusing or upsetting. Nothing more. But by god and by no means should it ever be learning to act cool and by god not learning to lie about yourself. Those are extremely antisocial behaviors.
You generally get those skills from working at BigCo Inc.
While you can read books about them and apply them more successfully than someone who didn't read, you still need raw experience to move on from a beginner.
There should be plenty of positions at BigCo Inc. that are only looking for technical skills. Everyone has to start somewhere.
It's opinionated in its approach, in that it stems from students and instructors believing conceptual economic education as it exists today is fundamentally broken and fails to address inequality effectively.
Have you heard of Keynes, Smith, Marx, Locke, Rousseau, Hobbes, Emerson, Tolstoy, or Conrad? Great! Each of them has no less than three legendary books that you can spend weeks to months to years studying. Computer science is a bit different in that the landscape is fresh and the resources constantly shifting and growing, but the old fields, as always, can be studied safely on ink and paper.
You start with one author, you go through his or her influences, contemporaries, pupils, and you are guaranteed to have a healthy amount of daily reading material.
I think the article's stated goal is background for getting hired as SW engineer at a large company. If this is your goal, I would spend half of allocated time on getting the basics (and you do need to be able to understand algorithms quickly) and the other half on networking -- going to a few meetups or an open conference will likely generate as much value for getting hired as learning yet another method of balancing a particular tree.
Once hired, though, it is critical to expand beyond just writing code. Dropping by sales / user groups / wherever and using end-to-end system, just as one of the end users, is likely to yield larger benefits, career-wise, than writing an extra few functions. Learning a few basics about company's financials and how your product fits can be an eye-opener and help you steer once you are inside. Just my 2c.
It's too bad that most interview processes don't differentiate between these, and this guide perpetuates that problem.
One path develops "software engineering", the other one develops software engineering. P vs NP is nice. But like have you ever seen a person, whose mind is wrapped about the tools s/he uses just destroying it? Like a debugger or something? Just ripping shit to shreds?
But you seem very focused only in one kind of workplace... which looks quite like deep into the programming/algorithm part of CS...
If you would like to compare to software engineers as we know then in Europe you would need to have also some knowledge of physics (a general overview), mathematics (including statistics, discrete mathematics, algebra, ...) basics of economy (it is very common to have at least a subject or two) and then a fast overview of some domain specific technical areas such as databases (formal SQL92), artificial intelligence (an overview on the common algorithms and story of AI), operating systems (I remember to have read the code from a small Unix, also made a kernel module), the architecture of a computer (von Neumann) and understand the basics of Hardware programming (including some assembly and an overview how the CPU registers work, and so on...) and compilers.
Also do not forget things like classic software engineering, specification modelling and definition of problems in formal languages. And then comes the actual specialisation (web programming, deeper in databases, graphics programming, ...).
I have the feeling I forgot half subject of every area I mentioned... but as you see an software engineer knows a bit of every area, not to deep in the ones he/she did not specialise, and a bit of the surrounding careers; and very often after complete the basic degree is common to specialise deeper in some of those areas or go deeper in them as part of your professional life.
P.S. and for sure the final project of the career... which not many students take it serious but it could be compared to some side projects/per projects which you see from time to time in HN.
> 1 + 1 = 2
> - The minimum level of math skill needed for an interesting program
If mathematics is necessary for what you want, then by all means, continue to study it! However, the link between mathematics and programming, or even computer science and programming, can be more tenuous than it would seem.
I would even say that computer science is more connected to mathematics than it is to programming. Very little of everyday programming necessitates an understanding of computer science. Whereas pretty much any computer science research requires a deep knowledge of mathmatics.
In practice, you'll be so busy seeing the forest for the trees, tackling the business case at hand, you'll rarely be fussing over textbook definitions.
Often, when I see someone focusing too much on book smarts and interviewing in itself it's a sign they may need to put their reading and memorization into practice more. This is why I'm skeptical of job interviews - these things cater toward those who memorize them (likely fresh out of college), not devs on the field of battle shipping stuff for a few years.
Memorizing arbitrary stuff out of a text book when you have libraries already there and deadlines? Come on. In the rare event you need to write your own thing, you'll ask the manager for time to clear up airspace and study not from the textbook, but other's successful implementations, at a time when it actually matters.
Here's how I'd improve it: find implementations of linked lists, queues, stacks, graphs, and whatever in programming languages, their standard libraries, and community frameworks. Show people the utility, have them conceptualize it internally, rather than memorize it.
Here are some off the top of my head:
Something broad and standardized, templated containers of data structures, like C++'s stdlib and its vector, map, and so on. Last time I checked chromium's source tree, std:: was everywhere: https://cs.chromium.org/search/?q=std::+package:chromium&sq=...
Something low-level and cool, like Python's timsort: https://svn.python.org/projects/python/trunk/Objects/listsor.... (Java actually ended up borrowing that: https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/...)
Something high-level, for instance, django-treebeard's approaches toward handling hierarchies in Django. In this package, adjacency lists (https://en.wikipedia.org/wiki/Adjacency_list) are carried over not just to relational databases, but an ORM system. (https://django-treebeard.readthedocs.io)
I would venture to say that you will likely never implement a 1-dimensional data structure. Those will exist in the standard library, or even in the syntax of the language itself.
What would be helpful practice is to implement more complicated data structures like trees, graphs, associative arrays, etc. for several different languages, and find out which methods are the clearest, the fastest, and the easiest to implement in each given language.
The other thing to focus on is everything used to go from source code in a file to a binary running on a user's system. There are interesting problems that practically no one teaches to "beginners", like foreign function interfaces, package management, signatures, etc. that are just as important to understand as tree traversal algorithms.