Indeed | Full stack engineer (RoR or Java) | Onsite or remote | Austin TX | Full time
We are looking for senior Java and Ruby engineers to join our team full-time.
Our Assessments team has a simple mission: help candidates get the right job. We let people build a profile to demonstrate their knowledge, skills, and abilities using job assessments… we’re trying to make the resume a thing of the past. Our team is highly distributed geographically so this position is open to remote candidates anywhere in the US or Canada as well as in our offices in Austin and San Francisco.Our team is nimble and scrappy. We ship new capabilities often and quickly by explicitly asking ourselves the 80/20 question a.k.a. the Pareto Principle.
You will:
Build the core functionality of our assessments platform and own design and execution
Develop our API and integrations with external applicant tracking systems like Greenhouse and Jobvite
It really depends on the book for me. Technical topics I already know pretty well, I find easy to commit new methods to memory when I come across them. Nontechnical, I can remember a good deal of fiction, but factual things fall off pretty quickly.
I think the most important thing is chunking[1]. You remember key things, such as storylines or plots from fiction, or, with technical writing, where to return if you find yourself needing a particular concept in practice.
I, too, really love Elm, and have worked on some tooling for getting it running on the server. (Self promotion ahead). I wrote an NPM module for compiling and loading Elm[1], and also put together a more comprehensive project for scaffolding an Express application to communicate between Elm in the browser and Elm on the server, via ports (this is the first time I announce it anywhere, since I want to have some full examples before anything "official", but it is usable today).
It performs perfectly fine on my machine, but I have not done any comprehensive testing. I was actually quite surprised when I first got everything working and was streaming input to the server, state to the client, and rendering the latter without any obvious latency. There are even some trivial optimizations, such as dropping repeats from the state signal on the server, which should speed things up significantly. I have no idea if it will scale, but I do plan on adding some infrastructure for writing bots in Elm and having them run in a cluster, so it should be easy enough to test at some point.
Aside from the things others have mentioned, which are all really good, there are some really good books on the subject.
Jose Valim's Crafting Rails Applications[1] is a wonderful resource, since it deliberately sets out to peel back the layers of magic. A lot of the techniques are ones I probably would not use in practice (storing views in the database and rendering them!), but they serve to elucidate the operation of the entire view stack. Really good stuff.
Two other good books are Rails Antipatterns[2] and Objects on Rails[3]. Neither of them has been updated in a long time, but the general principles will still hold. The former is more practical, the latter more theoretical; precscriptive and fanciful food for thought, respectively. Both solid.
It isn't always easy when something does seem to be common knoweldge, but you are correct that people try to be more understanding. I have adopted the attitude from this XKCD comic. https://xkcd.com/1053/
Ironically that comic and XKCD in general falls into the category of things that are very widely-known but people still present as new information. (The prime example being cryptography discussions linking to correct horse battery staple.)
I think this very much oversimplifies the costs. From a hardware standpoint this is probably mostly correct, but the problem is the sheer amount of research and talent behind it is not remotely inexpensive. I recall Carmack saying, about a year after he joined Oculus, that he thought getting the latency down would be straightforward (sorry - I can't find a source), but it turned out to be a much harder problem than he expected. And, when Carmack is stuck, I cannot but believe there are intricacies that I could not hope to understand at play. The fact that they have been unable to ship a consumer version after all this time, I think, corroborates that this is a much more difficult problem than just throwing some hardware together and calling it a day.
I highly recommend The AWK Programming Language by Aho, Kernighan and Weinberger[1][2]. It has a very similar style to The C Programming Language, also co-written by Kernighan. Even as a general book on programming, it is pretty good in that it presents the reader with useful exercises from simple text processing all the way up to more advanced database implementations. I would not recommend it as a first programming book, but it really covers how powerful the AWK language is in a way that is very accessible.
The beginning of your story reminded me of the wonderful commencement speech given by David Foster Wallace at Kenyon College in 2005 [1]. It is very easy to well up with rage, but it is significantly more difficult to understand the context of another's actions. Sometimes I have to stop and tell myself "This is water" and try to put myself in the shoes of the stranger who has enraged me. I do applaud your stopping to help, and I find it unfortunate the experience was not more rewarding.
Actually, it was very rewarding, which surprised me immensely. I'm not too surprised she didn't thank me - as k-mcgrady says, she was busy with the police by that time. But equally, we shouldn't be that surprised that people are preoccupied with their own problems and so don't stop to help us.
I did not find this list particularly useful. It is a nice attempt, but the way it categorizes libraries can be deceptive. I do not think anyone would consider bower and npm to be comparable projects, except in the most abstract sense. The same applies with node and express; one may as well conflate ruby with rails.
That said, a lot of the tools are really good. I would, personally, argue that underscore is the most important javascript library in existence. It transcends frontend and backend, server and client. It is data manipulation at its finest. It brings functional programming paradigms to javascript. It is beautiful.
After spewing this mantra, one of my colleagues wrote a blog post about it that presents a nice introduction[1]. I would also highly recommend Michael Fogus's book, Functional Javascript[2], that heavily relies on it.
They're not very different but I use lodash instead of underscore. Is this "six of one and half a dozen of the other", or is there good reason to stick with underscore?
When I went to that list I was specifically looking for underscore.js and date.js. Seeing a serious project that does not use these libraries makes me twitch.
Yeah, underscore was there but date wasn't. I guess my point was that there wasn't a date.js or some reasonable equivalent time library because date/time programming sucks.
Our Assessments team has a simple mission: help candidates get the right job. We let people build a profile to demonstrate their knowledge, skills, and abilities using job assessments… we’re trying to make the resume a thing of the past. Our team is highly distributed geographically so this position is open to remote candidates anywhere in the US or Canada as well as in our offices in Austin and San Francisco.Our team is nimble and scrappy. We ship new capabilities often and quickly by explicitly asking ourselves the 80/20 question a.k.a. the Pareto Principle.
You will:
Build the core functionality of our assessments platform and own design and execution
Develop our API and integrations with external applicant tracking systems like Greenhouse and Jobvite
Scale to serve 100M+ job seekers
Please apply here:
https://www.indeed.jobs/career/JobDetail/Sr-Remote-Java-Engi....
https://www.indeed.jobs/career/JobDetail/Remote-Software-Eng....
Indeed provides a variety of benefits that help us focus on our mission of helping people get jobs.
View our bounty of perks: http://indeedhi.re/IndeedBenefits
Please feel free to e-mail me directly at smichaud@indeed.com.