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.<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.
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.<p>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.<p>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).<p>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.<p>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.
I think you make an excellent observation that FE is a system engineering challenge.<p>Algorithms do play an important role as you can see in this great presentation by Marc de Marco (<a href="https://www.youtube.com/watch?v=90NsjKvz9Ns" rel="nofollow">https://www.youtube.com/watch?v=90NsjKvz9Ns</a>)<p>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.<p>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.<p>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.<p>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.<p>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 (<a href="http://rauchg.com/2015/pure-ui/" rel="nofollow">http://rauchg.com/2015/pure-ui/</a>) by @rauchg. Mess in Web Components (<a href="https://hacks.mozilla.org/2015/06/the-state-of-web-components/" rel="nofollow">https://hacks.mozilla.org/2015/06/the-state-of-web-component...</a>). Challenge of style encapsulation...<p>So there are a lot of unique challenges and skills and experience required in UI engineering.<p>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.<p>I sounds like you have had some unfortunate interview experiences. The interview process should be about uncovering the talent and potential - not one-upmanship.<p>I have an article on Medium that is the foundation of my interviews: <a href="https://medium.com/@johanstn/initiating-ui-engineering-conversations-946906b4c710" rel="nofollow">https://medium.com/@johanstn/initiating-ui-engineering-conve...</a><p>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.<p>Demonstrate your skills with real examples, projects, code you use to learn and experiment.