5 ms·

I am a frontend engineer as well and would probably only be able to answer half of those questions reasonably without studying. Sigh.

by jzig 9y ago

kafkaesq 9y ago
Or, like you know, researching them (with essentially zero time overhead) on the job. The way engineers routinely do.
blaisio 9y ago
Which questions specifically would you have trouble with? While technically these aren't things someone absolutely has to know in order to be useful on frontend work, I think they are all very useful and practical things to know, so maybe you should learn about them!
- jzig 9y ago
  The following is intentionally a little snarky. I know what IP and DNS are but I couldn't tell you how they work. I almost never use `this` and therefore don't remember all of its nuances. My team specifically avoids using it because it is harder for junior devs to grasp and makes things harder to read. I tend to agree. Writing a reduce function? That's what I use lodash for. What is REST? I use it every day but would have to look up a proper definition for you. The event loop? I know what it is but I have never needed to know what it is. I should learn these things because they are practical? Most of them aren't at my current job, but that's just my experience. And I probably get paid enough and have enough day to day freedom that I wouldn't want to work for you. However I would gladly answer all of these questions as a part of take home "homework". Sorry if I'm being a curmudgeon. Shrug. P.s. your website is down!
  - Sohcahtoa82 9y ago
    > What is REST? I use it every day but would have to look up a proper definition for you. REpresentation State Transfer ... That's about all I can do to define REST. I can't really tell you what it really means beyond describing CRUD, but I can identify a REST interface when I see one.
    - eyelidlessness 9y ago
      REST isn't exactly aligned with CRUD, though it's often used for CRUD APIs. REST generally describes (roughly in order of most common in implementation to least): - HTTP requests operate on resources - HTTP verbs describe the specific operations to perform (most typically HEAD, GET, POST, PUT, DELETE; some systems also implement OPTIONS, PATCH, custom verbs; some less-RESTful systems use POST for everything besides GET) - Resources have a single identifier (URL); some systems get this wrong - Query string parameters provide filtering and conditional behavior on requests for resources - HTTP status codes indicate the condition of the response - HTTP headers provide mechanisms for authorization/authentication, content type negotiation, pagination, error condition mitigation (redirects, rate limiting, etc) - Responses provide URLs to related resources where appropriate I'm probably forgetting a ton. The fundamental idea behind REST is to use the semantics of HTTP, as they were designed, to implement and interact with an API.
      - Sohcahtoa82 9y ago
        Well damn I just got told what's up.
        eyelidlessness 9y ago
        I wish I'd noticed how bad the formatting was on that. I don't see a way I can edit it to fix it now.
  - eyelidlessness 9y ago
    > I almost never use `this` and therefore don't remember all of its nuances. My team specifically avoids using it because it is harder for junior devs to grasp and makes things harder to read. I tend to agree. Honestly I think `this` (and any OOP technique) should be avoided except under very specific circumstances, regardless of whether junior devs are involved. Exceptions include (but are not limited to): - Interaction with native APIs or legacy libraries which mandate its use - React lifecycle or other modern lib equivalent, if absolutely necessary - When using a `class`, and only if it would be substantially more clear than a functional alternative > Writing a reduce function? That's what I use lodash for. Unless you need it for non-`Array` collections, just use `Array#reduce`. > The event loop? I know what it is but I have never needed to know what it is. Every time you do anything asynchronously in JS, you are interacting with the event loop. It would be a good idea to familiarize yourself with it, to understand the constraints and performance impacts of single-threaded asynchrony.
baron816 9y ago
I'm a frontend engineer who can answer all but 2-3 of those problems with relative ease and can't get a job for the life of me. Whatever that's worth.
ziziyO 9y ago
Lists like these are why imposter syndrome is so prevalent among engineers. You read something like this and suddenly you wonder if you're actually qualified to even be in the industry. Most of those questions will give no indication of a person's effectiveness as a frontend engineer, with the exception of the system design questions. Those are mostly rooted in actual problems that you might encounter as a frontend engineer.

I am a frontend engineer as well and would probably only be able to answer half of those questions reasonably without studying. Sigh.

by jzig 9y ago

I am a frontend engineer as well and would probably only be able to answer half of those questions reasonably without studying. Sigh.

kafkaesq 9y ago

Or, like you know, researching them (with essentially zero time overhead) on the job. The way engineers routinely do.

blaisio 9y ago

Which questions specifically would you have trouble with? While technically these aren't things someone absolutely has to know in order to be useful on frontend work, I think they are all very useful and practical things to know, so maybe you should learn about them!

jzig 9y ago
The following is intentionally a little snarky. I know what IP and DNS are but I couldn't tell you how they work. I almost never use `this` and therefore don't remember all of its nuances. My team specifically avoids using it because it is harder for junior devs to grasp and makes things harder to read. I tend to agree. Writing a reduce function? That's what I use lodash for. What is REST? I use it every day but would have to look up a proper definition for you. The event loop? I know what it is but I have never needed to know what it is. I should learn these things because they are practical? Most of them aren't at my current job, but that's just my experience. And I probably get paid enough and have enough day to day freedom that I wouldn't want to work for you. However I would gladly answer all of these questions as a part of take home "homework". Sorry if I'm being a curmudgeon. Shrug. P.s. your website is down!
- Sohcahtoa82 9y ago
  > What is REST? I use it every day but would have to look up a proper definition for you. REpresentation State Transfer ... That's about all I can do to define REST. I can't really tell you what it really means beyond describing CRUD, but I can identify a REST interface when I see one.
  - eyelidlessness 9y ago
    REST isn't exactly aligned with CRUD, though it's often used for CRUD APIs. REST generally describes (roughly in order of most common in implementation to least): - HTTP requests operate on resources - HTTP verbs describe the specific operations to perform (most typically HEAD, GET, POST, PUT, DELETE; some systems also implement OPTIONS, PATCH, custom verbs; some less-RESTful systems use POST for everything besides GET) - Resources have a single identifier (URL); some systems get this wrong - Query string parameters provide filtering and conditional behavior on requests for resources - HTTP status codes indicate the condition of the response - HTTP headers provide mechanisms for authorization/authentication, content type negotiation, pagination, error condition mitigation (redirects, rate limiting, etc) - Responses provide URLs to related resources where appropriate I'm probably forgetting a ton. The fundamental idea behind REST is to use the semantics of HTTP, as they were designed, to implement and interact with an API.
    - Sohcahtoa82 9y ago
      Well damn I just got told what's up.
      - eyelidlessness 9y ago
        I wish I'd noticed how bad the formatting was on that. I don't see a way I can edit it to fix it now.
- eyelidlessness 9y ago
  > I almost never use `this` and therefore don't remember all of its nuances. My team specifically avoids using it because it is harder for junior devs to grasp and makes things harder to read. I tend to agree. Honestly I think `this` (and any OOP technique) should be avoided except under very specific circumstances, regardless of whether junior devs are involved. Exceptions include (but are not limited to): - Interaction with native APIs or legacy libraries which mandate its use - React lifecycle or other modern lib equivalent, if absolutely necessary - When using a `class`, and only if it would be substantially more clear than a functional alternative > Writing a reduce function? That's what I use lodash for. Unless you need it for non-`Array` collections, just use `Array#reduce`. > The event loop? I know what it is but I have never needed to know what it is. Every time you do anything asynchronously in JS, you are interacting with the event loop. It would be a good idea to familiarize yourself with it, to understand the constraints and performance impacts of single-threaded asynchrony.

baron816 9y ago

I'm a frontend engineer who can answer all but 2-3 of those problems with relative ease and can't get a job for the life of me. Whatever that's worth.

ziziyO 9y ago

Lists like these are why imposter syndrome is so prevalent among engineers. You read something like this and suddenly you wonder if you're actually qualified to even be in the industry. Most of those questions will give no indication of a person's effectiveness as a frontend engineer, with the exception of the system design questions. Those are mostly rooted in actual problems that you might encounter as a frontend engineer.