I'm putting the thanks section first, because without the great organizers and questions from the attendees, this AMA event could have been a real bust!
So: thank you to the DVLP DNVR team and all the folks who showed up to talk about remote work and ask me questions on !
I think I had some pretty good answers to some of the questions, and some maybe okay(ish) answers to others!
During and after the event, I realized I had made a mistake by not having resources about remote work readily available somewhere for everyone to see!
After the event, I got some more questions via Slack (Denver Devs) and my email (rdl.ph).
I want to make sure there's a single place to collect everything, so I'm collecting everything here.
The majority of the event was recorded, so you can find that video below.
The recording begins in the middle of a question asking what Jamstack is and if it's just for sites without servers (it was a nuanced question, so that's not exactly a good paraphrase!).
I mentioned a few links and other resources, so I've collected those below.
Some folks have asked me more questions after the fact, so I thought I'd collect those questions and my answers below.
From Tobie Tsuzuki:
What advice do you have looking for remote jobs as your first technical role?
That's a tough one!
To be clear, my first job wasn't remote, so I can't give you any insight from that side of the picture.
However, I've hired people (remote & otherwise) and I've gotten jobs remote after my first, so here's what I think:
I admit that's something I can say from a place of privilege: if you don't have a job, anything is better than nothing - excitement aside!
But it really helps you stand out when you have lots of experience with the company, like their product, use their product, have ideas of how to improve their product, etc.
"Passion" is an overused and under-defined search criteria, but if I were to use "passion" as a hiring criteria, this is what I want.
Do you want to work for this company on our product, or are you excited about something else?
Being excited about the company will make you more successful no matter what the tech is, whether or not it's remote, etc.
The skills for remote aren't really all that different than the skills for non-remote work, but often during hiring the onus is on you - the candidate - to show that you can exercise those skills.
Sadly this isn't as often the case when hiring for "local" employees, but it should be.
Those skills are (not exclusively!):
Basically, if you can think of a skill you should have as a professional engineer, being able to demonstrate those skills (ideally with evidence!) is crucial to laying an initial foundation of trust for remote work.
It's fine to say "remote work is better for me because my sleep schedule doesn't fit the average work time period."
However, some companies might interpret that as: "I'm going to slack off all day and party all night."
A better phrasing might be something like: "I think remote work is a great way to run a business because it means I can work in all the time I'm most productive throughout the day!"
Now it's phrased such that the business sees how they're benefitting from you working remote!
And a followup:
When you are looking for 'passion' do you expect the candidate to have made projects or can demonstrate a working understanding of the product, or is a well crafted cover letter enough to get your foot in the door.
A well-crafted cover letter is enough to get your foot in the door, but only that.
I would say that for any job interview, remote or not, you should know as much as you possibly can about the product.
I've used GitLab for many years, but before I interviewed, I read all of their product marketing, dove into the handbook and read up on policies and engineering structure, read guidance docs for the way they run reviews and code styleguides, etc.
I think if you want a job that necessarily means you should have at least a working understanding of their product, but probably more than that.
As for projects, that's kind of a tough one.
For someone coming to me for their first technical role, probably looking for a junior level position, I'd be less interested in their projects.
I know those projects probably wouldn't apply directly to my company in all but a small handful of cases, so I wouldn't be judging too harshly on those projects.
I would look for the following, however:
We all had to do schoolwork; did the candidate want to do more?
Let's say you're applying for a front end position.
If all of your projects are Python and Rails, I'm going to raise an eyebrow and wonder if you're going to succeed.
I'll still give you a shot!
As a junior / first time tech role, it's totally fine to not know specifics about where you want your career to go.
But, if you can say: "I love the nuts and bolts of reactive data flow, and I've recently gotten really interested in Observable streams" that shows me that you've explored the depths of your field (front end in this case, it's just an example).
Critical thought and "digging in" to tech is important to advancing, so showing those things early means I'm more likely to take a risk on you.
Following up again:
I really like the idea of digging into tech. What's your approach for furthering your understanding of certain techs?
So far since I am more junior and I don't know where I am headed, I have just been trying to learn any new thing that seems interesting, but after trying to learn multiple frontend frameworks it seems I have no deep rooted knowledge of any of them.
☝🏻 This is absolutely the Achille's Heel of front-end frameworks.
They abstract so much away and often invent their own syntax (thus requiring compilers and transpilers) that it often doesn't make sense for new learners to understand what's actually happening under the hood!
I would say the best way to start digging in is identify something that you think is important or cool, and then start searching for ways to write your own of that!
I know it sounds crazy, but it's the best way to really get into the fundamentals.
So here's an example.
Let's say you use React all the time.
You have learned or self-identified that the way React renders new things to the screen is really cool.
It's just so convenient for you as a developer to spit out the same
HTML from your
render function and then React magically updates the DOM for you... so good!
Okay! But how does it work!?
Build one yourself!
Should be moderately simple, right?
So it sounds like you're going to need to learn what React is doing (Virtual DOM <-> Real DOM diffing), which means you'll need to learn about virtual DOMs, which means you'll need to learn about document fragments in memory.
Then you'll need to learn how React chooses what to update (what counts as having changed?), and in fact how it maintains hooks into the DOM so it can update appropriately.
Start piecing these things together.
Your first pass can just be the worst thing ever, it's fine.
As you learn more and more about this really specific topic, it'll improve.
Most importantly, as you learn more, you'll identify either that this still intrigues you, or that it doesn't.
If it doesn't, you can start over, pick something new!
Maybe.... How do CSS transitions and transforms work?
Is CSS an animation library? Surely not? ..... hmm something to research.
Finally, I find the MDN Web API page incredibly illuminating. It shows me all the things I don't know.
I would recommend you take a look at the
Interfaces section and see if anything jumps out at you.
I think bare minimum learning would be to understand all of the things that start with
I look at that list and I really want to dig into, for example,
Any of the
RTC* (Real Time Communication) stuff also looks really cool.
Then Tobie asked a question about another meetup I run - Jamstack Denver:
I saw the JAMStack meetup and thought Svelte looks pretty smooth but not sure if will gain any traction what were your impressions of it?
Well... HMM 😅
I think it's a cool idea.
label) to indicate data binding (e.g.
$: [some expression])
The guy who made Svelte (Rich Harris) also made Ractive.js, and Svelte feels like an incremental step forward - he essentially moved Ractive.js into a JS compiler instead of a frontend framework.
hyperHTML-style DOM libraries (like
lit-html) and the platform-native component model baked into web browsers.
I don't really think it's going to catch on.
Sadly, I think VDOM-based tools established themselves early, and it's hard to pry people away from that.
That said, VDOM is embarrassingly inefficient, so I hope that tools like
lit-html and Svelte (not itself
hyperHTML-like, but it's better than VDOM) eventually win out.