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'm sorry, Rebecca, I should have found a much more polite and constructive way to phrase my comment. Please forgive me for my bad attitude yesterday.
Perhaps I could get back to you with some more positive and specific suggestions on how the article could be improved? In the meantime I just wanted to apologize for the tone of my comment.
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 found your list to be spot on. I certainly have my weaknesses from that list, but I'm familiar with everything you mentioned. I've been making Websites for around eight years, but really only the past four have I considered myself a front-end dev.
It seems like every month there's a new fron-end trend that needs to be experimented with and learned. It gets a little daunting at times (hard to find the time, really) so I'm glad effort is being put in to lists like yours. I think it would be invaluable to a beginner.
> ...is that these topics are ones that anyone who calls themselves a front-end developer will need to be familiar with
I don't know about that. With Github you profess that experience with git is necessary to take advantage of "the rich open-source community that has arisen around front-end development technologies" – but that's not true. Explain how downloading the repo as a zip is slower or less advantageous than opening Terminal and typing commands – while I'm already looking at the Github project page in the browser? How would a purely front-end developer tell the difference?
> At the very least, you should be aware of tools like UglifyJS or Closure Compiler that will intelligently minify your code, and then concatenate those minified files prior to production.
In what world? This grates on me because it looks to be little more than grandstanding. And I hate grandstanding. What if you're coding with RoR or any other language with a sophisticated asset pipeline? Ugh.
50% of the techniques/tools you mentioned could be replaced or removed entirely without much issue in any front-end developer position I've encountered – in fact, this rigid brick layering of relative experience may even be looked upon as negative to an employer as it's clear that you are unwavering.
> that I wish someone had done for me in the past.
I think it's great for you to catalog and share, but to declare your list as the defacto baseline is ridiculous and presumptuous.
> Good front-end devs know to prefix any search engine query with mdn
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.
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.
I'm not sure why people are afraid of Makefiles. I know an incredible number of developers who view them as this scary black box. They are not a heavy weight thing which justify making excuses about not producing.
Here's what it takes to make a new Javascript project:
Unless you're jQuery, you don't need minification or GZipping because clients of your library already have their own. You don't need your own linting because you can trivially run `jshint project.js`.
If you find yourself running the same command in your shell a bunch of times, add it to your Makefile. It's that simple.
As someone who is not afraid of Makefiles (and has used them by default in past JavaScript-based projects), I welcome tools like Grunt to my projects. It fits in well with the types of "build" tasks I'm typically invoking in my JavaScript projects — and done so in a much simpler and abstracted syntax I prefer to work with.
Also, based on your comments, I think you and I have different definitions of "simple". :)
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/.
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...