

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

I&#x27;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&#x27;t get is the interviewing cycle though. The interviews for the role continue to surprise, borderline shock me.I think I&#x27;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.<p>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.<p>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.<p>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.<p>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.
======
panorama
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.

------
zer00eyz
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.

~~~
seige
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.

~~~
zer00eyz
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.

~~~
seige
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.

------
jsteenkamp
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](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/](http://rauchg.com/2015/pure-ui/)) by @rauchg. Mess in Web Components
([https://hacks.mozilla.org/2015/06/the-state-of-web-
component...](https://hacks.mozilla.org/2015/06/the-state-of-web-
components/)). 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...](https://medium.com/@johanstn/initiating-ui-engineering-
conversations-946906b4c710)

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.

~~~
seige
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.

~~~
jsteenkamp
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.

