5 ms·
Have you come across Scott Young's feat? http://www.scotthyoung.com/blog/mit-challenge/ http://www.scotthyoung.com/blog/mit-challenge/ I believe in the real wo
by dwoot 12y ago
Have you come across Scott Young's feat? http://www.scotthyoung.com/blog/mit-challenge/ http://www.scotthyoung.com/blog/mit-challenge/
I believe in the real world, you are best represented by a body of work and/or the ability to demonstrate that you are capable of tackling the problems associated with the job in which you are considering.
The world of information technologies is vast. There are computer scientists, software engineers, data scientists, test engineers, and many more.
It'd be best if you could narrow down what it is that you're interested in working on. I think a degree in computer science gives you a phenomenal foundation for any of the above, but it doesn't make you immediately in demand, particularly if you're missing a body of work.
I am a software engineer without a CS degree, but I've studied algorithms, some design patterns, and some math relevant to my areas of expertise.
That's my two cents, but I'm sure other people have some useful ideas as well. :)
- atmosx 12y agoNope, thanks for the link. I will check it out.
- tst 12y ago> I believe in the real world, you are best represented by a body of work and/or the ability to demonstrate that you are capable of tackling the problems associated with the job in which you are considering. This is such a good advice! I remember reading Norvig's spellchecker[0] and said to myself: "This code is so elegant and beautiful. I could never write something like this." I learned more about NLP, learned some Scheme, worked through Norvig's Design of Computer Programs[1] and improved my Python a lot. What have I learned? Firstly, people like Norvig have tons of experience and are incredible clever. Also they have worked in the same (or similar) domain for decades. Of course they know cool data structures and algorithms for NLP problems. Back then I didn't realize this and thought that I was dumb. Today, I'm less dumb and know that it takes time and experience. Build, learn, build, learn, ... [0]: http://norvig.com/spell-correct.html http://norvig.com/spell-correct.html [1]: https://www.udacity.com/course/cs212 https://www.udacity.com/course/cs212
- waps 12y agoExperience is more about knowing a million little tricks than it is about actual domain knowledge. Norvig's spelling corrector is an application of inverting the problem. Instead of attempting to correct a misspelling, he attempts to misspell a word, then stores the misspelled word along with the original word. Then, to correct a misspelling, you simply look it up in the hash table. Incredibly powerful mathematical concept that inversion thing. And there's a million of them. Other "tricks": * shuffling a deck of cards in O(1) (or shuffling anything at all) * sorting in O(N) (with a limited keyset, and guaranteed no repetitions it's easy. Think about it). * knowing the url to MIT's bit twiddling manual [1] * know how to "rewrite" english (or any language) text. Really impressive. Also, mostly useless. It's called Markov Chains. * understand how and why "every language compiles first to LISP, then to machine code" is true. Thinking about this yields no end of clever programming tricks * make sure to have spent a few months in each style of programming. Imperative (doesn't tend to be a problem). Functional (NEVER change the value of a variable, ever, for any reason). Dynamic (write a calculator using eval, and go from there. Exploit it). * having the experience that any style of configuration eventually ends up being a turing complete programming language, and so you should just import and use an existing language * having experienced the power of query languages. Instead of having a few reports, implement an interpreter that allows you to query them. Then amaze everyone by having every new report they ask for done in 10 minutes. * knowing the power of automated source translation tools, and how easy these things are to write IF you can munster the discipline of never touching generated code All of these things will have people tell you it's impossible. And when they see simple code that demonstrates things like this, it's cheating (e.g. O(N) sorting is not fully general. That doesn't make it slower than O(N), and it's still applicable to a lot of situations) ... [1] http://graphics.stanford.edu/~seander/bithacks.html http://graphics.stanford.edu/~seander/bithacks.html