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.
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.
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).
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/
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.
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.
I want to mention mincer[1], which I have used in the past for compiling assets, and it has been an entirely painless process. Definitely take a look at it as an alternative, which has been around longer and has seen assistance from the folks behind sprockets[2] (according to the README) for creating a similar API.
While I agree with making code editable in single lines as much as possible, I think this is a particularly bad example. I do prefer the comma first style for arrays and objects, but not for variable declarations. I used to use this exact style a couple years ago, but now I prefer to explicitly declare every variable with `var` to prevent any possible, syntactically correct, error that would result in a global variable.
It is not about the running of the command - I read the installation script, and it looks fine.
It is about my desire to work on a node application in what I consider to be a standard way. I want to be able to treat my entire application as a node package, leveraging npm for dependency resolution.
Think of it like a rails application. For local development, you probably use rbenv (or rvm), bundler, and have the version of rails you need listed in your Gemfile. You allow the package manager provided with the language and maybe a layer to keep environments separated (already provided by npm) to take care of dependency resolution and updates.
I want a node framework where I can use the package.json file as one does the Gemfile for ruby applications.
It sounds like the installation script, aside from handling the MongoDB and node setup, could be treated like a typical node package. Based on the fact that meteor has no package.json, seemingly none of those core packages are installed via npm either.
I may be alone in this, but I guess I would just prefer if my web framework expected me to have the interpreter and database installed, and used the package manager already provided for this environment.
After seeing the first, extremely slick demo of meteor, I was, as I believe a lot of people were, extremely excited to see where the project would go. Then came the funding, and some twelve or sixteen months of development, and I finally decided to dive in.
I really wanted to like it. I was predisposed to do so.
But from the very beginning, I was confronted with something I consider a deal breaker. While I am wary and generally disinclined toward the increasingly popular pattern of curl an installation script and pipe into sh, in this case it is not only skeptical, it is downright ludicrous. Why would I, nay anyone, want to install an npm package this way? Should not the installation instructions simply be `npm install -g meteor`? And what if I need to work on multiple meteor projects with different versions? Surely there is support for adding it to your package.json file, but why is this not the primary means of installation and well documented?
Maybe I am being overly sensitive to these issues, but it really baffled me that the very foundation upon which a meteor project is predicated would be contradictory to the typical node workflow. I will probably try meteor to spike out a project at some point in time, but I do not foresee myself using it extensively in the near future.
I am working on average size web applications, which simplifies things greatly, but I do not think your characterization of kernel development is correct.
The official kernel mirror on github[1] does not have any of these extraneous branches, and, unsurprisingly, makes good use of the tagging ability built into git.
In fact, the kernel developers prefer[2,3] that feature branches are always based on a known working state if possible, rather than some arbitrarily moving branch, be it called master or develop. That said, the master branch of the linux kernel is, by no means, relegated to only having merge commits from feature branches that correspond to releases.
Over time, I have come to feel this git workflow is more of an attempt to coerce git into a workflow that is familiar to users coming from subversion, rather than learning and understanding git's strengths. A corollary problems is that it mixes development workflow with release management - two disparate concerns that should be handled separately.
After a couple years of using this model, I have done away with using a develop or release branches whatsoever. Develop everything in feature branches, based on either the most recent production tag or the master branch, depending on if it is a hotfix or if it is new development work. A lot of people do not seem to understand you can just checkout a tag, so you do not need to keep a number of hotfix branches around for in-house repositories.
Now, it would be nice to develop a better tagging strategy for rolling updates to a web application, but, for the time being, simply using a stage and production tag work well enough. This is certainly suboptimal and can cause problems, and I cannot recommend doing so. Instead, use production and stage tags with either sane version numbers or simple timestamps. It would be best to only promote from staging to production, but that is not exactly necessary. Most of my thoughts on the release management side of things comes from Alex at The Daily WTF [1].
I am only about a quarter of the way through the book, but thus far I would have to say the chapters on BerkeleyDB and Eclipse were the most interesting, both containing a lot of history and insight into how the projects changed over time. The chapters on Audacity, Bash, and CMake were all pretty good, but I did not find them as enlightening.
I guess that means, thus far, the book is about a third of each: very interesting, modestly interesting, and mediocre. Not too bad considering each chapter is written by different individuals.
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 [email protected].