Front-End Systems Engineer | Indeed.com | Austin, TX or Seattle, WA (ONSITE)
Join a small, talented team that’s focused on radically changing how we approach front-end application development at Indeed. As an early team member, you’ll have significant input and influence on projects like a shared component library for UI development; tooling to make it easy for engineers to spin up and build new client-side applications; common systems for measuring and monitoring application performance; and more. You’ll evangelize front-end best practices to teams around the world, help them incorporate those practices into their development workflow, and take your learnings back to the front-end systems team to develop new tools. You’ll also help identify and mentor individual developers throughout the organization who will be the ultimate source of the front-end systems team’s success. Your work will increase the velocity of every developer who touches client-side code; it will impact hundreds of millions of job seekers around the world; it will — quite literally — change the face of Indeed.
---
The interview process will include a screening exercise and, for successful candidates, a day of on-site interviews. The process will focus specifically on identifying candidates with the required technical and communication skills necessary for the role; expect to talk about vanilla JS, maintainable CSS, client-side performance, testing client-side applications, designing and developing front-end systems to be used across projects, and communicating effectively with technical and non-technical audiences.
I won't address the rest of your comments, but please note that I said "tools like UglifyJS or Closure Compiler" -- if the RoR asset pipeline is taking care of this for you, then good! The point is that good front-end devs should be aware of the need for tools that address the various high-level topics I listed -- I just mentioned some tools that fill those needs for me.
My fear with doing that is that if the functions file is separated from the tests file, then it becomes difficult to see at a glance what the function needs to do in order to make the test pass. That said, I agree that what you're supposed to do could be more clear -- would you care to open an issue so we can discuss it on the repo?
Thanks for the great feedback -- it occurred to me that people could simply hard-code the "right" answers into their function. However, if I am using this to assess a candidate, I plan to actually read the code that they write :) And if a person is using this to assess their own skills, I trust that they know that an answer like the one above hasn't taught them anything.
Your guess about why I chose something that involves a little bit of setup is right on target, too. Being able to follow the instructions in a readme and get a simple project like this set up is a key skill to have, too.
The exact set of skills that one needs in order to do one's job will of course vary from person to person. What I have tried to point out in this post is that these topics are ones that anyone who calls themselves a front-end developer will need to be familiar with; if they are not familiar with them, then they risk being unable to keep up with the new information that is being shared about the front-end dev profession. This is based on my observations as much as my beliefs -- the set of things that you're expected to know in order to actively participate in the open-source front-end dev community is growing and changing, and this is my attempt to catalog those things in a way that I wish someone had done for me in the past.
I hope I gave due credit to the possibility that part of what's changed is me when I said in the next sentence: "Maybe it’s the result of people starting to take front-end dev seriously, maybe it’s browser vendors mostly getting their shit together, or maybe it’s front-end devs – again, myself included – coming to see some well-established light about the process of software development."
I do think the profession of "front-end development" has grown up a whole lot in the last couple of years. There have been front-end pros since long before I was even in the business, but I think the profession as a whole is being taken more seriously, and a set of baseline expectations for people in the profession is solidifying.
You are right, all of this can be done via makefile ... assuming you know how to set up a makefile and take the time to do so. Part of the goal of grunt, as I understand it, is to make it so developers have fewer excuses for not doing this -- setting up a project of a certain type becomes a one-liner. To me, that feels a whole lot simpler than suggesting that developers create the makefile you propose. More often than not, such suggestions result in projects that have no makefile at all -- and thus no tests, no minification, no linting, etc. If grunt helps developers integrate those best practices more easily, that feels like a good thing to me.
Much love for Alex Russell and for efforts to move the web forward as a serious development platform, but this was among the more content-free stories I've read in a long time. If you'd like to actually learn about "model-driven views," the component system the article mentions, head over to http://code.google.com/p/mdv/.
Yes, the point of the post was that it had a lot more to do with being a kid with a computer than with being male or female. The point of the title was that it was a story of ... a girl and her computers :)
It would have been great to see these improvements contributed back to PhoneGap/Cordova, which has an extremely permissive license and whose code is open-source. As it is, trigger.io comes with a restrictive license, I have to create an account to use it, I can't see the code, and they mandate that I include their branding with any free use of their product. Yay.
I saw a presentation on Enyo at CapitolJS, where I also announced that Toura would be open-sourcing Mulberry, and indeed, there are a lot of similarities. I too would like to get some clarity about what HP intends to do with it :)
Basically, Toura Mulberry uses PhoneGap as a wrapper around a "single-page" application that's powered by the Mulberry JavaScript/HTML/CSS framework. The command-line tools in Mulberry help you quickly scaffold the structure, content, and customizations for your app. The "builder" portion of Mulberry takes your content, prepares it to be consumed by the JS/HTML/CSS framework, and places it inside a PhoneGap project template so that it can be "built" for testing and submission to app stores.
There is a screencast demo at http://toura.github.com/mulberry/ -- the code has not yet been released (soon!) so there unfortunately isn't yet any demo code to share, but a demo will be part of the release when that happens.
In a nutshell, Mulberry is more opinionated than Sencha -- by being opinionated, it makes it much easier to get an app up and running without worrying about the underlying architecture of the app.
Mulberry expects that you're creating a content-centric mobile app, and so it expects you to define your application in terms of nodes that have assets associated with them -- assets like images, videos, audios, feeds, and data. Nodes are the building blocks of a single-page application that Mulberry creates inside a PhoneGap wrapper. Nodes are displayed with templates, and templates consist of components. You can use the components that come built-in with Mulberry and write very little code; however, you can also create your own components to add custom functionality to your app -- this is where Mulberry's true power lies (see the blog post for details).
Speaking more generally, Mulberry is aimed at developers who aren't interested in spending time on the low-level architecture of their application -- things like data stores, views, etc. Instead, Mulberry is aimed at developers who want to create their content, create their assets, create their data, and then write simple JavaScript and CSS that presents that content and data in the ways they need.
There is a total of 387k of JS (minified and excluding phonegap.js), but it's important to remember that all of the JS is shipped as part of the native app, so it all lives on device -- none of the JS is shipped over the wire except when the app is downloaded.
We could improve this number, but so far we haven't found that it significantly affects application performance. Mulberry is very conscientious about things that are more likely to affect performance, such as memory leaks as a result of improper component teardown. Apps with incredibly large data sets may experience slowdowns, but there are ways to mitigate that as well. Bottom line: in our year of use of the system, we've been fairly happy with performance, even with 387k of JS>
Since this was a rewrite of a system that just consumed the output of the CMS, the migration was not awful. One day, we just started exporting the new data format and using the new system to create apps. Users continued to use the same CMS to build their applications -- the CMS was the target of many improvements, but didn't get replaced wholesale. Thus the rollout of the new system wasn't really impacted by the number of users of the CMS. Though the Dojo/PhoneGap system in reality exists pretty independently from the CMS, you might think of it as the presentation layer of the CMS, so this rewrite really targeted a (significant) piece of a larger system.
Join a small, talented team that’s focused on radically changing how we approach front-end application development at Indeed. As an early team member, you’ll have significant input and influence on projects like a shared component library for UI development; tooling to make it easy for engineers to spin up and build new client-side applications; common systems for measuring and monitoring application performance; and more. You’ll evangelize front-end best practices to teams around the world, help them incorporate those practices into their development workflow, and take your learnings back to the front-end systems team to develop new tools. You’ll also help identify and mentor individual developers throughout the organization who will be the ultimate source of the front-end systems team’s success. Your work will increase the velocity of every developer who touches client-side code; it will impact hundreds of millions of job seekers around the world; it will — quite literally — change the face of Indeed.
---
The interview process will include a screening exercise and, for successful candidates, a day of on-site interviews. The process will focus specifically on identifying candidates with the required technical and communication skills necessary for the role; expect to talk about vanilla JS, maintainable CSS, client-side performance, testing client-side applications, designing and developing front-end systems to be used across projects, and communicating effectively with technical and non-technical audiences.
---
More information: http://www.indeed.jobs/career/JobDetail/Front-End-Engineer-S...