|
|
|
|
|
by tst
4396 days 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 [1]: https://www.udacity.com/course/cs212 |
|
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