Forem: Jamie Lawrence

Use these “unfair advantages” when applying for a job

Jamie Lawrence — Sat, 11 Apr 2020 22:52:55 +0000

Sometimes you might be lucky enough to be in such high demand that you don’t need any unfair advantages when applying for a job—but even if you’re well qualified, it’s worth making sure you do all you can to get the job you want.

This is especially true for remote jobs which regularly get hundred or thousands of applicants. You’ll need to do something to stand out from the crowds of people applying minimal effort to their job hunt.

Here’s a few “unfair” advantages you can give yourself that I’ve seen work…

To be clear, it’s entirely possible to get a job without employing any of these ideas but you should be aware that other candidates will use them to their advantage.

Make a personal connection

I know, I know, not the “Old boys club” again you’re thinking. Well, not quite. All I mean is that you should, if possible in your application, make known any connection you’ve had with anyone in the company.

“Oh, yes, I met Jason last year at RailsConf”
“I used to work with Andrew”
“I saw the job on Twitter when Jamie posted it”

And, if possible, elaborate on that in a positive way.

“And he seemed really smart”
“And he said how much he is enjoying working at Podia“
“And I really liked what he said about React”

I was even offering calls to anyone that wanted to find out more about the job/company and I they gave me a great initial connection with some of the eventual candidates.

Anything like that helps me understand that you know something about the company, something about the people, and something about who we are. And after knowing that, you still want to work with us!

Use the product

It such a trivial thing but if you can demonstrate that you’ve looked at the product website or, even better, tried it out then it shows a level of interest that’s extremely uncommon. When we get down to making a choice among the last few candidates, you can bet we check the user database to see who has played with the product 😉

Make a video

This is a bit of stretch for most of us but a quick intro video or screencast gives you a huge advantage. It creates that personal connection, letting me hear your voice and thinking and personality which most candidates don’t get to show off until the interview.

One of the most common ways candidates have done this is a screencast to walkthrough some improvement they’ve recognised in the product. It needs to be done subtly and with some humbleness (you never know why it hasn’t already been done) but it’s a great way to demonstrate your thinking.

Making a job-specific landing page

Along the same lines, creating a job-specific landing page with a personal blurb, link to your CV etc is a good way to demonstrate that you’re serious about the job. Just don’t make it too easy to see the other 12 landing pages you’ve created for other companies 😬 (yes, it’s happened)

Show your personality

Are you funny? Are you quirky? Do you have an odd hobby? Been a katana-wielding stunt double? Do you have an obsession with raccoons? Been binging on the Tiger King? Have a favourite GIF collection?

At the slightest opportunity you express yourself! Give the reviewer a chance to say “yeah, I really like this candidate”. In a sea of applications from competent, qualified people, the reviewers will look for anything to distinguish people and your love of cats might just do it.

Don’t be afraid to express who you are. A sterile business-like tone is a losing strategy.

Answer the questions asked

This is seemingly trivial but actually answering the questions that are asked in the application form probably puts you in the top 50% of applicants. Read the question, then spend as long as needed to answer it. Don’t rush, invest the time a new job deserves, and give the best answer you can.

If there’s an open text area, write more. Always write more. The more you write, the more material you’re giving the reviewer to like you and move onto the next stage. You need to distinguish yourself from the hordes of people that are just applying for every job they see.

Photo by Bruno Nascimento on Unsplash

Implementing Impersonation

Jamie Lawrence — Sat, 29 Sep 2018 14:11:00 +0000

The ability to log in as one of your users is one of the highest value features you can develop to support your customers.

The ability to log in as one of your users is one of the most dangerous features you can develop to support your customers.

With that pithy introduction out of the way…

No, actually, let’s back up a minute because I’m not sure that you’ve fully appreciated what you’re about to do: you are creating a security hole in your app.

If your app is Helm’s Deep, then impersonating users is like adding a small unguarded culvert that bypasses the main fortifications. You should expect Orks… and add the appropriate defences.

Still not afraid? Oh, maybe you’ve heard of Facebook? Yeah, this feature you’re about to blithely implement resulted in 90 million compromised accounts yesterday.

So, are you afraid now? Good. You may continue.

There’s a lot of things to consider when implementing a feature like this and the technical details are possibly the least interesting. They also vary considerably between apps, frameworks, and languages.

Technically, logging in as another user is probably as simple as session[:current_user] = user.id or something similar. Whatever. You probably know how this works.

Logging in as another user is not the hard part.

Here’s some more important things to consider:

Do users need to give explicit permission for support staff to impersonate them?
Who is authorised to impersonate users?
How have you authenticated the support staff?
How long does the impersonation last?
How does the impersonator know they impersonating another user?
What unintentional effects do you need to avoid?

Getting permission

This might not be required in every application but if you’re dealing with sensitive or financial data you might need to ask the user’s permission before viewing their account. I’ve seen this implemented by FreeAgent as a special code visible in the user’s settings which must be provided directly to the support staff

The user can also opt-in/opt-out off allowing support staff to access their account.

Who can impersonate users?

This is really an internal company process but you should be clear about who can and cannot impersonate a user, under what circumstances, and for what purposes. You probably want your support staff to impersonate users so they can fix/debug an ongoing issue. You probably don’t want your sales people impersonating users out of idle curiosity.

One feature I’ve previously built is some form of accountability. You might build an audit log in the database recording each time a member of the support staff impersonated a user. Personally, I think audit logs are great for analysing abuse after it’s occurred but do little to act as a deterrent. Instead, I think good behaviour can be enforce by announcing the impersonation publicly — posting to a Slack channel each time some one is impersonated is a simple method of ensuring accountability.

Authentication

Now that your admin accounts are a backdoor to every user account, it’s time to take another look at their security.

First, I think it’s important to have separate Admin and User models as the simplest way to avoid privilege escalation attacks

Next, we should ensure that it really is an admin impersonating the user. But don’t we just check that they’re logged-in as an admin?

Ha! Er… no. What happens if your support staff laptop is stolen? Or they’ve reused a password? You need another means of verifying it’s really an admin user. A sort of second password…a two-factor authentication if you will. 2FA. Top tip: just use https://www.twilio.com/authy to generate and confirm a confirmation code. It’s dead simple and will take a few hours at most.

This ensures that the logged-in admin account is being operated by the member of staff you think it is.

How long does the impersonation last?

A fairly common problem occurs when you impersonate a user on Friday, and then on Monday you open the app and forget you’re logged into that user’s account. Hopefully you realise in time before you do anything too… permanent like send a newsletter out with the wrong account.

A simple solution is to expire the impersonation much quicker than normal session cookies. If your user sessions normally last 30 days, I’d reduce the session timeout for impersonations to something like 1 hour.

How does the admin know they impersonating another user?

Even if you limit the duration, you’ll still want to display some indication that they’re impersonating another user.

In one app, I added a large/prominent ghost 👻 fixed in the left-hand corner which would end the session when clicked. It was a fun but important feature. A banner at the top works just as well

What unintentional effects do you need to avoid?

It’s only after you’ve built an impersonation feature that you discover all the unintended side-effects. Try to shortcut this process by considering where else you send your user information.

Some of my hard-won lessons include:

turn off Intercom when impersonating a user! Otherwise, you’ll send a message and end up it reading it yourself in the impersonated session… and the user will never get a notification!
disable all analytics or you’ll develop a very suspicious hotspot of user activity around your support staff’s location!
if possible, disable user notifications/emails when an account is being impersonated — or remind staff that impersonating a user will still generate emails, notifications, and dashboard events.

Multi-tenant applications

It’s slightly more complex to impersonate users when they’re on different subdomains or custom domains. The basic process isn’t too arduous though:

Generate a secure token attached to the target user’s account
Redirect the admin user to a special endpoint at the correct domain with the token as a parameter (https://mycustomdomain.com/users/impersonate?token=ac8feb1b48fcddfe902814ff342de0d41e80d8d67e56d8182d634dbea1220e92f9dda4b0dbbe902ec460f119a435a684793e844b738529b42d6d60f12736b2f2)
Look up the target user account using the token
Sign them in using whatever version of session[:current_user] = user.id your app requires
Remove the token from the user account so the impersonation can’t be replayed

Recap

So here’s the outline process for impersonating a user:

In your admin dashboard, let staff choose a user account to impersonate
Request a 2FA verification code to confirm the identity of the admin user
Once you’ve confirmed their identity, create the user session. In a simple web app, this might be just session[:current_user] = user.id . Or you might do the more complex multi-tenant dance with tokens and redirects.
Record the impersonation session in an audit log
Notify a team Slack channel with the details of the session
Add a session variable indicating that the account is being impersonated session[:impersonating] = user.id
Display a banner with a warning message, the name current user, and a way to end the session
Disable all user analytics, both javascript and server-side
If necessary & possible, disable user notifications like account activity emails