Back in late May, I went to one of the most informative tech meetups ever. The SFHTML5 meetup group organized an event at the Google SF office to cover web security. Google security researchers presented about 2.5 hours of lectures talking about common hacks/attacks, good defense, and the general state of web security.

You can check out the slides here: click here if you dare. You can watch the lectures here:

But if you don’t feel like sitting through 2.5 hours of lecture, allow me to summarize the best parts:

1. Common hacks/exploits
   • XSS
   • CSRF
   • MITM
2. Simple security best practices
   • Use frameworks/libraries to fight XSS for you
   • Implement CSP to protect your front end
   • Reinforce HTTPS with HSTS

I won’t go into detail about any particular topic. This blog post will simply get you started in understanding fundamental web security. I suggest you use Google to research more about hacks/attacks or wait for me to post another blog post that provides a collection of links to sweet videos, references, and articles that I found particularly helpful for learning more about all these topics.

Be Afraid

How are websites and web apps compromised? Why are sites often “hacked”? There are three main types of attacks that you should worry about: XSS, CSRF, and MITM.

Cross-Site Scripting (XSS)

When a punk manages to get your code to run their JavaScript, that’s XSS. A simple example is when an unprotected website just accepts text from the user and adds it to the site’s HTML code. If that text is actually JS, then the site ends up sending the browser user-generated code. Damn.

XSS is one of the most common problems plaguing web security today. This is pretty depressing because there are plenty of frameworks and libraries that help fight XSS, but so many site operators just don’t use them and some fools even try to write their own anti-XSS code.

Cross-Site Request Forgery (XSRF/CSRF)

Let’s say a user logs into your website or web app. They are now authenticated, right? Well it depends. It could be that the user’s browser is authenticated. An attacker could take advantage of this authentication and get the user’s browser to submit an HTTP request crafted with nefarious intentions. The request will be accepted because the browser has the right authentication cookie data, for example.

How is the evil HTTP request initiated? It could be through XSS, it could be through convincing a victim to visit a malicious site that sends HTTP requests, etc. Most examples mention authenticated cookies being used by attackers.

Man-in-the-Middle (MITM)

There’s a reason why public internet is unsafe. When you’re on a shared network, other users on the same network can try to intercept your data. Not only can man-in-the-middle attacks read your data, they can also send you bad data/code. Some attackers merely intercept web pages you’re accessing, add more advertisements, and feed you the web page with extra ads. Other attackers might intercept your attempt to visit http://www.facebook.com, give you a fake Facebook login page, and convince you to submit your login info to them.

Obviously, protecting a network by requiring a password to connect can help. However, if you’re using public WiFi in a coffee shop where the password is given to anybody who asks for it, then you’re in trouble again. As I shall mention, HTTPS is crucial for fighting MITM pain.

Be Somewhat Less Afraid

It’s great if you’re aware of threats. Now it’s time to learn the basics on how to combat the threats. At the meetup, the Google peeps focused on three types of solutions: frameworks/libraries, CSP, and HTTPS with HSTS. I will also mention a couple other technologies (BONUS) for your consideration.

Frameworks/Libraries Features

One of the Google experts emphasized that XSS is a much bigger problem than it should be because there are so many frameworks and libraries that help fight XSS. He said that no one should be writing their own anti-XSS libraries. Instead, use one of the many open-source solutions. Also, it’s quite possible that you’re already using a framework that has anti-XSS features that just need to be activated or configured.

For example, in some templating libraries, a simple syntax change will enable anti-XSS escaping features. Other templating libraries automatically escape contents by default. Some frameworks like AngularJS do “round-trip escaping on all strings for you” to protect your app from XSS and other injection attacks.

Content Security Policy (CSP)

A server can instruct a browser to use a whitelist to decide which resources should be loaded and which should be blocked. This is done when a server adds a CSP to a response header.

For example, a CSP whitelist can tell a browser to trust script files from the server and Google CDNs, images from the server and Amazon CDNs, CSS files from the server, and web fonts from Google. Everything else will be blocked. In-line JavaScript will be blocked, in-line styles will be blocked, images hosted by 3rd parties will be blocked, Flash will be blocked, iframes will be blocked, etc.

Your CSP can be configured based on various types of resources. Check this CSP Cheatsheet for the list of options. I recommend that you investigate server-side libraries, frameworks, or middleware that can help you implement CSP. When writing your CSP, you can try starting with the most restrictive whitelist and then see what needs to be unblocked.

Reporting Feature

You can also set up a reporting system to find out what your CSP has managed to block (thereby identifying failed attacks).

A Googler suggested using the CSP reporting feature without an enforced whitelist to help you examine what browsers are actually digesting when they visit your site or app. For example, you could set up a CSP that has a whitelist and just asks browsers to report non-whitelisted sources without actually blocking them. This gives you the ability to tweak your whitelist based on production usage without changing production usage. After you’re done tweaking, change the CSP to force browsers to report and block uninvited resources and content.

app.use(lusca.csp({
  policy: {
    'default-src': 'none', // Block EVERYTHING
  },
  reportOnly: true, // Record what's being blocked
  reportUri: '/report-violation-endpoint'
}));

HTTPS and HTTP Strict Transport Security (HSTS)

HTTPS

To protect data transfers from MITM attacks, many sites connect to visitors via HTTPS. HTTPS connections not only protect typical payloads like JSON, but also static files and cookies that would otherwise be vulnerable to CSRF attacks. The hard part about using HTTPS is making sure no part of the site ever falls back to unencrypted HTTP.

For example, let’s say you’re browsing a site that provides free icons and graphics. Are all files served over HTTPS? HTML, CSS, and JavaScript files are no-brainers. What about images? Yeah that’s pretty standard too. But what about when you get an icon pack? You click a download link, and the browser starts downloading a zip file. Is that using the HTTPS protocol? It’s easy to make mistakes.

HSTS

Furthermore, what if a user visits the site using HTTP first? It’s pretty common for people to type “somewebsite.com” in the URL bar and the browser will turn that into “http://somewebsite.com”. After they visit that URL, the site can redirect the visitor to “https://somewebsite.com”. But sadly, that initial connection via http wasn’t secure. It’s susceptible to a MITM attack.

With HTTP Strict Transport Security, the browser can automatically turn “somewebsite.com” into “https://somewebsite.com”. HSTS works by setting a header that tells the browser to enforce HTTPS for requests sent to the domain (“somewebsite.com”) for the next X number of seconds. Yes, you can set X to be a very large number such that HSTS is enforcing HTTPS for the next year, if you want to be cool like that.

Stay Tuned

This blog post was getting pretty lengthy, so I decided to split it into two parts. In a follow-up blog post, I will provide a list of references, tutorials, and videos to help you research more about CSP, HSTS, and some complementary tools/libraries.

Software Engineers are hot shit right now. Recruiters pander to us by calling us rockstars, ninjas, and gurus. We are revered for our intellect, our problem solving skills, our powerful working memory, our familiarity with mysterious tech –but not for our communication skills. Why is this ok? If we’re expected to be smart, shouldn’t we be expected to grasp effective information exchange with fellow humans? Why is modern society still excusing coding “rockstars” from having to come equipped with high quality communication skills?

Photo by Gratisography

How do I know that software engineers aren’t expected to have stellar communication abilities? While I don’t have hard data, I have met, worked with, or listened to a lot of engineers who have sub-par comm skills. And no one makes a big fuss of it, which makes me think no one has high standards for the skills I’m talking about.

On top of that, job interviews target coding skills, web tech trivia, and algorithms with minimal examination of proficiency in structuring arguments, explaining complex concepts, and intelligent discussion. There’s a pretty great article by the CTO of npm that drills into this topic.

Maybe it’s all rooted by the tendency for engineering schools to suck at emphasizing communication in their curricula. My time in college certainly didn’t include any lessons on effective speaking. You often hear schools talk about the importance of group projects and working together, but they never explain what good teamwork looks like, what common pitfalls plague discussions/meeting, etc. Instead, they focus on teaching the hard sciences and math. Then class after class of students walk away with little or no appreciation for the subtleties and subjective nuances of conveying ideas to one another.

I find it so funny that programmers laugh at all these subjective fields of endeavor when that is what they do.

The ability to “work well with others” is often mentioned as a requirement in job descriptions for programming positions, but how many interviewers and interviewees really know wtf that means? Does it mean employees are expected to avoid conflict like their lives depend on it? Is it benchmarked by low quantum of drama? Should it be deeply linked to “likeability”?

No. It’s about empathy, open-mindedness with regards to homo sapiens, and communication skills (among other things).

Who died and made you king of communication skills?

My point is that it’s time to stop letting engineers off the hook for lacking skills in listening, speaking, presenting, asking, writing, and critiquing. I’m no master in these subjects. My own skills are far from honed, but you don’t need to be a master to have some ideas on how to improve. Also, it can be fun to explore communication issues just like how it can be fun to solve mysteries in web app development. Besides, as engineers, we pride ourselves in being good at what we do, so shouldn’t we put some effort into gaining communication skills that make us even better at what we do?

If you’re pondering my motivation for making such a big deal out of all this, then let me just say that impatience is a potent impetus. I started analyzing communication when I started noticing miscommunication and the toll it took on my patience. I’m not just talking about miscommunication during meetings at work. I’m also referring to poor presentations at meetups, chatting at networking events, conversing during job interviews, writing open-source documentation, writing test descriptions, etc.

When I don’t understand someone, I tend to wonder, “Wtf is this person even saying?” Then that little voice in my head chimes in, “Don’t be so harsh, Jeff. Maybe you’re just too dumb to understand.” After that, another inner commentator adds, “Fellas. Shut up. Let’s use our detail-oriented brain to brainstorm reasons why communication has fallen apart here.”

Let’s Do This

We engineers are problem-solvers, right? Well here’s a problem: miscommunication. So let’s solve it. What’s the first step for solving stuff? Comprehend the problem space. Break it down. Then divide and conquer.

Breaking it Down

We’ve confirmed miscommunication. Now what are the root causes? There are too many possibilities to cover now, but here are a few:

• Knowledge Imbalance: Person A knows something person B doesn’t know. The imbalance results in lack of context or incorrect assumptions.
• Ambiguity: Is the person talking about this? Or is the speaker talking about that? What is this? What is that? Maybe we’re referring to different things. Perhaps less ambiguous nouns are needed.
• Suboptimal Terminology: Lack of or misuse of terminology and jargon is pretty common in programming. For example, does everyone know what you mean when you say “collection”? Are you referring to an object literal that has a bunch of properties, an array with a bunch of elements, a MongoDB collection, or a more abstract thingamabob that “collects” stuff?

Divide and Conquer

If X, then Y.

• If there is a knowledge imbalance, then identify who needs what info and let the glorious sharing of knowledge begin.
• If something is ambiguous, then ask clarifying questions.

Et cetera. One at a time. We can get through this together! Let’s hold hands! –or not. Because even the nicest people fail to wash their hands frequently enough to earn hand-holding privileges. Don’t let your guard down.

What’s Next?

The next blog post in my Communication for Engineers series will focus on tips for presenting a tech talk. I’m oddly excited about it. I haven’t done any big tech talks, but I’ve attended plenty. There are some easy ways they could be better. There are common issues that are easy to solve. That said, I’m also working on a blog post covering web security fundamentals. In due time, I will write tips for:

• Presenting a tech talk
• Conversation (with emphasis on listening)
• Asking Questions

If I’m not burnt out from writing about communication skills, I will also blog about:

• Giving & Getting Feedback
• Writing (with emphasis on concision)

End-to-end testing can be pretty tricky. There are a lot of “gotchas” that prove how hard it can be for you to truly think from the perspective of a computer. Ideally, E2E testing is all about writing tests from the perspective of a user, but that’s not going to always provide smooth sailing when writing E2E spec files.

This blog post is going to focus on a gotcha that rears its ugly head when you have a fixed nav bar. Nowadays, it’s pretty common to see fixed nav bars. Let’s use Twitter as an example. Twitter doesn’t use Angular, so you wouldn’t want to test their site using Protractor, but what I’m about to talk about can also be applied to WebDriver (which can be used for non-AngularJS sites).

What’s the big deal?

Here’s the problem: what if we want Protractor to click on the avatar under the fixed nav bar as seen in the screenshot above? Obviously, a human user would intuitively scroll to find an element before clicking on it. However, Protractor’s perspective is different.

describe('"Who to Follow" widget', function() {
  it('should include avatars that go to other Twitter profiles', function() {
    // get first (index 0) avatar using class-based CSS selector
    var avatar = $$('.who-to-follow .avatar').get(0);

    // Will this click always work?
    avatar.click();

    // assertion of what to expect as a result of the click
    expect(blahBlahBlah).toBe(yadaYada);
  });
});

When you use .click(), you might expect Protractor (or WebDriver, which serves as the underlying engine for Protractor) will try to scroll the web page until the target element is displayed before clicking. However, Protractor will only scroll until the target element is in the browser viewport.

Now imagine your test suite includes several tests (ooh la la!). In test #1, the actions of the test cause Protractor to scroll to the bottom of the page. In test #2, the test tries to perform the actions of Example A. Therefore, during test #2, Protractor tries to scroll back up the page until the target avatar is in the viewport, but this just brings the avatar directly under the fixed nav bar.

Then Protractor attempts a click by finding the center of the target. So even if a tiny portion of the avatar’s butt is displayed just below the bottom of the fixed nav bar, it won’t be clicked. Instead, Protractor will throw an error saying that the target could not be clicked. The error will also mention that the nav bar would receive the click event.

Well that sucks. Now what?

There are two main solutions to consider:

1. Un-fix the nav bar for your E2E tests. –Bleh!
2. Add extra scrolling to your E2E tests. –Okay

The first solution might not be a great idea because it’s a major alteration for the sake of testing. What if the fixed position of the nav bar causes other issues that your tests will reveal? I believe you want E2E tests to interact with a product that is very close to the product users will interact with. Changing the nav bar’s position just for testing goes against this philosophy. The main exception to this rule is animation: I believe it’s ok to disable animations for E2E testing just because it can take up a lot of time, slowing down your test/build process. Also, animations can just be very cumbersome for automated E2E systems like Protractor to deal with.

Solution: How to add pre-click scrolling

The solution I use for dealing with fixed nav bars is to define and use a helper function that invokes element.scrollIntoView(false). This method is a native DOM element method that you can read about on MDN. You can’t simply invoke it on a Protractor ElementFinder object. You can’t call elemFinder.scrollIntoView() the same way you call elemFinder.click().

Also, you may have noticed that false is passed into scrollIntoView. This tells the browser to scroll as far as it can in an attempt to align the bottom of the target element with the bottom of the scroll area. In other words, this solution only solves issues with fixed nav bars at the top of the viewport. Using element.scrollIntoView(false) will fail if your web app uses a fixed nav bar at the bottom of the viewport.

// Inside a separate JS file that contains helper functions...

// Syntax Option 1
function scrollElemToBottomOfView(elem) {
  elem.scrollIntoView(false);
}
module.exports.scrollElemFinderIntoView = function(elemFinder) {
  var promise = browser.executeScript(scrollElemToBottomOfView, elemFinder);
  return promise;
};

// Syntax Option 2
module.exports.scrollElemFinderIntoView = function(elemFinder) {
  var promise = browser.executeScript(function(elem) {
    elem.scrollIntoView(false);
  }, elemFinder);
  return promise;
};

// Syntax Option 3
module.exports.scrollElemFinderIntoView = function(elemFinder) {
  var promise = browser.executeScript('arguments[0].scrollIntoView(false)', elemFinder);
  return promise;
};

There are 3 syntax options above because I just wanted to present a few different coding styles. As you can probably tell, browser.executeScript() accepts a couple of parameters. The first one is the script, the second one is the script’s parameter. The script can either be a function (technically speaking, it’s a function reference) or a string representation of the script’s body. Syntax Option #3 was inspired by a Stack Overflow answer for a very similar situation (it was for WebDriver, but it was easy to translate to Protractor).

// Somewhere inside test code...
var helpers = require('../path/to/helpers');
helpers.scrollElemFinderIntoView(avatar);
avatar.click();

You may have noticed that the solution in Example B mentions promises, but the code in Example C does not use them. My understanding is that it’s not crucial to use every single promise that Protractor and WebDriverJS provide. For example, even though the .click() method returns a promise, you don’t see devs writing Protractor tests with exampleButton.click().then(function() { ... }); all the time.

So why did I mention promises in Example B? Just to reinforce the fact that browser.executeScript() will return a promise. By storing the result in a variable called “promise”, it tells other devs what to expect. That said, I admit it may not be terribly valuable. Let me know your opinion on this or any other part of the solution presented here.

If you find the right job, you can feast your eyes on sweet code and palm trees.

In my previous post, I described my experience using LinkedIn, Whitetruffle, Hired, and Dice. This time around, I’m going to cover a crop of sites that I used less extensively. Although they didn’t yield fruitful leads, they’re still pretty interesting to me, and with job searching, you can’t not explore more than a few avenues.

Job Sites and Search Tools

Readyforce

• The gist: Job board for entry-level opportunities (mostly for recent college grads)
• My experience: I only browsed Readyforce for a bit
• My recommendation: Give it a shot, but keep expectations low if you’re not a recent college student.

The Readyforce website has undergone a big redesign since my job searching days. I was originally drawn to the site by its large selection of companies listing their open positions. However, the site is clearly marketed towards college grads, and the creators want job seekers to “connect” with employers through their own social(?) network.

When I visited the site a few days ago, it looked quite different. While it does look cooler nowadays, it also feels buggier. On top of that, there doesn’t seem to be a clear way to apply for jobs. Maybe I just don’t understand their model, or more likely: maybe I have to register an account first.

The Muse

• The gist: Job listing featuring “rich media”
• My experience: Browsing The Muse was so fun that I even signed up for the email newsletter.
• My recommendation: Must visit! The site does a fantastic job of profiling each company. Their email newsletter does a pretty bland job of standing out from other self-help resources.

I love what The Muse is doing. Muse peeps travel to employers’ offices to take professional photos and record video interviews with current employees to highlight the benefits of working for the employers. It’s great to see photos of cool offices, and although the videos have mediocre audio/visual quality, they still provide some decent insight. The end result is that The Muse feels like a portal for quick tours of hiring companies. I felt like I was getting a fun, behind-the-scenes look at a bunch of tech jobs rather than just browsing endless, cookie-cutter job descriptions like you do with most other job sites.

During my first few visits to their site, I was so enamored with The Muse that I signed up for their email newsletter. That’s right, I actually wanted their spam. Sadly, their emails are pretty lame. Each message uses a click-bait subject line like “This Genius Formula Can Tell You Your Dream Job”. Opening one of these emails just reveals a giant button to take you to their blog where the short articles don’t live up to the hype of their titles/headlines. By the way, the “genius formula” is gifts + passions + values = your calling. Genius.

The Sourcery

• The gist: Recruiting firm that actually lists job opportunities on their site.
• My experience: I talked to a couple of their recruiters, and I got minimal results.
• My recommendation: I’m not a fan.

You can find a lot of job postings on The Sourcery. The companies that use The Sourcery for recruiting will often post on other job sites, but there will be a note at the bottom of the job description that mentions the requirement to apply via The Sourcery. After filling out a job application on The Sourcery, one of their recruiters will let you know whether or not your candidacy will be pursued.

For me, the problems come from the recruiters. They noticed I was a Hack Reactor grad, and they immediately labeled me as just another coding bootcamp grad –in a bad way. Although they were friendly, the recruiters implied that all coding bootcamp grads are the same, that they’re all “great” junior-level coders, and that they all can’t handle more than the average entry-level job. What’s really weird is that I would get emails from some recruiters telling me that my job application was rejected due to a lack of work experience, but then other Sourcery recruiters would contact me and tell me that they want to interview me for the exact same job. Maybe the recruiters reach out to rejected applicants if the pool of applicants is running low for a particular job.

Obviously, The Sourcery is not the only company that treats bootcamp grads as low-level programmers. This is why Hack Reactor doesn’t want you to talk about them during interviews. It’s also why Hack Reactor avoids calling itself a bootcamp. I’m getting off-topic, but the gist is: the bootcamp market is getting bigger, and the quality is very inconsistent. Consequently, the mediocre bootcamps are hurting the reputation for all bootcamps. The Sourcery’s expectations for bootcamp grads have already been adjusted downwards.

AngelList

• The gist: Networking in the startup bubble.
• My experience: I hit the “I’m interested!” button several times without much luck.
• My recommendation: Meh. It’s easy enough to use, but results will be hit-or-miss.

In my last couple of weeks at Hack Reactor, I was instructed to make sure I had 3 online profiles ready to show off: LinkedIn, GitHub, and AngelList. The nice thing about AngelList is that you’re more likely to get in contact with an in-house recruiter. You don’t have to go through 3rd party recruiters. The bad thing about AngelList is that you might not get in contact with any one. When I say it’s “hit-or-miss”, what I mean is that I know some colleagues who were contacted via AngelList by several companies, and I know other colleagues who were getting zero interest. There was no apparent reason for the two distinct outcomes.

I was only contacted by a few companies via AngelList, and I wasn’t too interested in them. There are plenty of startups on the site, and if you’re hoping to join a tiny company, you should at least try to use AngelList.In my experience, although some companies reached out to me, none of the contacts yielded real conversations about interviewing. Also, there are a ton of companies that don’t distinguish themselves (i.e., there are a ton of startups in the advertising industry –and their profiles look too similar).

VC Sites

• The gist: Easy way to discover jobs (but doesn’t make applying to jobs any easier).
• My experience: Lots of browsing filled me with hope.
• My recommendation: Definitely worthwhile, but it’s going to require plenty of effort.

Many moons ago, a ridiculous fellow Hack Reactor grad pointed out that Venture Capital websites tend to have giant lists of job openings for their respective startups. I eventually validated his insight for myself by checking out job lists maintained by:

• Spark Capital
• Accel Partners
• Kleiner Perkins

You can find a huge number of jobs. It definitely helps keep your hopes up, knowing that if you fail a job interview, there are so many other jobs to go for. But the caveat to remember is that these job postings are just like any other: it’s hard to get noticed when applying for a job without a referral/connection. For smaller companies, you have a much better chance, but overall, you will have to apply to a lot of jobs just to hear back from a couple employers. Like with all job openings, I recommend putting in some extra effort by checking LinkedIn (or maybe other social networks like Twitter?) to see if you can contact the employer’s engineers, hiring managers, and/or in-house recruiters.

In other news

I’m exicted to start a new series of blog posts covering various tips, tricks, hacks, best practices, puzzles, challenges, questions, and mysteries (both solves and unsolved) that I’ve encountered at work. This “Learned On The Job” series will be arriving shortly!

That said, I haven’t finished writing about what I learned from the job search process. More job hunt-related content is still to come (including “WTF moments” :D), but I want to mix things up a bit too. After all, talking about software engineering is more fun than talking about searching for software engineering jobs, right?

“Will Decorate Eggs For Food” by Gratisography.com

Back in December of 2013, I graduated from Hack Reactor. After graduating, I started casually looking for a job, but due to the winter holidays, I didn’t start searching in earnest until early-to-mid January. In hindsight, perhaps I should’ve spent less time searching by myself and more time using Hack Reactor’s network/connections. That said, Hack Reactor encourages grads to look for jobs using all sorts of resources, and I benefited from other forms of job search support from the HackR staff.

This blog post covers a bunch of online resources I tried out myself. I ultimately found my current job through a recruiter, but that doesn’t mean that job sites felt useless to me. Therefore, I’m happy to share some opinions and experiences with you. Maybe you’ll have better results. At the very least, job sites showed me just how many awesome jobs are available, which kept my spirits up during my battles with job interview stress.

Job Sites and Search Tools

Whitetruffle

• The gist: Employers and job seekers are matched using a system akin to online dating.
• My experience: I only tried out Whitetruffle for a few days. I revisisted sparingly.
• My recommendation: Thumbs down. I see potential for the site, but for now, it’s lackluster.

It feels a bit hollow. Much like with online dating, everyone makes a profile. Companies look at job seekers’ profiles, and job seekers like you can look at companies’ profiles. There are Like buttons to express interest. Mutual interest leads to a match. A match leads to an email notification. An email notification is supposed to lead to a conversation or some sort of initial phase of job candidacy…right?

You are also given notifications when an employer says they like your profile. The site will nag you to respond to the employer. However, in my experience, employers didn’t respond after I indicated mutual interest. Boooo! This made me wonder if employers just click the Like button on every profile (i.e., spamming) in hopes of stirring up job seeker interest.

Hired

• The gist: “Auctions” occur regularly. During auctions, employers “bid” on you.
• My experience: I went through a couple of auctions, which resulted in a few on-site interviews.
• My recommendation: Thumbs up. I will explain some shortcomings, but overall, Hired is looking good.

Hired is quite an ambitious setup. Job seekers must pass a few coding challenges to enter their pool of candidates, but when I joined, the site hadn’t yet implemented the challenges, so I was able to join after my profile was approved. Hired must have convinced employers that their candidates are top notch because employers were “bidding” salaries between $105,000 and $130,000 on me.

Misleading, but worth it?

However, the auction format is quite misleading because it implies that you must accept the highest bid. It also implies that employers must hire you and offer you whatever they bid. This is not the case. There are no strict obligations. You must still pass whatever interview process employers have. Employers can still ultimately reject you. Employers can offer you whatever salary they want to offer you if you pass their interviews. In other words, Hired simply uses an auction format as a gimmick to get people excited to participate. It’s a trick, but I’m not even mad.

Why not? Because the pool of employers on Hired is pretty darn good. I got serious interest from 5+ companies. I got multiple on-site interviews. I got two offers. Plus, if you get a job, Hired will give you a $2,000 bonus. Awesome, right?

Now it’s not all rosy. Some companies that were interested in me seemed really boring. The companies that gave me offers both offered me salaries below their respective bids. In the end, I didn’t accept any job offers because I didn’t think I was going to fit well within the companies or something irked me about the company. I should also note that Hired “provides” you with an “advocate” –in less disguised terms, Hired assigns a recruiter to you. The recruiter will call you pretty often to help plan interviews and to eventually nudge you into accepting an offer. If this sounds potentially annoying to you, don’t fret because I’ve dealt with many recruiters, and my Hired recruiter was definitely one of the nicer ones (my only beef is that the recruiter would sometimes call me in the morning when I was sleeping in late).

Caveat: some of my friends used Hired, and they didn’t have a great experience. For me, the only real bummer was when Hired stopped including me in auctions. I think I may have disappointed my “advocate” by not accepting job offers, and I may have reacted poorly to the recruiter’s nudging because at the time, I thought it was a bit too much. Little did I know that he was far less pushy than most recruiters.

Dice

• The gist: Generic job board with a reputation for being stalked by recruiters.
• My experience: I put my résumé on Dice and within 2 days, I was receiving tons of emails from 3rd party recruiters and head hunters.
• My recommendation: Thumbs up. Dice is effective, but you will NOT enjoy the experience.

Dice is an ugly site that is incredibly helpful in a painful way. First, I created a résumé specifically for Dice. What does this mean? Dice is for when you WANT spam from recruiters. Dice is for when you want to turbocharge your job search. Dice is for when you’re finally ready to destroy your fear of sharks, so you jump in a shark tank with craploads of bleeding tuna attached to your wetsuit. Do you get the picture, or must I throw more ridiculous warnings at your eyes? You must be mentally prepared to be inundated with contact from recruiters. They can sometimes be…unpleasant.

The onslaught of recruiter spam arrives from Dice because your profile is public. Your profile is rather pointless except for the résumé part of the profile. This means that your résumé has to be public, so it’s a good idea to upload a variant that excludes your contact info. Recruiters will check out your résumé and contact you via Dice messaging (which gets sent to your email). You then respond to recruiters, and work with them to get interviews and get hired. It’s a very clunky process. I could rant for several more paragraphs on the downsides of working with recruiters. However, it can be worth it. I’m very happy at my current job, which I earned through a recruiter.

LinkedIn

• The gist: Networking, stalking, and head hunters.
• My experience: Messaging through LinkedIn actually helped me. Also, I got the feeling that employers/recruiters viewed my LinkedIn more than they read my actual résumé.
• My recommendation: Thumbs up. Linkedin is overrated, but it’s versitile and omnipresent.

I didn’t get a ton of recruiters reaching out to me via LinkedIn. It can’t compete with Dice in that department, but at least with LinkedIn, you get contacted by in-house recruiters, not just 3rd party recruiters.

That said, after I got a job, I updated my LinkedIn profile to show my new gainful employment. Consequently, I’ve been contacted by recruiters at least a few times a week even though I’m not actively trying to get a job. In other words, the recruiter “spam” really only pours in if you’re currently employed (or experienced).

Other Uses

Not to give false hope, but you may want to consider paying for a LinkedIn pro account. This lets you send a few messages to people you’re not connected with. I used this feature to contact executives and engineers at a few companies I was interested in. A couple of folks at one company actually replied to my messages, in which, I sincerely gushed about the company (and bragged about my 1337ness of course).

Quick Aside: “Unique” résumés and cool profiles

I consider my LinkedIn profile to be a way for me to show off a bit of my personal style. Some people try to be edgy or unique by formatting their résumés in a different way, but I’ve heard that’s actually a bad idea. Not to mention, a lot of people just don’t come up with good designs. Some do, but plenty don’t. Besides, résumés need to be easily skimmed by human eyes and easily scanned by software. After I got hired, I switched from being a job seeker to being an interviewer within my first week at the company. I saw over 10 resumes and sadly, the bland-looking ones were generally easier to skim. The uniquely formatted ones showed good intentions, but poor execution. You should think twice before you use bombastic fonts and lighter colors.

Oh! Back to my original point: I use my LinkedIn profile to demonstrate a bit of my personality through writing style –not through formatting (although I do add bullet points because their text organization powers are un-friggin’-paralleled). In fact, for pretty much any job site that required me to create a profile, I put in quite a bit of effort to write something actually interesting. It can be difficult to flex creative muscles for such tasks, but I believe it’s worth it to prevent your profile from being read with the same dry tone as every other candidates’ boring dossier. If you have 5+ years of perfectly relevant skills, then you can probably write a profile devoid of personality/creativity, and you’ll still stand out as a stellar candidate. Hooray for when that day arrives.

Stay Tuned

Check back (somewhat) soon for more opinions and anecdotes on software developer job search sites. In part 2 of this Dev Job Searching Tools Roundup, I will ramble about Readyforce, The Muse, The Sourcery, AngelList, VC job listings, and more.

In future blog posts, I will cover other software engineering job hunting topics. I’m particularly excited to discuss my impressions from the other side of interview process. Also on my to-blog list: inheritance in JavaScript and lots of AngularJS best practices / app architecture patterns.

Author of Cracking the Coding Interview, @gayle , talking to @hackreactor pic.twitter.com/aVbcohgqSG

— Jeff Lee (@RebootJeff) January 16, 2014

In a previous post, I mentioned that attended a talk given by Gayle Laakmann McDowell when she visited Hack Reactor. She’s the author of the famous Cracking the Coding Interview, which is a book that helps developers perform better when interviewed for a new job. Her text mostly focuses on algorithm challenges, but there’s also a lot of content that has more to do with coaching up interview candidates.

I really liked McDowell’s presentation at Hack Reactor. There were plenty of intriguing anecdotes, and of course, there was plenty of good advice. Plus, she included a lot of insight into the hiring process. Many of her stories and comments provided the Hack Reactor community with a “behind the scenes” sort of perspective.

Keep in mind that she worked for companies like Apple, Microsoft, and Google, so her advice comes from the perspective of giant companies. I doubt her tips apply equally to smaller employers. For example, McDowell heavily emphasized the importance to study certain algorithms (e.g., various sorting and searching algos) and data structures (e.g., trees, hashes, etc). In my experience mostly interviewing with smaller companies (fewer than 500 employees; as few as 5 employees), studying textbook algorithms and data structures wouldn’t have helped me as much as studying more web-specific skills.

That said, I still want to share some of the more interesting takeaways from McDowell’s talk.

Interviewers’ Process / Employers’ Perspective

• Your performance is evaluated relative to other candidates (so you’re not just being judged based on fixed benchmarks).
• Resumes are barely read. You must make yours easy to skim within 15 seconds.
• Unless it’s a warm-up question, you are not expected to get the solution right away.
• Employers judge your GitHub and public repos based on coding style (do you violate any major no-nos?) and use of design patterns. They don’t have much time to judge app architecture.
  • My 2 Cents: Perhaps this falls under “design patterns”, but I would like to add that there is time to judge your use of a framework. If the employer is familiar with the frameworks you used, they will notice when you fail to follow the framework’s more important conventions. For example, for AngularJS apps, I will notice if you put too much logic in the views, if you abuse $rootScope (which is akin to relying on global scope variables as a crutch), if you create bloated controllers, if you lack services/factories/providers, etc. I will be extra happy if I see you use multiple modules, if I see tests, if I see usage of Angular best practices, etc.
• Only the interviewer knows how well you did in the interview. You may think you aced it. You may think you bombed it. But you don’t really know.

When I was at Google, I referred a number of candidates, and ran a little (informal) experiment. How well could people judge their performance?
After each candidate completed their interview, I’d ask them how they did. Then, I’d look up their actual performance. And guess what? There was no correlation. None. Zip. Zero. Zilch.

Interview Coaching / Advice

• When answering a behavioral/experience question, you should tell a story. Your story-telling should use the following format: Premise, Situation, Action, Result. The “premise” is a quick, 1-sentence intro like “One time, I had to do X for an app.” The “situation” is the context of your story. The “action” and “result” are pretty self-explanatory. I imagine Laackmann’s motivation for this advice is that interviewees usually leave out at least one of these four parts when discussing valuable past experience.
• For each major experience you include on your resume, you should be prepared to discuss what you liked, what you disliked, what was challenging, and how you solved difficult problems/bugs.
• Always follow up with interviewers afterwards. Send them thank-you emails and ask about next steps.

What to Worry About

• Your conversational skills don’t need to be great because employers are desperate for technical skills.
  • My 2 Cents: I think this is dangerous advice. It might apply to a giant company, but if you’re joining a smaller team, you need to be decent at chatting. Culture fit is also a bigger concern for smaller companies, and most company cultures include “must be decently articulate” as a core component.
• Worry less about super advanced algorithms, but you should worry a lot about the common algorithms and data structures such as: hashes, trees (and common tree methods such as depth/breadth-first search), binary search, merge sort, and quick sort.
  • My 2 Cents: I disagree. If you’re aiming for a back-end job, then maybe you need to be more of an algo+data structures expert. But if you’re aiming for a front-end or full-stack job, then there are more practical concerns that you will be quizzed on. I’m happy I know tree search methods, but this kind of knowledge only helped me in a few of many interviews I did during my job search. This topic of “advanced algorithms vs practical concerns” is commonly debated, but I have my reasons, which I hope to discuss in a future blog post. For the record, I’ve conducted interviews at my current job. I ask practical questions that most candidates struggle with.
• You must know Big-O, recursion, and maybe even bit-wise.
  • My 2 Cents: I disagree about the bit-wise stuff (although, I suppose it’s impressive if you can bust it out with ease).

Whiteboarding Tips

• If you are asked a trivia question, and you don’t know the answer, consider reasoning the answer by imagining how things should work. For example, if asked a question about CSS, imagine you created CSS. How would you implement a given rule?
  • My 2 Cents: This one’s iffy because a lot of trivia questions are meant to focus on unintuitive situations. A quick aside for a quick example: margin collapsing. If there are two sibling <div> elements, and they both have margin: 10px;, then how much space is between them? You’d expect there to be 20px of space between them, but instead, there is only 10px thanks to margin collapsing.
• When solving an algorithm question, come up with some test cases (including edge cases!).
• Think out loud when trying to solve an algorithm question. Don’t just write code.
  • My 2 Cents: As someone who has interviewed dev candidates, I can’t stress this enough.
• When whiteboarding, be conscious of your handwriting, alignment, etc.
• It’s ok to…
  • start solving a problem via pseudocode before writing real code. Just let your interviewer(s) know your plan.
  • write TODO comments in your code for important-but-tangential stuff like input validation
  • create proper variable names at first and then switch to abbreviated versions
• Use “breadth-first coding”: write your code to use helper functions that may not exist. Write the helper functions later as needed. Think of it like writing an outline before writing an essay so then other people can quickly get a grasp of your overall approach rather than waiting and awkwardly watching for several minutes while you write out everything.
  • My 2 Cents: This sounds like a no-brainer, but you’d be surprised how many people don’t do this. To be fair, this is like writing modular code BEFORE refactoring.
• Beware of common bugs you might make regardless of how awesome you are. Examples:
  • off-by-one errors
  • bad comparison operators in if-statements, loops, and other conditionals
  • math where you must perform a check before performing the operation to prevent edge cases from making your program explode. E.g., it might be good to perform a check before performing division so then you stop divide-by-zero errors.