5 ms·

This is basic stuff. Perfect answers aren't required.. it's just whether or not you can have a conversation on something technical which you ought to be, accord

This is basic stuff. Perfect answers aren't required.. it's just whether or not you can have a conversation on something technical which you ought to be, according to your job title, at least vaguely familiar with. Don't take this type of exercise personally; it's not aimed at you - it's aimed at the many people who call themselves "full-stack engineers", but haven't ventured beyond the bounds of a particular framework.

gunapologist99 5y ago
> it's aimed at the many people who call themselves "full-stack engineers", but haven't ventured beyond the bounds of a particular framework. That's a great point. Lots of people think that full-stack means knowing how to use npm to install tailwind and express. They just don't know what they don't know. A "full-stack engineer" should be very familiar with standards like TCP/IP, HTTP headers, the OSI model, CSS things like flexbox, DOM, CORS, SQL, websockets/eventsource, unicode etc etc as well as probably multiple web frameworks in multiple languages, various backend and cloud platforms (at least enough to get around in) like AWS and GCP, and understand what proxies and TLS are and what they do, and probably also how to do things like Let's Encrypt and write secure code with XSS, CSRF, etc hardening. Obviously, everything is a gradient, and nobody is perfect with everything (as well as the JS build tool of the week) but this stuff takes years and perhaps decades to really grok. There's nothing wrong with being a "junior dev", or just a "dev", or whatever -- it takes a lot of effort to master your craft, especially when you're crossing multiple domains from front-end to back-end to security to architecture. But it is important to know where you best fit in, at least at whatever your current career stage is.
- whakim 5y ago
  I think it's unrealistic for any engineer to remain highly proficient in many of those things simultaneously. I use AWS day-to-day, but haven't used GCP day-to-day in 5+ years - should I realistically be able to keep abreast of the vast number of GCP changes that have happened over that time (plus all the changes in devops that make the workflows I was using 10 years ago look outdated)? Many projects don't need Websockets or Eventsource - do I have to keep that knowledge top-of-mind across the years that I don't use them? Can you really claim that you're "very familiar" with that web framework that you used two jobs ago - assuming there haven't been a bunch of major changes since then? I guess my point here is that proficiency teaches you some knowledge, but perhaps more importantly it provides you with context, guidance and direction when picking up new stuff (or catching up on old stuff).
  - gunapologist99 5y ago
    When referring to AWS/GCP, I said, > "at least enough to get around in" Because, you're right -- cloud-based knowledge changes a lot faster (and gets wider) than standards-based, and it's actually a lot less useful because you don't know from year to year if the knowledge is even still relevant or if the product is still supported. And, yes, you do need to keep standards-based knowledge top-of-mind, even if you perhaps are not currently building projects on them and even if you can't remember the specifics of syntax etc. Knowing every tool in your toolbox will make you a far better engineer, and, yes, it absolutely can be done.
- ZephyrBlu 5y ago
  > A "full-stack engineer" should be very familiar with... That person doesn't exist, gradient or not. There's no way for someone to be "very familiar" with so many different domains at the same time. By the time you gain familiarity with all the domains, the information you initially learned will be out of date or you will have forgotten. Also, full-stack colloquially refers to someone who can work on frontend and backend.
  - withinboredom 5y ago
    I sometimes market myself as a “true full-stack engineer” and I’d say I’m pretty darn familiar with everything from the machine code, lexer, parser, compiler, linker, language idioms in a few languages, frameworks, CSS, HTML, TCP/IP, an ever-hating-and-hope-will-die feeling towards GRPC, JSON quirks, YAML quirks, how file systems work, how email works (SMTP, DKIM, SPF, etc), k8s, the Linux kernel, custom drivers, video game engines and the maths behind them (like Quaternions, vectors, matrices, etc), and probably a few other things I can’t remember right now. It takes a lot of time work to stay on top of these things but it’s a passion, and some things I know exist but don’t know the current incantation for (like getting full screen access for a game engine). It used to be quite long, but I think it’s much less LoC these days. Anyway… we do exist. Like I said, for me it’s a passion. It probably won’t come up in an interview unless it’s a startup and the job sounds incredibly interesting. Even then I might keep my mouth shut just to not come across as over-qualified or “too expensive.”
    - ZephyrBlu 5y ago
      To me being "very familiar" with those things would mean that you could perform the role of a SWE, SRE, compiler dev, <language> dev, <framework> dev, kernel dev, engine dev, etc right now and be effective. Since that isn't possible I have to assume that you have a different definition of "very familiar" than I do.
      - psyc 5y ago
        It is possible. Contradiction dissolved.
- rhizome 5y ago
  "Very familiar" feels pretty squishy, aren't there fairly standard HR terms for these levels of knowledge? I'm pretty sure it's less than "proficient" which is less than "expert," and I feel there should be at least one more in the middle there. I've always understood "familiar" being just a little more than exposure.

gunapologist99 5y ago

> it's aimed at the many people who call themselves "full-stack engineers", but haven't ventured beyond the bounds of a particular framework. That's a great point. Lots of people think that full-stack means knowing how to use npm to install tailwind and express. They just don't know what they don't know. A "full-stack engineer" should be very familiar with standards like TCP/IP, HTTP headers, the OSI model, CSS things like flexbox, DOM, CORS, SQL, websockets/eventsource, unicode etc etc as well as probably multiple web frameworks in multiple languages, various backend and cloud platforms (at least enough to get around in) like AWS and GCP, and understand what proxies and TLS are and what they do, and probably also how to do things like Let's Encrypt and write secure code with XSS, CSRF, etc hardening. Obviously, everything is a gradient, and nobody is perfect with everything (as well as the JS build tool of the week) but this stuff takes years and perhaps decades to really grok. There's nothing wrong with being a "junior dev", or just a "dev", or whatever -- it takes a lot of effort to master your craft, especially when you're crossing multiple domains from front-end to back-end to security to architecture. But it is important to know where you best fit in, at least at whatever your current career stage is.

whakim 5y ago
I think it's unrealistic for any engineer to remain highly proficient in many of those things simultaneously. I use AWS day-to-day, but haven't used GCP day-to-day in 5+ years - should I realistically be able to keep abreast of the vast number of GCP changes that have happened over that time (plus all the changes in devops that make the workflows I was using 10 years ago look outdated)? Many projects don't need Websockets or Eventsource - do I have to keep that knowledge top-of-mind across the years that I don't use them? Can you really claim that you're "very familiar" with that web framework that you used two jobs ago - assuming there haven't been a bunch of major changes since then? I guess my point here is that proficiency teaches you some knowledge, but perhaps more importantly it provides you with context, guidance and direction when picking up new stuff (or catching up on old stuff).
- gunapologist99 5y ago
  When referring to AWS/GCP, I said, > "at least enough to get around in" Because, you're right -- cloud-based knowledge changes a lot faster (and gets wider) than standards-based, and it's actually a lot less useful because you don't know from year to year if the knowledge is even still relevant or if the product is still supported. And, yes, you do need to keep standards-based knowledge top-of-mind, even if you perhaps are not currently building projects on them and even if you can't remember the specifics of syntax etc. Knowing every tool in your toolbox will make you a far better engineer, and, yes, it absolutely can be done.
ZephyrBlu 5y ago
> A "full-stack engineer" should be very familiar with... That person doesn't exist, gradient or not. There's no way for someone to be "very familiar" with so many different domains at the same time. By the time you gain familiarity with all the domains, the information you initially learned will be out of date or you will have forgotten. Also, full-stack colloquially refers to someone who can work on frontend and backend.
- withinboredom 5y ago
  I sometimes market myself as a “true full-stack engineer” and I’d say I’m pretty darn familiar with everything from the machine code, lexer, parser, compiler, linker, language idioms in a few languages, frameworks, CSS, HTML, TCP/IP, an ever-hating-and-hope-will-die feeling towards GRPC, JSON quirks, YAML quirks, how file systems work, how email works (SMTP, DKIM, SPF, etc), k8s, the Linux kernel, custom drivers, video game engines and the maths behind them (like Quaternions, vectors, matrices, etc), and probably a few other things I can’t remember right now. It takes a lot of time work to stay on top of these things but it’s a passion, and some things I know exist but don’t know the current incantation for (like getting full screen access for a game engine). It used to be quite long, but I think it’s much less LoC these days. Anyway… we do exist. Like I said, for me it’s a passion. It probably won’t come up in an interview unless it’s a startup and the job sounds incredibly interesting. Even then I might keep my mouth shut just to not come across as over-qualified or “too expensive.”
  - ZephyrBlu 5y ago
    To me being "very familiar" with those things would mean that you could perform the role of a SWE, SRE, compiler dev, <language> dev, <framework> dev, kernel dev, engine dev, etc right now and be effective. Since that isn't possible I have to assume that you have a different definition of "very familiar" than I do.
    - psyc 5y ago
      It is possible. Contradiction dissolved.
rhizome 5y ago
"Very familiar" feels pretty squishy, aren't there fairly standard HR terms for these levels of knowledge? I'm pretty sure it's less than "proficient" which is less than "expert," and I feel there should be at least one more in the middle there. I've always understood "familiar" being just a little more than exposure.