How would you classify your experience level as a developer? What are your development strengths?
I've been programming since I was a kid. I started by learning how to hack the hex codes in Rollercoaster Tycoon to cheat, and then made GUI for it in Visual Basic, and then wanted to share it with the world, so I had to learn how to build a website, and it went from there.
I got my first programming job in high school at a small company doing mostly Flash, Actionscript, and Javascript. From there I learned PHP, went freelance bulding Wordpress sites in college, then Ruby on Rails, etc etc.
So that's about 15 years of professional experience. I'm completely self-taught. That's a strength because it reflects that I can adapt to any situation. I didn't know Actionscript at all when I got that first job, but I learned on the job. I've learned dozens of languages, libraries, and paradigms throughout my career, so not only am I not intimidated by new challenges, I revel in learning new things.
As far as development style, I pride myself on elegant code. It's not always possible or appropriate given the requirements, but when it is, I try to write code that is beautiful in its syntactical minimalism and its efficient use of axioms.
What are your top 1-2 favorite editor(s)?
I learned vim as part of a challenge with one of my coworkers to learn the most obscure technology in my first programming job out of college. I didn't realize at the time how common vim actually is, and I ended up falling in love with it.
Now-a-days I mostly use VSCode with vim keybindings for most of my serious development, but still use vim for toy projects or quick script editing.
Have you ever done a pull request?
Pull requests were the way we merged code into master at Makerbot. I started as a senior developer so I didn't have the authorization to actually merge to master, but I was promoted to a manager later, so I was responsible for reviewing code before merging, doing the merges, and ensuring that everything was sound after the merge.
Do you prefer working directly with the business people? Or do you find it's best to have a go-between run interference?
I've done both, and they each have their pros and cons. When working directly with the client, you have the advantage of being able to clarify their needs right there and then, but you also are responsible for managing their expectations and potentially having disagreements about the best approach to accomplish their goals.
Likewise, having someone else managing the clients can take off some stress, and allow you to focus on the engineering problems. However the disconnect in communication can be cumbersome. This is also dependent on the in-between person. Someone who's very knowlegeable about the technology and its limitations can be very helpful, but that's not always the case, so I've found myself in a position of managing the expectations of two people instead of one.
Have you worked with any of the cloud providers (Heroku, AWS, Azure)?
I've used Heroku and AWS on and off throughout my career. It's been a few years since I've worked directly with either, but it wouldn't take much to refresh my memory. I haven't used Azure, but like I said earlier, I love to learn, so I'm not worried about having to learn a new platform.
Can you explain what DevOps and/or continuous integration is, and some of the benefits? Have you used anything like GitHub Actions before?
CI is the practice of continually merging code and running automated tests and build processes on the master code. There are a few benefits, for instance this practice encourages you to portion changes into smaller pieces, and makes it easier to track down problems than working directly with the main code branch. Some other advantages is that you get added confidence that your main branch is stable, and you have builds continually ready to publish. I've used tools like GitHub actions to varying degress as different jobs. For instance, at Makerbot we had Travis running tests and builds. We also had automated linting, dependency management, and compression. The software had to be built for Mac, Windows and Linux, which was also automated which meant that the QA team always had fresh builds to reference to ensure each version was continually tested by humans before releasing.
Are you technology agnostic? Or are you pretty strict when it comes to things like Mac vs Windows, or AWS vs Azure?
My only real line is that I strongly prefer *nix based systems like Mac or Linux. I prefer to work in the command-line and between working with Macs, Linux servers, and my own Linux machine, the *nix interface just makes sense to me.
What do you know about "secure coding" practices?
There's the obvious things like not storing passwords in plain text, don't commit API keys to your git repositories, use SSL and HTTPS. I'm not a net-sec expert by any stretch of the imagination, but I usually do look up expert recommendations before releasing a product, especially with back-end code. The recommendations change fairly frequently, so I think this is a good practice rather than having too many hard rules committed to memory. Additionally, there's a lot of automated process to check for vulnerabilities which I've used. NPM can check for vulnerabilities, and Github has add-ons that I've used to check for potential vulnerabilities.
Have you ever had a chance to do server-side development? Does that interest you? If so, would you lean towards Node, or using some other language like C# or Python?
I've done a lot of server-side development. Most of my earlier jobs were server-side using Ruby and Golang. If I were given the choice I would probably write in Rust, but Node would be my second choice. I've written server-side code in Rust for my own projects, and it was a good experience, and it was lightning fast. I have written Python for jobs before, but it's not my favorite. I've only dabbled in C# when playing around with Unity, but I could pick it up, though it wouldn't be my first choice.
Are you happily satisfied with Web UI development? It's totally OK if you are, but we’re curious how eager you are to expand into things like native mobile development with Swift, etc.
My most recent jobs have been in React Native, so I haven't touched a lot of true Web UI development in a couple years, though the differences between React and React Native from a development standpoint are pretty minor. I've looked into writing native mobile, but the problem of having two codebases always stopped me from getting too attached to one platform. I've looked into Swift and it looks like a fairly solid language, so I'm ultimately not opposed to it.
On a scale of JavaScript to TypeScript, how critical do you think typing is to the future?
My hot take is that Typescript doesn't go far enough, haha. I think expressive and strong typesystems are a necessity for robust software. Dynamic typing is best suited for smaller scale scripting in my opinion. Past a certain level complexity, static analysis is invaluable. Not only that, but a well-designed typesystem can actually give you more tools of abstraction and expressive power that just isn't available in dynamic typing, or adhoc typing like with Typescript.
That said, I couldn't imagine starting a Javascript project without immediately reaching for Typescript, though I've been looking at alternatives like ReScript and Purescript lately. I've had success integrating the former, and less with the latter.
Don't jest in your response, but when do you think unit testing is seriously a good idea? And when is it a complete waste of time?
Heh, cute. Discretion definitely is a factor in having a comprehensive test suite. For instance, if you're using raw Javascript, it might be smart to test how a particular function reacts to having the wrong types passed to it. But if you're using Typescript this is completely unnecessary. I think it's also important to delineate where you're testing your code as opposed to testing an external library. As an example, if you're using something like Redux, it's unecessary to test that your state updates when your dispatch an action, because Redux should be taking care of that. Additionally, if your reducer is just merging the payload of an action into a state, that's up to Javascript to do properly. However, if you're doing something more complex like only updating some nested record under some conditions, you may want to break that out into a helper function and test that.
I think with experience, some pieces of code will raise red flags to you. Examples might be something that does complex data manipulation, or has a lot of conditions and possible code paths. I favor testing the smallest part that could go wrong, because once you validate that, more than likely, the rest of it will work too.
How comfortable are you in creating a webpack.config.js file from scratch? Would you say you are a Webpack master, or jedi in training?
It's been a little while since I've done that, so I would need a little practice before I could consider myself a jedi master, but it's not something I'm worried about. I've worked with Bower, Grunt, Chef, etc etc, and I'm aware Webpack is a little different, but I didn't struggle with it last time I worked with it, and I don't expect to have any problems with it moving forward.
It wasn't too many years ago that Webpack was the new kid on the block. Have you checked out some of the up-and-coming competitors like Rollup, Snowpack or others?
I've been in React Native land for the last few years, so I'm a little behind on this front.
Explain what NPM is, like you’re talking to your mother. Also, please unravel the motivation behind Yarn.
Okay, ma, so when I'm making a project, it would be pretty unreasonable for me to write everything from scratch. People have written code that they share for other people to use. So, I can install those from a central website and use their code. Also, NPM automatically makes a file that keeps track of the external code I'm using, and can refresh them or update them, or install them all from scratch if I move my code onto a new computer. But, if I have a really big project, installing those one-by-one can take forever, so there's Yarn which will install them all at once rather than one-at-a-time, which makes it a lot faster.
Have you ever published an NPM package? If not, based on what you just googled, what are the basic steps?
Years ago I made a library for ReasonML called Rationale. The motivation was that I was interested in using Reason as a Javascript replacement, but the stdlib was pretty pitiful, so I made a stdlib extension inspired by Ramda. My memory is a little hazy, but I remember having to set up an account on npm.org and logging in via the npm cli. I remember being diligent about version numbers was important to making sure npm didn't reject the package. Other than that, npm publish will put the package on NPM.
Can you explain what REST sorta kinda means?
REST is an architectural style for API endpoints managed through HTTP that is stateless. That means that each request is separate and no request information is stored between requests. Continuity is achieved through request headers. Furthermore, it has a consistent grammar to how requests are constructed for each endpoint.
For most things, REST is probably the way to go. But when do you guess GraphQL is a better fit?
I've never used GraphQL itself, but I've used systems that were arguably inspired by it. I was building a few apps for a company that was meant to be a monolithic platform for managing fashion businesses, particularly brick and mortar shops. Each of these apps had really specific requirements as to what data they needed, and the developer time to have a REST endpoint for each one would have been too unweildy. So having this GraphQL-like querying interface meant that I, as the front-end developer, could ask for the specific data I wanted, and only that, without having to bug the backend developer for a new endpoint, or having to grab a bunch of data I didn't need. Ultimately there was a big disconnect between the way the data was represented in the server, and the way it was shown to the client, so this approach granted us that flexibility, and I think it was the right approach for this situation.
Even if you've never used these, describe how important you feel front-end error tracking systems are, like Rollbar, LogRocket or even Hotjar?
I haven't used any of these, but I just released a React Native app on iOS and I'm currently beta testing it for Android, and not having error logs in the wild has been incredibly frustrating. I've been trying to solve that problem. Unfortunately, the "plug-and-play" solutions weren't working for my setup, so I'll have to sit down and think of something, but I haven't had the time between the job search and other bug fixes.
So, in short, I want to know every error that happens at all times. There's that old cliche that "it worked on my machine!" And of course that's true. No one would release something that wasn't working for them. That's why error tracking is so important; it can lead you to why it was working for you and not for another user. I can't count the number of times I've pulled my hair out trying to replicate something because either the error logs weren't helpful, or they were non-existant.
What are your thoughts on CSS styling libraries and when to use utility libraries like Tailwind vs more complete frameworks like Bulma? What about LESS and SASS -- when are they worth it?
Raw CSS has come a long way since the early days, but I still would reach for SASS or LESS when having to write CSS. Actually, the most recent website I had to make I used SASS, so I'm a fan.
I used a utility library a while ago called Tachyons that I found very helpful. I liked that it was pretty unopinionated, and just gave me composable styles to speed up development time. I used Bootstrap in the past, and there would inevitably be a point where I was spending more time overriding defaults than actually styling.
I haven't used Tailwind or Bulma, but Tailwind looks pretty similar to Tachyons, and I guess Bulma is more in the spirit of Bootstrap. Personally, I would probably lean toward Tailwind, but that's coming from experience with long-lived projects that end up changing their aesthetic pretty dramatically. Having small composable pieces makes these changes easier, whereas I feel like I'd have to either remove Bulma and start over, or spend a lot of time overriding defaults in the event of a radical design change.
How enthusiastic would you be if we asked to pay you to take some training courses on Udemy?
I love to learn so I'd probably jump at the opportunity. Currently I watch a lot of lectures about advanced programming topics.
How many of these platforms / languages / frameworks do you have experience with? Feel free to add similar items as you find appropriate. (organize your response in order or preference)
I'm not sure if there was meant to be a list with this question or if you're referring to the entirety of the questionairre, but with the exception of the error logging frameworks, I've heard of all of these, and worked with the grand majority of them, and if not, worked with something very similar.
- Front-end language: Typescript, Javascript
- Front-end framework: React
- Style language: SASS/LESS (don't have a preference for which)
- Back-end language: Rust, Node, Ruby
- OS: Manjaro, Ubuntu, MacOS
- Testing frameworks: Jest, Mocha, Chai
- Cloud platforms: Firebase, AWS, Heroku
- JS Package Manager: PNPM, Yarn, NPM