Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
That’s a damn one-two punch from Dave. He goes for the ultimate clickbait title¹, then follows up with a pile of epic advice for us all. If you want web browsers to get better, listen up:
Complaining on Twitter sure does feel good but it doesn’t do much other than burning bridges and burning through people’s patience. I guess you may also get hit with the mute button which is probably the opposite effect you were hoping for. Despite how good or valid your complaint is, combativeness results in immediate dismissal by your target audience… not once, but for years. People hold grudges for a shockingly long time.
And so:
The best thing I’ve ever done in my career is blog about my specific problems with browsers (or any software you’re passionate about). This goes for software beyond browsers too. I’ve done this for IE, Safari, Edge, Firefox, Chrome, Windows 10, WSL and I’ve seen first hand how a “friction log” can become a powerful tool in an organization.
Behind the scenes, your posts will get picked up by external-facing developer advocates and shared internally. A single blog post is worth 10,000 tweets.
To Shared Link — Permalink on CSS-Tricks
Before I go: When it comes to complaining about web browsers originally published on CSS-Tricks. You should get the newsletter.
Chaos Engineering might sound like a buzzword - but take it from someone who used to joke his job title was Chief Chaos Engineer (more on that later) it is much more than buzz or a passing fad - it’s a practice.
The world can be a scary place and more and more companies are beginning to turn to Chaos Engineering to proactively poke and prod their systems and in doing so are improving their reliability and guarding against unexpected failures in production and unplanned downtime.
Following a recent interview on the Dev Interrupted Podcast, OutSystems CEO and founder Paulo Rosado joined us to chat about his path to founding the company, advice for successful leaders, and the growing threat of technical debt. The conversation below has been edited for length and clarity.
Tell us about OutSystems' founding story. What inspired you to start the company?
When we were small, we asked for help all the time. Dependent on our parents, friends, teachers, and siblings to help us navigate the complexities of life, asking for help seemed like the most natural thing to do. As a child, I don’t remember dealing with any painful emotion while asking for help, worrying about what it would do to my self-esteem or the damaging effect it can have on the image I have built for myself. I was simply happy to learn from everyone around me, knowing I could rely on people to give me useful advice when I needed one. Indeed, the best feeling in the world.
Yet, somewhere along the way, the meaning of help changed. I had caught on to the bug of independence and individualism. Asking for help became less about learning and more about my identity. It made me question my own abilities. Will it make me look weak or incompetent? Will others think less of me if they find me dependent? Will people question my intelligence and smartness? I would much rather struggle through a task and waste countless hours without accomplishing anything than approach someone. I was hungry for information but ready to stay foolish.
Not all operating systems are built equal. In fact, there is plenty of variety when it comes to multitasking, overheads, memory use, and more. This spectrum of choices can make things difficult for Internet of Things (IoT) developers when it comes to choosing the right system for their device.
One type that is uniquely suited to connected devices—at least basic ones—is Bare Metal. Just as a Bare Metal server only hosts one tenant at a time, a Bare Metal environment is entirely dedicated to running a single application. This is in stark contrast to regular operating systems which run multiple programs simultaneously. Let’s take a look at the different types of operating systems and consider which is best when it comes to IoT.
This week, my main task for this sprint was canceled. While not as momentous as the cancellation of an entire project (I've been there too), deleting the past week's work still stung. This isn't the first time, though, so I know that there are a few things to keep in mind:
Bottom line: Were you paid for your work? Then your employer still sees it as valuable, if only to make sure that a given line of development was sufficiently explored before determining it wasn't worth continuing. Developing a product or service often means saying 'no' to things, and sometimes that means cutting losses before the sunk cost fallacy takes hold.
Keep a habit of scribbling out the algorithm/pseudo-code before you actually convert the solution into code. Writing by hand can also help you plan your code before you move it to the computer. You can save a lot of time if you write out which functions and classes you will need, as well as how they will interact. Although more time consuming, this restriction will mold you into a more fundamentally sound developer.
When you are implementing a feature, its always good to split the bigger tasks into smaller and clearer tasks which are individual logical units and can be tested individually. Keep a list of such small achievable tasks and keep ticking against them once you complete it. This will give you a boost and motivate you to keep ticking more boxes. The checklist can be either in a book or in any software (like Google Keep).
Someone emailed me:
What approach to building a site should I take?
- Build a single responsive website
- Build a site on a single domain, but detect mobile, and render a separate mobile site
- Build a separate mobile site on a subdomain
It's funny how quickly huge industry-defining conversations fade from view. This was probably the biggest question in web design and development this past decade, and we came up with an answer: It's #1, you should build a responsive website. Any other answer and you're building multiple websites and the pain from that comes from essentially doubling the workload, splitting teams, communication problems across those teams, inconsistencies across the sites, and an iceberg of other pain points this industry has struggled with for ages.
But, the web is a big place.
This emailer specifically mentioned imdb.com as their example. IMDB is an absolutely massive site with a large team (they are owned by Amazon) and lots of money flying around. If the IMDB team decides they would be better off building multiple websites, well that's their business. They've got the resources to do whatever the heck they want.
The post How Many Websites Should We Build? appeared first on CSS-Tricks.
I recently did an AMA over on DEV. Just taking the opportunity to port over some answers here like a good indiewebber.
You need to put yourself in a position where it's your job to create and take care of a website. Even if that feels like a stretch for you early on. Get the domain, get the website on the public internet. Put your name on it. Now you've given yourself stakes, and you'll learn technology because you must make your ideas come to life.
For me, 650 years ago, that was putting up a website for the ol' college band. We needed a website! That sounded like fun to me, and I managed to struggle through buying a domain, hosting, and putting up a WordPress website. Then, over time, I learned front-end web technologies because I wanted to change up the design, change up the templates, add cool features, etc.
Get yourself a project and learn through the project.
I usually won't avoid the tweet. The tweet is usually a good proving ground for the blog post anyway. If nobody cared, eh, maybe not that good of a post. If it does get good engagement, it's like the conversation around it is useful in the creation of the blog post. Plus, tweets are so easy to kick out the door. Blog posts, for me, on purpose, have a longer schedule that includes editing and scheduling and such.
Here's an example tweet. Just a silly little UI experiment. I didn't feel like waiting to blog about it to drop the demo. But from the Twitter thread, I got some interesting technical feedback, info about what parts people were most suprised by, and some other related ideas. That will, hopefully, lead to a much more robust blog post.
I even treat DEV like that, honestly. I wrote this blog post reaction quickly here, but then refined it for my own blog with some of the feedback.
I think "scroll shadows" in CSS is one of my favorite CSS tricks of all time. It's originally by Roman Komarov, but explained and improved by Lea Verou. I saw a tool the other day around the idea by Stefan Judis.
It's a real mind-bender involving four-layered gradient backgrounds, each positioned, sized, and colored differently, and then behaviorally different regarding scrolling.
It's not just a neat trick because it has real UX implications. Showing a shadow of where you can scroll is important UX. Consider this story of a recent design update in iOS that led to complete confusion around UI actions hidden behind a place you could scroll to, but had zero affordance on how to get there. (Happens to me all the time in Spotify, for the record.)
I think writing is literally the only way.
I can't think of a developer with influence who has that influence for anything other than writing. Or if it's not writing, then it's a YouTube channel or some other form of creating public stuff.
This super-low level stuff sometimes feels over my head. It's hard for me to picture the industry implications of stuff like this just by looking at specs, ya know?
To me, it seems the Layout API has the most powerful potential.
What I'm imagining right now is that Houdini doesn't affect normal day-to-day front-end developers like me that much. I won't be writing much Houdini code. But I'll use fancy things that other people create, because it does something useful for me. Just like most people don't write their own libraries or have published npm packages — they just use them.
It's fun to be wow'd by Houdini. If anyone is looking for that, make sure to look at Vincent De Oliveira's showcase website.
You know what I really like? I like getting into the office every day and having a pretty decent amount of freedom of what I'm going to do that day. I'll probably have meetings. I'll probably have some stuff on the ol' calendar. I'll probably have some team expectations I'm trying to meet. But I also usually have plenty of time to pursue things that are interesting to me at the moment.
Sometimes I'm in the moment to drill through some emails. Sometimes I want to tinker with some demo that sounds like fun. Sometimes I want to write up a thought or record a video. Sometimes I want to plan something out or document something. Sometimes I want to talk something out with other people or do some pair programming.
I'm fortunate that I'm the boss (lol) and I put myself in that position on purpose so I have that freedom.
I feel like every time someone asks this we all should take every opportunity to scream Container Queries! until we get them.
The idea is that we should be able to write CSS that says, "When this element is this wide, this CSS should take effect." And not just width, but whatever media queries we have at the page level already.
The best demo of a use case out there is Philip Walton's page.
I want to write a card component that shuffles itself around based on how wide it is, not how wide the page is, because there isn't always a direct connection between those two things (e.g. a card component can show up in a narrow sidebar on a large screen, but be full-width on a tablet or something).
Every component can be in a situation like that, so for the love of CSS, let me write media queries scoped to those components. I echo a lot of other people when I saw that if we had this, the vast majority of media queries we write would be these, not page-level.
I'm not sure I've ever made a big fold-based decision once in my career. Not a big fan of that thinking. THERE IS A LINE IN WHICH THIS IMPORTANT MODULE MUST NOT CROSS, haha. Prioritizing the most important stuff to be higher up the page, sure. Websites don't fold like newspapers.
Plus, we've got viewport units now, so if you absolutely need to position something in the top visible viewport area, you can.
Sorta! It still feels pretty casual to me (let's call my writing medium quality), so it's not like I'm renting a cabin in the wilderness and finding inspiration in the sunsets and cheap whiskey.
I see a ton of cool stuff happening in CSS-in-JS. I think it solves a lot of interesting problems for certain websites. For example, I very much like the idea of having the option to write styles that are scoped to a component programmatically, and thus are tree-shaken when the component isn't used automatically.
But the web is a big place, and dare I say most websites aren't built with JavaScript-powered component models. Thus, CSS-in-JS isn't necessary or appropriate for a lot of sites.
Although, two things to be clear:
The post Clips from my DEV AMA appeared first on CSS-Tricks.
As anyone who has been on the Internet any time in the last decade can tell you, Twitter is certainly a mixed bag. On one hand, it's an absolute cesspool of humanity; but then on the other, it's a magical place full of connection and cat memes.
This latter category is where the following bits of wisdom were found. It turns out, there's a handle entirely devoted to helping developers stay on their game, one inspirational quote at a time. Here are a few of my favorites:
My partner and I ran a design and development conference company for eight years. During that time, we produced hundreds of hours of conferences, both on-site and online. Diversity scholarships were only becoming a typical conference offering around the time we decided to sunset our business. So, when we committed to collaborate on an updated ARTIFACT conference, I knew right away I wanted to make Diversity Scholarships available.
We always worked on making our events inclusive, so adding a program that would enhance that inclusion even more seemed like a no-brainer. When I started to research how to create a diversity scholarship program, though, the only examples I could find were finished programs, and not much documentation about the thinking or planning that created them. It’s not unusual to improvise a solution to a problem and make changes on the fly, in fact it's pretty routine when you run a small business. A diversity scholarship program was something I wanted to get right, though — or at least as “right” as possible — the first time around. I decided to look a little deeper than what was available online.
Tech conference organizers: have you offered diversity scholarships for your events? Would you be willing to answer a few questions about it? PM or @ me if interested. TIA!
Other sentient beings reading this: Can I get an RT to reach as many organizers as possible? Thanks!
— Ari Stiles (@ari4nne) March 11, 2019
Twitter helped me find conference organizers who had created and run diversity scholarship programs. I ended up talking to several organizers about their experiences, in addition to comparing a couple dozen programs and applications online.
There are two types of readers I’d like to address:
So much of the planning for an inclusive conference takes place before you even begin talking about things like diversity scholarships. If your destination city is a relatively inexpensive and easy place to visit; if your venue is accessible and you’ve made plans for accommodations like live captioning; if your ticket prices are reasonable; and if your speaker lineup is genuinely diverse, you’ve got a strong foundation to build on.
Most of this can be accomplished with research. Cities popular with tourists tend to have reasonable transportation and accommodation prices. Cities with big tech hubs often have large, sometimes state-of-the art meeting spaces to hold conferences. Finding cities that have both can be a challenge, but the combination ultimately makes your conference more accessible to different types of attendees.
A little more work may have to go into your speaker lineup. Although there has been some progress on this issue, the majority of tech conferences still mostly feature white men. There have been plenty of articles written on how to create a diverse speaker lineup, but one of my favorite tips is to focus on your conference content first and foremost. Thinking in terms of content makes it easier to look past a potential speaker’s popularity. It also works against your natural bias toward picking “friends” or people you have worked with before. By focusing instead on the content a speaker provides, you can evaluate how that content might add to your overall theme and how it might affect your audience. Curating content is more work than just lining up a group of well-known speakers, but it pays off in the form of a more focused conference and — usually — a more diverse lineup.
You'll also need to encourage open discussion among your co-organizers about diversity issues. My first job in conference planning was for South by SouthWest Interactive (SXSWi), and I feel lucky to have gotten my start working in an environment where these discussions were regular, open, and just “part of the process.” As with any skill, the more you practice talking about diversity, the easier it becomes.
Craft Conference has put together a video about their diversity program. These testimonials may help further the conversation with your colleagues.
Diversity and equity scholarship programs have become popular offerings at tech conferences for many reasons. We need more diversity in the industry, and the current thinking is that more diverse conferences can create more leadership and presentation opportunities for underrepresented populations. Diversity can lead to more robust discussions, too. This goal stated plainly on the Web site for #Perfmatters, run by Estelle Weyl:
"We want to ensure the conversation is stimulating and help everyone see their own Web app issues from new and different perspectives. For that, we need attendees with different perspectives. While we love everyone, conferences where all attendees come from corporations with generous continuing education budgets aren’t as interesting for participants as when attendees represent different work and life experiences."
It can be useful to do a little soul-searching to think about why you and your co-organizers want to do this. “More than anything,” says Tenessa Gemelke, organizer of Confab, “we wanted to remove obstacles, not just check boxes.” It’s easy to tell ourselves that because we’ve recruited a few women or people of color, we’ve “taken care of” conference diversity and we can move on to the next task. The needs of your diversity scholarship recipients are not checklist items — they are the building blocks of a more inclusive community.
Brainstorming a bit about the reasons you want to build a diversity scholarship program can help you set goals, identify problems specific to your target audience, and define limits. You might even discover that you have secondary objectives, which is not unusual.
Justin Reese is the Founder of Code & Supply and co-creator of several conferences based in Pittsburgh, PA. In addition to the traditional uses for diversity scholarships, he and his staff occasionally use scholarship funds to send up-and-coming hometown speakers to other cities. “We want people to see the talent and resources we have here in Pittsburgh,” says Reese. He and his team think of Code & Supply scholarships as a way to showcase local talent and build a robust, diverse tech community in their home town.
At ARTIFACT, we think of diversity and inclusion as the future of technology. So, in addition to building a robust, inclusive community, we see our diversity scholarship program as a vital part of a forward-thinking conference. Techniques and workflow change not only because of new gadgets and platforms, but because of new audiences and different types of teams.
Once you’ve settled on your “why,” it’s best to determine your “what” — as in, what you have to offer. Do you have any resources or perks on hand that will require no help from sponsors? For example, some conferences have more space than they need. Can you give some tickets away for free, or at a discount? Or if you have limited space, can you make a few free or discounted tickets possible by bumping up the cost of your other tickets? Make a list of what you can offer for free or from simple changes to your conference plan.
Other services that you might consider offering through your diversity scholarship program:
Some organizers even make travel and hotel reservations for their diversity scholarship attendees. It makes sense — most conferences already make these arrangements for their presenters, so it’s easy to do it for a few more people. This service may help scholarship dollars stretch a little further too, if the extra travel or booked rooms are available at a bulk discount.
If you want to offer more than just the basics, you will probably have to work with sponsors. The good news here is that sponsors often enjoy investing in diversity initiatives. Before approaching a potential sponsor, though, it’s wise to be clear on how you plan to spend the money. Consider creating a one-sheet that states your goals, the underrepresented groups you are trying to recruit, and what perks the sponsor can expect for participating. This way, you have something to leave behind for sponsors who want to think it over or who need to present the idea to others before it gets approval. Be sure to include your contact information.
It’s useful to think about how many diversity scholarships you’d like to offer in an ideal situation. In practice, that perfect number will probably drop based on your budget or lack of space, but having a lofty goal may encourage you to try a little harder.
Among the conference organizers I spoke with, the number of diversity scholarship recipients ranged from two to fifteen percent of total ticket sales. Those with higher numbers started with higher goals.
Figuring out the logistics of a diversity scholarship plan may be the most complicated part of the process. Trying to figure out how to juggle all the tasks involved is what spurred me to do all this research in the first place!
Implementation will include some combination of the following steps, not necessarily in this order:
Your entire staff may be involved with processing diversity scholarships, but it’s a good idea to have one person oversee the whole program for the sake of continuity. There is a great deal of communication involved with this process, so it helps to choose a point person with strong organization and communication skills. The most significant qualification, though, is a real passion for creating a diverse conference community.
With input from your team, set application deadlines, reviewing deadlines, and scholarship offer deadlines. Every organizer I spoke with suggested making these deadlines early in the process and sticking to them.
You’ll need enough time to review applications and make scholarship offers early enough to give your attendees time to plan. Remember that they might have to request time off work, make family care arrangements, and deal with other obligations. People from out of town need at least two months notice, and international attendees may need three months or more. Early deadlines help everyone. No one in your organization wants to review applications at the last minute anyway, since conference planning gets more intense in the weeks leading up to the event.
Any unclaimed scholarship resources can be used by qualified local attendees in the weeks leading up to your event. Since they don't have to factor in travel or accommodations, it is easier for local attendees to make plans at the last minute.
Devote a page to your diversity scholarship program on your site, then link to that page as reasonably often as possible. If you can‘t list it in your main menu, consider linking it from the site footer and from the ticket sales page, in addition to posting about it regularly on social media.
The list may vary a bit based on your typical audience, but we chose the following criteria:
Be sure to list the types of aid available (determined earlier, when you were “taking stock"). It’s also good to let your applicants know that not every application will be accommodated, and that all applications will be verified.
Most conferences use some kind of online application form to collect and organize data. If you are not able to code one yourself, Google Forms or Wufoo make it pretty easy to build a form. Keep the application as simple as you can — you’ll need:
You’ll want the form to compile data in a way that will be easy to sort through later, like a spreadsheet.
Asking for help in a society that values self-sufficiency over shared responsibility can be tough. Don’t make it harder by asking applicants to divulge too much personal information, participate in open interviews with committee members, or meet with sponsors as part of your program. If a committee will be reviewing applications, consider anonymizing the entries before review.
This should be an ongoing process for several reasons. Some applicants will qualify for your program for reasons that are not always verifiable, so the person doing the vetting may need to contact them and clarify the request.
Other applicants may either misunderstand or overlook your qualifying criteria. The most common mistake many applicants make is assuming they qualify for aid only because their employer won’t cover the cost of the conference. This is where additional information will help: why isn’t this covered? Does the company have very limited funds, or is their travel budget just maxed out already? Does the applicant qualify for a diversity scholarship on other grounds? Applicants should know early in the process if their application is refused or if more information is needed.
Once the application deadline is met, evaluation begins. If your applications have been properly vetted, then the hardest work is already done. If a committee is evaluating applications, it’s good to not only figure out a way to anonymize applications, but also to streamline the evaluation process. Maybe give each committee member two or three questions to rate for each applicant. Possible evaluation questions:
These can be rated on a scale, maybe one to ten, with ten being highest. This makes calculating scores easy. Other data you might choose to consider: when was the application received? Do you want to consider more local applicants than those from out-of-town?
Evaluations have been made, so you are probably left with a set of applicants you want to offer scholarships to, some applicants you are not sure about yet, and a few that you plan to refuse. Start by making offers to those applicants you want to help attend the conference. Clearly state how much help you are offering and a deadline for accepting or refusing the offer.
If you are working with a particularly long waiting list, or the process is going slowly (more than two weeks since you began awarding scholarships), it’s courteous to let people know they are on a waiting list.
At ARTIFACT, we are assuming that some applicants may have a change in plans and therefore may have to refuse the scholarship. In that case, we will be passing along their offer to the next person on our waiting list.
Once all the offers have been made and accepted, it’s time to email the rest of the applicants, thank them for their participation, and let them know they won’t be receiving a scholarship offer. If you can, it’s nice to offer something to those who didn’t receive a scholarship: maybe a discounted ticket if they still choose to attend, or an invitation to any after-hour events, where you have room for a few extra people.
In addition to all the input you sought from your colleagues in the beginning, you’ll need feedback on every aspect of the program. Make that easy to do by including an email address or link to a feedback form on your scholarship description page, your application form, and anywhere else on your site that seems appropriate. Once you start awarding scholarships, make communication a high priority. Consider creating a way to collect anonymous feedback from scholarship awardees and sponsors—easier to do if you have a larger conference—to foster honest, less inhibited comments.
Now that everything needed for your diversity scholarship program is in place, it’s time to follow your plan and take note of what works and what doesn’t. Stay flexible, as you may have to change some parts of your program on the fly. Keep thinking in terms of equity for all of your applicants, and communicate openly about any changes you make. Applicants are more likely to trust a transparent process.
Listen more than you talk. Always.
Once ARTIFACT 2019 has concluded, I’ll be compiling all of our results and feedback in one place and writing a follow-up to this article. Until then, I’d like to thank all the conference organizers who took the time to answer my questions about diversity scholarship programs: Tenessa Gemelke, Estelle Weyl, Justin Reese, Val Head, Dave Poole, Jenn Strater, Ádám Boros, and PJ Hagerty.
In the meantime, here are some other resources you might find helpful:
The post Creating a Diversity Scholarship Program for Your Conference appeared first on CSS-Tricks.
Photo credit by Unsplash/Japheth Mast
It turns out, getting an interview at Google is easier than you’d think. Well, at least if you’re an honest person who knows how to use spellcheck.
Jacob Schatz (@jakecodes) is a staff engineer over at GitLab and was kind enough to share how he conducts job interviews for technical positions and his thinking process for them. Technical interviews are talked about often and can be a touchy subject for some, so it’s worth noting that this article expresses Jacob’s own opinions and are not necessarily shared by his employer.
Are you an interviewee who is terrified, exhausted, sad, or disappointed? I'd love to change that stigma.
I believe that people can have a great interview experience, and that I can simultaneously find the right candidate. Both things can happen at the same time! After your interview process is over, in a perfect world, regardless of outcome, you should feel good about yourself and the process. You might feel sad that you didn't get the job or excited to start your new job, but you should understand why in either situation.
At GitLab, I was put in charge of hiring very early on, and as such, I've seen thousands of resumes. When I first joined, I was asked to hire and form a team of front-end developers. I was employee #29 (we now have 500+), and I was the first front-end developer, so there was no hiring process for our team. We gradually created a process.
This article is aimed at both the interviewee, and interviewer. For the interviewee, I want you to know what a perfect interview can be like. Interviewing should not be scary or intimidating. This is a guide you can follow to do your part in creating the perfect interview. If you are an interviewer, maybe you have perfected your process. This is my view on how interviews can go in a perfect world. There are all different types of interviews, and this article focuses on interviewing developers of all experience levels. Over the years, I’ve latched on to some great processes, and this article is a behind-the-scenes look at that process for both sides of the candidacy.
Before I begin, it's important to remember that everyone is human and humans are not perfect. There are no perfect developers. Treat everyone like a regular human being. It's OK to be amazed at what some people are doing, but not OK to worship others. Talent is both congenital and acquired and you can acquire it too. Your interviewer and you are both imperfect. Interviews should not be focused around perfection. Here's what interviews should be.
The GitLab Values cover a lot of great points and you should read it. This is loosely based on those.
As an interviewer, I can only focus on so many things at once while being a productive, active listener. But I do have five specific things I am try to focus on:
There are other things I'm looking for, of course, but these five things are enough to get you the job you want if you’re interviewing with me.
Forget nervousness. I won't ever hold it against you. I know you may be nervous, and that's totally fine. There is the rare occasion that nervousness becomes a debilitating factor, and in those cases, I just ask that you reschedule. Just don't hang up on me!
We have training on bias at GitLab. One thing I learned from the training is that everyone is biased, whether or not you think you are. At one point, I had the idea of doing blind interviews like they do for some orchestras. We never implemented it (and it would be tough) but that's why I keep a list of questions and a summary of what I want to cover in each interview. Each interview has a script I can follow. Everything is as repeatable and similar as possible. As the interview progresses, I'll be able to tell if I can hit the harder questions. Harder questions are not there to disqualify people, but to qualify people. If you get to my hard questions it means you have a ton of experience and knowledge under your belt. It's really important to know that I must ask trivia questions in some form but I don't qualify candidates based on trivia questions. It's about figuring the depth of your JavaScript knowledge and programming in general.
That being said, there is still one trivia question no one has ever gotten right. I'll just keep asking it, and I am sure some day, someone will get it. Trivia questions are fun, because I am a major JavaScript dork. I just love talking about all the ins and outs of JavaScript. I am looking for people that can be my coding buddy. Hiring people is about finding other people you can work with, not people that will work for you.
Inexperienced interviewers tend to test you on what THEY know (so they can feel a little more secure when they can ding you on an "wrong" answer).
In contrast, great interviewers focus on what YOU know, and facilitating a two-way conversation to explore a mutual fit.
— Jennifer Kim (@jenistyping) April 8, 2019
This may be people's worst fear. The part of the interview where we ask questions like, "Why are manholes round?" The truth is that some companies may ask the medium-to-hard questions from LeetCode, and some may never ask any technical questions.
Experience speaks louder than any technical interview question I can ask. For example, if I'm hiring for a front-end engineering role and someone tells me they built their own cool things that we can talk about, then that's awesome. I still may need to throw some more questions their way after that, or maybe the demo answers all my questions (though unlikely, but possible). But if we can walk through the code of something that you are super proud of, that’s great.
It’s helpful if you can tell me about something that you built for another company where I can see your code, or you can explain it sufficiently enough. What were the challenges? How did you deal with 10,000 comments? How did you deal with mobile? What were some challenges? I'll give you an example: You built the comment system for GitLab. For the comment system, an interesting challenge was dealing with loading users for the @ drop-down to mentioning other users. It turns out that the JSON payload for that drop-down can get quite large and loading it on page load makes the page load significantly slower. But loading that data on the first @ keypress is also slow because the payload can be more than 10 MB. We want the user to have a seamless experience and not realize the data needs time to load. So, a good way to talk about that experience would be to describe some of the approaches you considered, like:
mouseover of the textarea.That last one isn't a boring solution, but is something I've heard someone say in an interview.
Hey interviewers, are you hiring someone for your marketing site? Don't ask them the hardest algorithms and data structure questions. Yes, algorithms and data structures play a huge part in everything, but it's more important that the candidate knows about responsive design, and maybe animations, and performance. Since we are talking about performance, they should know about Big O notation. They should know what causes re-paints. Look at Firefox Monitor and compare it to Salesforce. Everything about the Firefox site is much more snappy. Why is it more snappy? Why is the Salesforce site so chunky and slow? Resize them... oy vey! Big O would probably help you explain some parts, but being able to explain the whole picture is important.
Quick aside on Big O notation since I brought it up.
Big O is a way of describing the time your code will run in and/or the memory space your code will take up in a worst case scenario. I think it's really great to learn, and helps out in every day programming. You can and should learn it, which might take about an hour. After one hour, done or not, you’ll more than likely be prepared for any legitimate Big O question that interviewers would ask.
Big O is not something you need to take a course on. Here are some articles that can explain it to you in under an hour:
OK, back to algorithms and data structures in interviews.
Since there's a chance these types of questions will come up, it's worth doing a little homework in advance. There are two typical gold standards when studying for interviews that ask about algorithms and data structures.
There are many other things that are recommended for algorithm and data structure, heavy coding interviews, but rather than memorizing every example in the world (which won't solve any problems for you), it's better to learn how to solve these problems.
As I said above, front-end engineers should learn Big O for their health, because it's good for you, like eating your Wheaties. Interviewers should not ask extensive algorithms and data structure questions unless the job requires extensive knowledge of them. If I was designing a front-end framework, say like Vue, it would be important to optimize a DOM diffing algorithm or at least understand the implementation of the algorithm you are using. But does that mean I would ask seven extra hard questions from a CTCI? No. You are testing for understanding, not for memorization. When people work through these questions (when I ask them), I want to see that they thought through the problem and we worked it out together more than I want to see that they got the right answer. It's all about figuring out what you will be able to do, as an engineer, when you get the job — not what you memorized yesterday. A person who has knowledge of algorithms is going to be better at implementing them than someone who has to learn them on the job.
Are you hiring someone to build a dependency management system? This person needs to know a lot about algorithms and data structures.
These are two extreme ends of the spectrum, but in my opinion, not everyone needs to know how to write a red-black tree from scratch — but everyone should understand Big O. However, it will dramatically improve your skills as a software developer to learn typical algorithms and data structures.
When I do ask algorithm and data structure questions here are a few I do ask:
Getting these wrong will not disqualify anyone. Remember, I don't use trivia to qualify people.
There are a lot of soft skills I'm looking for as well during the interview. It's my way of determining whether you have a "good head on your shoulders."
Pedantically speaking, that means you make good decisions, but it's much more than that to me. People who have a good head on their shoulders make sound decisions. It's good to have different opinions than me, but there is a standard of knowledge we should agree on. For example, we should all agree that laying out an entire blog with only absolute positioning is a bad idea. That is not a sound decision.
But I might create a scenario like this to check on those skills:
Let's go into CodePen and create a static blog homepage. We'll need a navigation menu, and we'll need a place for the title and article, and then at the bottom let's have some comments and a footer.
I'd then talk you through different ways you could create the navigation and the pros and cons to each. For a lot of the front-end developers I hire, I'd like to know that they know some core JavaScript so I might ask them add some small functionality using only vanilla JavaScript.
When a framework does everything for you, you don't need to do things yourself. I want to know that you get the whole picture.
A “good head on you shoulders" is a fancy way of telling me that you have your crap together. This is not an exhaustive list, but are the types of things that catch my attention:
On that last point: kindness doesn't mean you are a pushover. Kindness is a major part of challenging others and giving feedback.
It seems obvious now, but I am convinced — after working at GitLab — that self-sufficiency is what interviewers should seek in everyone being hired. Self-sufficiency plays a big part in your role in the company.
For example, to go extreme, think about a GM, who may have the least amount of external direction of anyone on a team. Everyone has responsibilities, but a GM must often be good at many things, including (but not limited to) marketing, sales, and management. All this changes based on the size of the team. Their role may be the most vague. They are very self-sufficient. A senior developer (in my opinion) should be able to take on an entire large piece of functionality and implement it properly.
This is not to say a developer shouldn't communicate during the process. They should ask questions, and pair with other people to find the best way forward.
Reviewing an interviewee’s code has the opportunity to be boring (in a good way) as we know what to expect from them. We are relying on them to mentor less experienced developers. Junior developers should be self sufficient too, but probably won't take on large initiatives alone. Junior developers often work great in small chunks. For example, it might be a great thing for a junior developer to take on the smaller tasks that a senior developer has on a larger project. Senior developers can also mentor junior developers and nudge them in the right direction to help them become more self-sufficient, which is a great thing for both parties — and also a great thing for the manager, as they can delegate more work to a senior developer.
If you are a front-end developer and need hand-holding at this point in your career, that is totally 100% OK, and everyone has been there. Or, if you are applying to a lot of places and not getting anywhere, and are extremely frustrated: I suggest that you become a little more self-sufficient before you apply. One way I suggest to become more self-sufficient and nab that job you want: Forget code examples, little shopping cart apps, and their ilk, as they don't fair well for job interviews. Build something full-fledged for someone and do it for cheap or free. Find a church, synagogue, homeless shelter or someone near you and offer to make them a website.
Just remember that free clients are often the worst clients. It will be worth it when you can say that you've done work for a few clients. For bonus points, document your work in a few blog posts. This stuff looks great on resumes and will make you stick out from the rest. I know that anyone can get an easy website through Wix or other site building platforms, but there's nothing like a wonderful custom-designed website. I think I made around 10 or so websites before I had my first programming job. I could fill a book with crazy stories from those times.
This is another point that seems obvious, but is hard to do right. Communication is well documented in the GitLab Handbook so I won't cover it, except to say that I follow GitLab's values and we are looking for others who desire to follow those values as well. Positive and negative feedback is also well documented in the GitLab Handbooks, so I won't cover it here.
Because we interview a lot of candidates at GitLab, we follow a common flow so we can repeat it easily. I won't go into specifics about our interview process, because it's constantly evolving. But, in general, this is the flow I follow.
You'll get asked the famous question that goes along the lines of "tell me about yourself," "tell me what you've been doing," or "tell me about your time at [Company Name]." When I ask this question, I am trying to find the connection between the job you applied for and the jobs you've had in the past. It's good to find the common ground ahead of time.
Like, for example, as an employee of GitLab, if I were personally applying to a FAANG as a front-end engineer, I am sure both GitLab and that company are trying to get page load times to be faster. Maybe I noticed there were 26K event listeners on a page when I first joined GitLab and was able to reduce it down to 0, decrease the loading time by 50%, down to a speed of 200ms. I am sure this would be something relevant to the conversation.
So, as an interviewee, I might say something like this:
"Hi! I am a front-end engineer at GitLab, I've been here for 3.5 years and during my tenure I've made a ton of huge improvements, some of the areas I loved working on are performance, UX design implementation, and architectural design.
You don't want to get into tons of details at this point, but it's good to give the interviewer some facts to work with. It is frustrating when I ask this question and someone goes into a 10-minute detailed account of their entire career.
The interviewer might ask, "What made you decide to apply to our company?" Hopefully, you are excited to work at this company — otherwise, why bother applying for it?
For some reason or another, this question often sends a candidate into overdrive and they wind up mixing up the name our company. That's perfectly normal behavior, especially if your company sounds like another company.
What I'm looking for at this point is to see whether you are just looking for a job or that you’re really excited to work with us. We want people who really want to work with us. This is when I can also see if a person knows anything about our company. For example, some people like our values, have read them and want to work at a company with these values. Some people want to solve big problems like the ones we are tackling. Some people have seen talks and read articles from our team and would love to work around smart people like them.
Lastly, I like to ask if a candidate has any questions for me. This is an important part of the interview, and you should extensively think this through beforehand. Your goal is to make me respond with: “Oooohhh, great question!" On one hand, I am truly trying to answer any questions you have, so don’t be shy. On the other hand, I am also trying to gauge your interest in the job, so something like, “Uh, I dunno," is usually a big bummer to hear because it signals that maybe you’ve tuned out, or the job is not interesting to you. that’s can leave an undesirable aftertaste.
Look up your interviewers and find out about them. Doing this in advance can be an eye-opening exercise. You might find out about their customer acquisition strategy which could lead to a ton of other interesting questions. If the company is a startup, do they plan on being acquired, or do they want to IPO? When you have a clear, well-thought question, it makes you sound professional, which again, is one of the things I listed as important.
If you can’t think of any questions to ask, then do you really want this job in the first place? If the interviewer has a personal website, go check it out, and if nothing else, you can ask them about the comic book they wrote and posted to their website.
But I’d advise:
Don't ask about money or benefits at this point; those things can (and likely should) be covered with a recruiter introduction call before you get to a person like me.
Interviewing, unlike programming, is not an exact science. You’re trying to prove that you are excited about the prospect of working with a company. You want to prove this to the interviewer and yourself. Hopefully, you want a job that is interesting. This guide isn’t a script to follow, but more of a few loose ideas to help you get into the mindset of the interviewer, with a few tips for other interviewers strung in there as well. Maybe I pointed out things you might not have known before.
Just remember that, in theory, interviewing should not be a scary process, but more of a find-some-buddies-to-work-with process.
The post Interviewing for a Technical Position Doesn’t Have to Be Scary appeared first on CSS-Tricks.
Photo credit Flickr/Eli Christman
Can we be real for a second? OK, good. There’s a lot of really terrible advice out there for people trying to get ahead at the office. I mean, so horrific that I honestly wonder if these writers’ editors even read the work before publishing.
Listening to users, stakeholders, and dev team members is crucial for product people. It helps us build rapport, generate new insights, and make inclusive decisions. Unfortunately, we can get so busy updating and convincing others that we forget to attentively listen to the individuals we communicate with. This article shares 12 techniques to help you improve your listening habits and become even better at understanding others.
"Most people do not listen with the intent to understand; they listen with the intent to reply," wrote Steve Covey in his book The 7 Habits of Highly Effective People. It's true: we often listen with a specific goal in mind, with the intention to reply, to share our perspective, or to convince the other person. As a consequence, we don't pay full attention to what the other person is saying or filter what is being said; we only hear what supports our view. We obtain partial or selected pieces of information, which can cause us to draw the wrong conclusions and get the wrong end of the stick. To avoid these issues, start by taking a sincere interest in the individual and what the person has to say. Make a conscious effort to listen to understand, not to reply, correct, or criticize.
"Should I write a book?" Someone asked me this today, and I rattled off an answer.
But as I was doing so, it occurred to me that I get this question frequently. Probably a few times per month, at least. And this makes sense, since I've written a few myself and I'm in the content business. Heck, one of those books has even enjoyed more success, commercially, than I ever anticipated.
There are patterns to bad writing. I'll give some examples based on a blog post I was sent. It's also based — indirectly — on some of proposals I saw for PyCon and PyDataDC.
For the conference calls for papers, I can ask a few questions of the author, but that's about it.