Ask HN: The Case for the “Front End Engineer” Role | Hacker News Reader

Ask HN: The Case for the “Front End Engineer” Role

2 pointsseige8 comments

I've spent 5yrs now doing FE Engineering. In our industry, thats grand total of 0 proof that I know programming. I accept that. What I still don't get is the interviewing cycle though. The interviews for the role continue to surprise, borderline shock me.I think I've been lucky to stumble across a few challenging jobs so far. In all of them, the fundamentally challenge was designing curation heavy environments(think photoshop) with lots of JS. This is eventually a systems design challenge rather than algorithm design.

This has made be believe that FE roles are primarily system design problems not algorithm design. My belief goes all the way back to the language itself. JS started as scripting language. Not a heavyweight like Java. As AJAX grew as a pattern over the last decade, we wrote lots of tiny scripts. We needed a way to manage 1000s of such snippets. It was driving us crazy. This is where it became a systems design problem. Case in point: rampant growth of JS MVC frameworks.

What makes FE Eng. different is that we care for the pixel till the end. Most people don’t internalize that. Just imagine working with illustrator for a day and instead of having a mouse to move objects, now you have to do it with numbers. Most folks with a heavy interest in algorithm design will cry at that task. Thats almost too blue collar for them. Maybe thats true… but that is work! Someone has to do it.

I have given interviews at several places now for FE Engineering role. A lot of times interviewers are engineers who think of it as a blue collar job. Hence, it quickly devolves into a self-boasting and a narcissist activity to prove that whose more white collar. The whole experience has an undertone that you are either a failed CS graduate or don’t have a degree and hence you are no match for me.

So what am i missing? Are we interviewing the right way or are their gaps in my understanding? Help me understand how i should re-think about it.

People are generally not taught how to interview well. To most, it's not a skill to be honed. I find this occurs often in software development, when engineers are asked to participate in the interview process.

This is why you still get companies, who pride themselves on having progressive engineering cultures, defaulting to whiteboard interviews, bland comp sci trivia, and puzzle questions even though they're proven to be awful indicators of on-the-job success.

Ten years ago this is how people were interviewed when they first got into the industry, so that's the only way they know how to interview now, despite the demographic and tooling significantly changing in software development.

Go back 10 years, front end only wasn't really a thing. This is new and a lot of folks haven't adapted (and maybe they won't).

Someone in a non technical role once suggested to me that we should all be able to do each others role, and that is now entirely unfeasible. The front end has evolved so far away from the back end as to be ridiculous.

I think your problem is who your talking to and working with. Keep shopping around and sharpening your skills, you will find a place that respects what you do, what it takes, and the talent involved.

A lot of engineers think I want to race against them in a bid for who is the smartest person in the room == algorithm design. I actually dont.

I am happy not being the smartest person. I am also happy accepting that maybe their role deserves a higher financial comp. if thats what is bothering them.

There is no point name calling companies in my experience who I think do this wrong but I'll take the opportunity to give a shout out to a few who do it right imo. Companies like Netflix, Apple and Uber for me have been the best interview experiences in this vein.

As a back end guy the things that get me excited are "we shaved XXms off of that request by doing something". That isn't the nature of front end work at all. I don't disrespect the things front end folks do, the browser is just another client, no different than IOS or android.

You have a rich environment to work in, and there are plenty of things to get excited about in it! What were full page reloads 10 years ago, can be partial loads of new data today, that can and will have material impact on bandwidth and server resources used! You can cut down render times, and optimize the hell out of a user experience (this change has XXX higher conversion making us more money or keeping eyes on the site longer). Don't be afraid to talk about your value and put it out there, figure out what is going to excite you and track it!

As for interviews, well they are always a mixed bag in the field (we still don't know how to do them right)! Find a place you like with people you like, and build a network! Your next job should not be a random interview but rather a phone call to those folks and a conversation about "what its really like where they are".

Lastly about the money. Well thats a mess across the board to. Bad actors who get paid more exist everywhere, and were not on a good path to fix that. Were seeing a lot of the disparity in pay between front and back end disappear, but it takes time.

I feel another strong issue in the mix is that we just don't know how to fill our 60min time slots with questions that are more relevant to front-end engineering.

In absence of literature, we resort to what we have experienced and that starts a long conversation about some problem with a back-tracking algorithm at work. The reality is that we are either afraid or ignorant to admit we dont know how to check skills for the role.

The interview panel IMO should be a mix from fields like engineering, design, product management and marketing instead of just engineering.

I think you make an excellent observation that FE is a system engineering challenge.

Algorithms do play an important role as you can see in this great presentation by Marc de Marco (https://www.youtube.com/watch?v=90NsjKvz9Ns)

However I think it's fair to say most FE engineers apply existing solutions and the system design is a bigger part of their role.

I differentiate between UI Engineering and Front-End Engineering. The former emphasises design integration (pixels) and performance (rendering). The latter is broader scope and emphasises the systems engineering.

Both have to deal with system design. UI is about components and messaging across the components with the front-end application being the "system". FE is about components that integrate the front-end application with what have traditionally been back-end APIs and services.

In many cases when people say FE they mean both FE and UI. I would not get hung up on these but they help to clarify what you are talking about and who you are trying to hire.

In the case of design and pixels there are specific challenges around dealing with layout and CSS and achieving 60fps. Creating UI components is an exciting area. For example see Pure UI (http://rauchg.com/2015/pure-ui/) by @rauchg. Mess in Web Components (https://hacks.mozilla.org/2015/06/the-state-of-web-component...). Challenge of style encapsulation...

So there are a lot of unique challenges and skills and experience required in UI engineering.

There are also exciting developments that start to push more overlap between UI and FE. For example GraphQL - the UI is "language" that "programs" what was traditionally the back-end API.

I sounds like you have had some unfortunate interview experiences. The interview process should be about uncovering the talent and potential - not one-upmanship.

I have an article on Medium that is the foundation of my interviews: https://medium.com/@johanstn/initiating-ui-engineering-conve...

What are you missing? I would not say you are missing anything. Rather a case of pulling together your skills and focussing them on what you really enjoy doing. It sounds like it is UI more than FE. If that's correct then your engineering expertise will lie on componentization, engineering applications ("system") and UI performance.

Demonstrate your skills with real examples, projects, code you use to learn and experiment.

I really like your article on Medium on initiating UI Engineering questions.

It took me a while but as an interviewer myself, i realized that I need to move away from an interviewing style that is strictly looking for answers that can be evaluated objectively. A couple of them are good to check for fundamental know-how but a process designed around just them just doesn't bring the right balance. Both left and right part of the brain need to be cross-checked on for a good candidate.

Depending on the level and requirements of the role, junior to senior, coding to architecture, the emphasis shifts from what you can do today with specific knowledge and understanding, to what you think we should be doing tomorrow with insights and reasoned opinion.

The answers are important but how you answer the questions, or reason about them when you don't know, more so.

Reply on news.ycombinator.com