How To Transfer To Another Role Within Your Company


You’re in a company you love, with a great culture and enviable perks. There’s just one thing–your dream job isn’t what you’re currently doing. In fact, it involves working in another department.

I’ve been there. In the four years I’ve been at Dropbox, I’ve had four different roles, from customer service to product manager–successfully working my way into a technical role despite not having a technical degree. So I’ve learned a thing or two about how to set yourself up for success when you want an internal transfer, whatever your company policy on it may be. Here are my recommendations.
Your current role might have nothing to do with the job you really want, but the first step to a successful transfer is to be really good at your current job.

This goes beyond delivering excellent results–it’s important to maintain a positive attitude about what you’re currently doing, even when you’re not 100% excited about it. That being said, if you’re looking to move into a different function that requires an entirely different skill-set, you also need to show you possess those abilities already. How? Take on a couple projects that are relevant to your desired role to showcase what you can do.

Before I made the jump from customer service to business development, I took on extra work to help resolve customer issues related to our partnerships. I became an expert in the product and technical details of the product integrations we had with our partner companies. As a result, the business development team included me in their conversations with partners, and I helped negotiate and resolve the technical aspects of our partnership deals.

So when I formally pursued the move to join the business development team, I’d already established that I had the skills to do the job.

You (and only you) own your career. Yes, you’ll need others to help you get ahead, but chances are no one’s going to find, evaluate, and secure that next role for you.

If you want to pursue internal opportunities, make that known–tactfully and gradually. The best way to do that is through regular career conversations with your manager. Don’t just chat about your current workload. You should also let your boss know which types of skills and experiences you want to develop. Again, it’s your responsibility to get onto the same page with your boss on what you want for your career. In fact, you should be having periodic career check-ins anyway–even if you’re happy in your job and don’t want to move. If you’re not doing this already, start immediately.

This way, if and when an internal transfer opportunity comes up, it will be easier to find the right time and way to bring it up with your manager. Beforehand, do your due diligence: ask HR about any internal transfer policies to make sure there aren’t logistical barriers. For instance, some companies require you to be in your current role for at least one year before being eligible to move into a different role.

Depending on your relationship with your manager, it can be scary to initiate this conversation, and you might have to navigate some internal politics. But at the end of the day, if you don’t advocate for yourself, you won’t get too far.

Finally, you should consider looping in an ally in your organization who can serve as a career advocate. This should be someone who’s familiar with your work, and with whom you have a strong working relationship with based on mutual respect. Ideally, they should be able to talk about the quality of your work, vouch for you as a teammate, and give examples of how you’ve gone above and beyond your job description to help others.

Having a strong advocate internally can make a big difference when it comes to a hiring manager taking a leap of faith on you–especially if you’re going after a stretch role. Of course, you have to put in the work to earn their respect, and make it worth their while to be your career advocate in the first place.

If you love the company you work for but aren’t fully satisfied with what you’re doing–an internal transfer can be a great way to move forward in your career. However, you’ll need to be willing to put in the work to get there–start with these three things and you might just reap the rewards.

This article originally appeared on FastCompany.

About HackerTrail

HackerTrail is a curated marketplace exclusively for IT talent ranging from developers to infrastructure specialists to data scientists. Using clever technology and gamification, HackerTrail connects the right candidate to the right job opportunities with top companies across Southeast Asia.

Looking to switch jobs? Find out which companies are currently hiring and get shortlisted for interviews now on

7 Key Steps to Getting Your First Software Engineering Job

I graduated from a web development bootcamp in 2017. I had no experience working as a software engineer or in the tech industry. I started applying for jobs in October and began working full-time as a Front End Engineer in December.

The job hunting process was a short but stressful 5 weeks for me. There were things that I wish I had known, and other things that paid off way more than I expected. To save you a lot of time and stress, I’ve distilled what I’ve learned into seven key things I did to secure my first job.

1. Make a portfolio of a few standout projects
I’ve reviewed the resumes of other bootcamp grads where they only listed one or two partially completed projects. They don’t have to be perfect (my glitchy Phaser.js game isn’t), but they should show the progress you’ve made as a software engineer.

This means if you say you know React, you should have at least one React app in your portfolio. If you don’t have work experience as a developer, a portfolio of at least three projects is critical. These also shouldn’t be tutorials — get creative! The more fun the project is to you, the more work you’ll put into it. And the more passionate you’ll sound when you describe it to your interviewer. (Bonus points if you make your own portfolio website too!).

You should also be ready to discuss your project’s strengths and weaknesses with an interviewer. Several of my interviewers pulled up my Github and asked me to walk through my code with them. I definitely fumbled the first time this happened, since it had been weeks since I had looked at the code! Preparation is key.

Afterwards, I made sure I could navigate around my projects on Github and could talk about one tough challenge I solved in each project.

On the topic of Git, all my interviewers were impressed that I had experience using Git for version control and collaboration. I recommend familiarising yourself with Git + Github. If you’ve never used Git for team collaboration, I would definitely recommend making your first PR to an open-source project. Good Git habits also go a long way. One of my interviewers just stepped through my commit history to see how I “think,” and I was very glad it was a project with good commit messages.

2. Prepare for the technical interview

Image from Unsplash

There are lots of problems with the way tech interviews are done, but the fact is that for many companies white-boarding is here to stay. There are tons of great resources out there to practice this (Pramp, InterviewCake, and of course Cracking the Coding Interview to name a few).

I have to confess that I struggle with this a LOT — my mind tends to go blank under pressure. But the most important thing is that you practice thinking out loud. Complete awkward silence during an interview is the last thing you want, and the more you think out loud, the more the interviewer will know how far you’ve gotten (and be more able to help you, if they’re so inclined!).

I also just bought a whiteboard and dry erase marker so that I got used to working without a code editor (trust me, it’s jarring going from coding with the aid of a linter to a blank wall!).

Not all companies will ask you to whiteboard — but almost all will ask you some basic technical questions, which I call “trivia” for lack of a better term. For the positions I applied for, these questions usually focused on HTML, CSS, JavaScript, and web performance. There are also lots of online resources out there with lists of common questions — I just made a bunch of flashcards and practiced!

There are few topics with which any front-end or full-stack web developer should be comfortable. These include the event loop in JS, promises and async/await, the CSS box-model, CSS specificity weights, and ways to speed up the loading times of a web page. I’ve been asked questions about all of these more than once.

3. Define what kind of company or role you want

Image from Unsplash

In the beginning of my job search, I made the mistake of casting a very broad net, with a “beggars-can’t-be-choosers” mindset. But no matter where you land, you’re going to be devoting the majority of your time to work. What’s the point if you can barely muster any excitement about going to the office, or worse, dread it?

Making a list of priorities for your new job will help you a TON in staying in charge of the job-hunt, instead of letting the job-hunt run you. My top priorities were:

– Opportunities to solve challenging problems that interest me
– Good work/life balance
– Opportunities to work with a modern tech stack

These priorities led me to focus on jobs at companies where there was a healthy work culture (no working nights and weekends). I also wanted to used modern frameworks (sorry jQuery). They also had to have interesting missions that I could get behind (no thank you soulless corporations).

Also, remember that interviews are not just a time for the company to evaluate you. Often you’ll be able to find warning signs if the company is toxic or not a good fit. I encountered one company that issued a long coding challenge before even talking with candidates. Another company was working on a fascinating product, but my interviewers bristled when I brought up work/life balance. I could go on and on about all the warning signs I experienced.

Always, always ask questions during interviews. It shows that you are serious and interested, but can also help you detect these warning signs.

4. Stay organised and track everything

You have some killer projects under your belt, prepped for the technical interview, and have a target company in mind. Now it’s time to start applying for jobs. But holy moly, keeping track of dozens of applications can be a nightmare! I used to keep applications in folders on my computer, but it got unwieldy and cumbersome.

I ended up using Airtable instead to track all my applications. I used it to track the job listings, cover letters, any email or written communications, salary ranges, contacts, meeting logs, and more.

Here is a link to the template I used. (For all non-spreadsheet nerds out there, Airtable is like the love child of an Excel spreadsheet and a relational database.) One thing I love about Airtable is the ability to link between records in different tables. This allowed me to keep a thorough list of company contacts and individuals on the “People” page, and companies on another.

But why bother staying this organised?? Besides satisfying my love of spreadsheets, it makes it a lot easier to pinpoint strengths and weaknesses in your job search strategy.

For example, here is a breakdown of the state of my job applications after I had gotten the job:

Out of the 40 applications I sent, I received no response from ~50%, and job offers from 20%. Not bad considering the shot-gun approach I had for sending out applications. But, still not as high as I would have liked.

But if we take a look at the jobs that I had an opportunity to interview for:

Things look a lot better. I have a 50% offer rate. For a quarter of the jobs I interviewed for, I was still between rounds of interviews when I accepted my job offer. So they also might have turned into offers if I continued interviewing with them. I was only rejected by one company after interviewing (and that was likely because I laughed when I found out their average workweek was 60+ hours — a rather awkward interview!).

Thanks to my meticulous spreadsheet, I realised that as soon as I talked to an actual person at the company, my odds of getting an offer went way up. My interview game was mostly on-point, but my ability to get that interview was not so great. If my job search had lasted a few more months, I would have definitely switched up my strategy. I would have spent less time writing a ton of cover letters and applications, and more time networking and cultivating referrals.

That brings us to my next few points…

5. Write a meaningful resume and cover letter
Instead of writing lots of low-quality applications, spend more time writing highly-tailored applications. After all, a resume or cover letter with typos or grammatical errors will get rejected immediately. Resumes that are over one page, more often than not, get rejected immediately.

Generic cover letters might not get rejected immediately. However, in a sea of job applications, they really don’t do anything for you. Take a few minutes to visit the company website, and come up with a genuine reason why you’d like to work for that specific company. If you can’t, well, maybe that’s a sign it’s not the right company for you.

Either way, you should tailor your responses as much as possible. Avoid copying and pasting any templates you find online (hiring managers will Google it, I promise).

I could write a whole article on resumes alone. But in general, you should highlight the most relevant technical aspects of your previous jobs. For example, I used to work in nonprofit development and fundraising — nothing about the job title screams “web developer.” HOWEVER, I made sure to highlight my work on migrating data and managing fundraising software. In addition, I placed my top three most relevant portfolio projects at the top of my resume. Thus, my technical ability was demonstrated BEFORE my work history.

6. Network!

So, I am TERRIBLE at networking. I’m a shy introvert and find it hard to mingle in large-group settings. But even for me, it was possible. I dragged myself to local meetups, and sometimes I even had fun chatting with other techies.

The vast majority of the meetups didn’t result in any job leads, honestly, but the handful that did really paid off. In fact, the job that I have now is one that I learned about through someone I met at a meetup!

So I really, really encourage you to put yourself out there and attend meetups, lectures, and Slack groups for tech professionals. Even connecting with people/companies online via social media is helpful. The best jobs are often never even posted, so it’s important to try and build your professional network even as a newcomer to the industry.

And remember — this is a mutually beneficial exchange! Many companies offer referral bonuses to employees, so it is often in their interest to lend a helping hand too.

7. Avoid settling for less, and negotiate, negotiate, negotiate

Image from Unsplash

At nearly every position I interviewed for, at some point, I was asked what my target salary was. This was frustrating, as in general, the first one to name a number is in a weaker position for negotiations. At the same time, you don’t want to waste your time interviewing at a company that falls far below your desired salary.

After fumbling with this question a few times, I finally got my act together and conducted some salary research. I looked up salary estimates for developers with my level of experience in my city on websites like Payscale, as well as a salary survey from my local tech meetup. At larger companies, you can also look up salaries on Glassdoor, so you can be surer that your range more or less aligns with theirs.

So whenever I was asked what my salary requirements were, I said: “My target salary range is $X to $X. However, money is not the most important thing. I’m really looking for a company where I can continue to grow and contribute to the team.” This was basically my way of stating my target salary in the politest way I knew how. I stated a range to express my flexibility but made sure that the bottom of the range was something that I would be 100% happy with.

And once you do get an offer, never be afraid to negotiate. It never ever hurts to ask! You can also negotiate on other things besides salary. These can include vacation days, delaying your start-date, and sign-on bonuses, which can be more flexible than base-pay.

Thank you to all of you who made it this far! I hope that you found this helpful in your job search. My last piece of advice is this: don’t worry about just getting a job. There is a ton of demand out there for software engineers, even outside of the major tech hubs. If you’ve studied and prepared, you WILL be able to get a job.

Focus on getting the right job — a role that involves working in technologies that you love, at a company that treats its employees well. It might not always be possible to get both at your first tech job, but once you get your foot in the door, pursuing the next opportunity will get a lot easier. It only gets better from here.

Be kind to yourself, and take care. Good luck!

This article originally appeared on freeCodeCamp.

About HackerTrail

HackerTrail is a curated marketplace exclusively for IT talent ranging from developers to infrastructure specialists to data scientists. Using clever technology and gamification, HackerTrail connects the right candidate to the right job opportunities with top companies across Southeast Asia.

Get your first engineering job by checking out which companies are hiring for recent grads on

Why Should I Learn Android?

You have firmly decided that you want to learn to create applications for Android using Kotlin. You are super motivated to create your first application.

Or are you?

If only it were that simple. There is that lingering feeling in your heart: “Perhaps learning iOS is better?” Were you thinking about Web and Desktop application development yet?

Choices, choices — everywhere!

Even if you’ve decided on Android, perhaps, you are still not sure what is the best starting point: Kotlin or Java.

There are a lot of comparisons between iOS and Android development out there, and they all talk about (if you haven’t seen those yet, go and search on the internet — there are plenty of those):

  • size of the market
  • jobs prospects
  • revenue gaining opportunities
  • development tooling
  • knowledge transferability (how the knowledge you learn on one platform can help (or cannot) on the other platform)
  • device fragmentation and many others

Let’s imagine that you have identified a benefit from one side, like Android’s market size being much more significant.

Next moment, you find a downside that either will cancel out the benefit or will make you spend a lot of effort to cancel out that itself (like device fragmentation and revenue levels).

So the choice is pretty tricky and not apparent.

I know how you feel right now. I’ve been there when I was trying to choose what mobile platform I wanted to learn first. It is frustrating and painful.

But hey, if you have already made a firm decision — great! Read on, and you will not be disappointed. Because what is to come — will surprise you.

In programming, when things go about learning, all of the above matters quite a bit.

But not as much as the learning benefit that you get.

Learning a Programming Language in a Day? — Impossible!

Or is it?

Did you know that a programmer who is an experienced learner, can learn a programming language in one or two days? And get comfortable with the platform, bunch of libraries, and a framework in another one or two days?

Sounds shocking, isn’t it?

And no, I’m not trying to sound arrogant here. These are actual people, who I know. And they can pull that off. Moreover, they can join a team that has an entirely unfamiliar set of technologies, and be productive on their first day.

They are not some geniuses or super-talented people.

They do share one observable trait though: they all know five and more programming languages, and they are proficient with a bunch of different libraries and frameworks from these languages.

These developers can start being productive with a technology they’ve never seen before in a matter of hours.

For that, they need access to someone already proficient in this technology. While working on some feature, experienced learners would ask a few specific questions to the experts, so that they can fill in the blanks in their existing knowledge.

So two to three questions and they are already ahead of most learners by far. As far as by months and years of experience.

That sounds amazing and daunting at the same time.

Perhaps, you are thinking “That is not possible!” Or maybe you’re feeling down because you can’t learn as they do.


The point is that, when you will be able to command (comfortably developing production-ready applications) roughly five and more programming languages (that are not very alike), and about the same amount of different frameworks, then this skill of rapid learning is yours to take.

In fact, it will already be yours. And you’ll be just like these “talented” (more like hard-working) developers.

To get there, you’ll need to accept the “Life of Learning” into your heart. You’ll need to become a lifelong learner.

Just like them, you will want never to miss an opportunity to learn.

There is a weird behaviour of the library? — You go out of your way to read the documentation and sources. And you debug and use print statements.

You do all of that until you understand precisely why it behaves this way.

Perhaps, you catch a glimpse of a new concept, but made it work without fully understanding it? — go there, read about it, play around with it, until you have a full understanding of it.

Do you have a bug in front of you, and somehow your last code change made it fixed? But you still don’t understand the bug? — You don’t stop there.

You figure out why it was not working, and why your fix worked.

Sometimes, you’ll need to create a tiny application just to play around with a single new concept. Use it in all the forms and for different purposes, until you’re confident that you got this.

I hear you’re saying: “One day? No matter how much learning you do — it is just not possible!”

Heck, it takes months and sometimes years to learn a programming language!

I know, right?

That is true. It takes so much time to learn even a single concept in programming.

But it takes a tiny bit less time to learn your second concept. Especially, if that concept has some connection to the one you’ve just learned before.

But it all checks out.

Science Behind Learning Programming Language in a Day

In Human Cognition and Learning, there are few theories on how people process information and learn. These all theories are significant and complement each other.

There is one theory that contributes to this effect of learning a programming language in a day.

It is the Schema Theory developed by the respected psychologist Richard C. Anderson (Anderson 1977, 1978; Shallert 1982).

You can dig into these white papers in your own time, but let me quickly give you an overview of most important parts here.

The main concept in the schema theory is Schema. It represents generic knowledge. A schema includes slots for all the components and features included in it.

One schema can contain other schemata (plural of schema). Essentially, schemata are embedded within others at different levels of abstraction. But relationships between those are not necessarily hierarchical (like a tree in programming), but more like webs (bi-directional graphs in programming).

Let me give you an example of what could be person’s schema of a “variable”:

I’m pretty sure there is a lot one can add to that schema. You can continue expanding this schema endlessly.

At some point, you will even escape domain of programming and start talking about normal things in life and nature. Or perhaps, you can connect it to mathematics or linguistics domain. And so on.

Why do you think I’m so obsessed with cognition and learning?

I’ve spent a few weeks digging through papers to understand how a person can learn faster and better. Especially, I was interested in formal and abstract concepts’ learning.

I did it because I’m creating a few Kotlin and Android tutorials and I encourage you to become a member of iwillteachyoukotlin so that you can receive an early preview version of my “Ultimate Tutorial: Getting Started With Kotlin on Android.”

Anyways. Schemata like that are not just drawn on the paper by a learning student (not saying that you couldn’t — it might be a good idea).

They are formed naturally in one’s brain when individual gains more an more experience and concept understanding.

Schemata change all the time. Even right now, while you are reading this same text, your schemata are being expanded and re-structured (unless you already know everything here).

The most important point is that schemata like that are much more than a sum of its parts. Whenever your brain makes a meaningful connection between two schemata, you gain insight.

It is like having a breakthrough.

Did you ever have an “A-ha!” moment like: “A-ha! This thing over here is just like that other thing I know everything about but with such small difference?”

This insight might not be 100% correct. But it doesn’t have to. Such insights are something that makes you able to apply an otherwise wholly new concept quickly.

So here is the deal. The more schemata you have readily available to connect concepts to, the faster you’ll learn these concepts. Some of these schemata don’t even have to be from the domain of programming.

For example, if you are learning how double-linked list works, you might connect that concept to a schema of how cars are connected in the train.

Then you can understand all the operations with a double-linked list (such as insert and remove) as an operation being performed on the train cars.

And it will all check out.

Kind of.

Obviously, such connections between schemata are just what we call metaphors.

They give us meaningful and useful models for the understanding of a particular concept. But they have edge cases when concepts differ from these models.

So it makes sense to discover these edge cases, and learn how the concept behaves in these.

That, my dear reader, is exactly what experienced learners do when they ask precise questions about new programming language or framework to someone already knowledgeable in it.

They probe those holes in their models. They fill in the blanks in their schemata.

Alright, this is all great, but what does it have to do with the question whether you should learn Android or Kotlin for that matter?

Or should I ask the real question?

Why Should I Learn?

See what I did there?

I’ve changed the question and made Android, or Kotlin irrelevant.

So should you learn?

According to the schema theory, the answer is a definite “Yes.”

You’ll need all the learning and all the schemata that you can get to achieve your life goals. So learning every day and at every opportunity should not even be a question. That is just what you do.

The simple reason to do it always is that the more you do it, the easier and faster it gets.

My famous phrase “learning is a skill that can and must be trained” shines here. The more you learn — the more schemata you have and more interconnected they are.

As a result, it gets easier and faster to learn new concepts — to expand said schemata.

That is all unless you don’t want to learn anything in your life again. Sorry to break it to you, but as soon as you want to achieve anything you haven’t done yet, you’ll have to learn and grow.

From the fact that you are reading this, I firmly believe that you want to learn.

That makes this question answered, you want, and you should learn.

What about Android?

Well, no matter how much you weigh the upsides and downsides of all the different platforms, you won’t arrive at the decisive solution. It depends a lot on what kind of application do you want to create, what business you are trying to build, and what is your market.

If you already have all that information, you should be able to make a choice.

If you are just looking at what new technology to get in your toolbelt as a software developer, then it doesn’t matter as long as it is something that is widely used. Android is.

What about Kotlin?

These two years and a half, Android community has seen a rapid increase in Kotlin usage. Every single software developer that I’ve met or been working with were super happy about Kotlin.

They’ve converted company’s application to Kotlin as soon as possible too.

Some of them made a conversion even before the stable 1.0 release of Kotlin. Which was a bold move, but it was worth it.

Moreover, Google and other big companies and communities are making their bet on Kotlin.

If you are reading this, you’ve perhaps already made a choice. If I were you today, I would do the same — learn Kotlin.

This article originally appeared on Hackernoon.

About HackerTrail

HackerTrail is a curated marketplace exclusively for IT talent ranging from developers to infrastructure specialists to data scientists. Using clever technology and gamification, HackerTrail connects the right candidate to the right job opportunities with top companies across Southeast Asia.

Looking for an opportunity in Android development? Check out top companies in Singapore hiring for Android developers now on

The Best Interview Questions We’ve Ever Published

Hiring is by far the biggest concern we hear from founders. Finding the right people to work at your company is high-stakes. Poor performers can take a catastrophic toll on your success. Most seasoned CEOs say that founders should be spending as much as 50% of their time early on getting the right talent in the door. Yet, the actual hiring process tends to remain more of an art than a science for startups — regardless of all the structure and rubrics they try to impose.


This makes the questions you choose to ask during interviews of paramount importance. You only get a narrow sliver of time with each candidate, so you need to maximize your learning per minute. How do you do that?

Over the years here at the Review, we’ve collected and aggregated hundreds of interview questions recommended by top leaders in every field. Our goal in this piece is to present the very best questions we’ve heard for hiring incredible performers — with deep dives into interviewing technical and product candidates in particular. We hope having them all in one place will make your future hiring that much easier.

1. Ask these questions to test for the 7 most important high-performer attributes.

As Co-founder and CEO of KoruKristen Hamilton has long worked to bridge the gap between graduation and employment, and place people in jobs where they’ll excel. Working with candidates who lack real-world experience has had a surprising byproduct — she now has a crystal clear sense of the skills and traits that make people great performers. She’s identified seven characteristics that, taken together, best translate into someone killing it at their job. These traits transcend department or career stage, and they apply to entry-level engineers and marketing executives alike:

  • Grit
  • Rigor
  • Impact
  • Teamwork
  • Ownership
  • Curiosity
  • Polish

To test for each of these qualities during a standard interview, Hamilton has curated very specific questions—

For grit, ask:
Tell us about a time in your career that you wanted something so badly that you were unstoppable in pursuing it. What obstacles did you overcome to get there?

As you listen to the answers to those questions, pay close attention to both the tasks and the duration described. “Try to get a sense of how long that person can stick it out. How long are they going to beat their head against a problem?”

For rigor, ask:
Tell us about a time you used data to make a decision.

Look for details about the complexity of the data and how the thinking happened, rather than focusing on them immediately getting to the right answer.

For impact, ask:
1) Tell us about a time you had a measurable (read: quantitative) impact on a job or an organization. 

2) Tell us about a person or organization that you admire. Why do you think they have made an important impact?

You’re looking for signs that the candidate understands the larger picture, and that they can speak to the importance of making trade-offs and prioritizing appropriately.

For teamwork, ask:
1) When working on a team, what’s hardest for you? 
2) What about a time you worked on a difficult team? What was your role and experience? Do you know where the other people involved were coming from? Tell us about the situation from their perspective.
3) What makes you happiest and most effective when working with others?

You want to use their answers to measure EQ and ability to empathize. Are they able to acknowledge and understand the experiences of those around them?

For ownership, ask:
Tell us about a time you experienced what you perceive to be an injustice.

“Regardless of their answer, empathize with the unfairness,” Hamilton says. “Say, ‘Are you kidding? That’s crazy. What a jerk.’ True owners will immediately respond with something like, ‘Yeah, but I recognized it wasn’t worth my time to complain about it.’ They won’t buy in and double down on venting or complaining.”

For curiosity, ask:
What’s the last thing you really geeked out about?

You’re looking for them to say something they then obsessively taught themselves about. “If someone doesn’t have that quality — if they don’t need to learn every single detail of the topic in front of them — they’re probably not going to reflect that level of engagement in their work, either.”

For polish:
1) See how they handle themselves when you interject or interrupt them in the conversation.

2) Do they send a thank you note shortly after the conversation?

You’re looking for calm confidence when they might otherwise be flustered or thrown off their game. Gratitude following an interview indicates humility and a sense of professional standards that will translate into their work.

For more on how to ask these questions and suss out the 7 traits for success, read the rest of Kristen Hamilton’s interview here.

2. This is the anatomy of the perfect technical interview.

As the former Technology VP for both Amazon and Zynga, Neil Roseman‘s interviewed hundreds of people and believes every phase of the process needs to be meticulously designed to drill deep into skill sets, actual accomplishments, culture fit and leadership potential.

In his opinion, great interview questions focus on specific examples of the candidate’s unique contributions, actions, decisions and impact. Ideally, you want to:

Probe: give me an example…

Dig: who, what, where, why and how on every accomplishment or project

Differentiate: we vs. I, good vs. great, exposure vs. expertise, aprticipant vs. owner/leader, 20 yard line vs. 80 yard line

“I look for past projects and accomplishments that seem to have enough weight and depth that I can apply STAR questions — STAR stands for situation, task, actions and results.” Roseman subscribes heavily to an approach called Behavioral Interviewing, in which STAR questions are a staple. They include:

  • What’s the background of what you were working on?
  • What tasks were you given?
  • What actions did you take?
  • What results did you measure?

When it comes to soft skills and culture fit, Roseman is a big fan of one question — he asks everyone, no matter the position: Do you consider yourself lucky?

“I’m looking for the people who embody the phrase ‘fortune favors the prepared,’” says Roseman. “It’s the willingness to be ready and take advantage of every opportunity that presents itself. At a startup, this is particularly valuable.”

For more questions and advice on how to structure interviews from Roseman, read on here.

3. Identify ‘Adaptable Leaders’ with this list of questions.

According to Anne Dwane, former CEO of Zinch, CBO of Chegg and now Co-founder of Village Global, the most important quality any startup leader (current or aspiring) can have is adaptability. And the most defining attribute of adaptable leaders is who they surround themselves with. They are often on teams with other flexible, resourceful, innovative people. Whether now or in the future, Dwane recommends a certain hiring framework to help you identify self-motivated individuals who will enrich your team’s aptitude for learning.

“The most powerful way to construct a job description is to clearly communicate that unyielding, consistent learning is a core part of the job,” she says.

After making introductions, Dwane begins with a pointed two-part question: What motivates you and what do you want to do next?

Most candidates deflect the question by repeating their resume. “They try to add to it but it doesn’t demonstrate what I’m looking for which is: active listening, the ability to answer the question, and self-awareness.”

She then asks these questions to identify whether a candidate is an adaptable learner:

  • What have you started?
  • How would you describe yourself in your own words?
  • How would a colleague describe you in three adjectives?
  • What current trends are you seeing in your profession?
  • What new things have you tried recently?

The last two questions are strong indicators that your candidate is self-motivated to explore and embrace new trends, routines, and technology. Take note of this as a critical demonstration of self-learning in your interview. Dwane advises probing more about the new process he or she introduced, why it intrigued them, and the results of implementing it.

As for homework: “I love to give people an opportunity to give a compelling presentation on a topic they care about,” Dwane says. “That’s the game. If they look pained while they are doing it or don’t enjoy the assignment, then you know someone isn’t going to have a gameful approach. You want someone who is going to enjoy talking about the topic and putting the presentation together.”

For more on how to spot, hire and nurture adaptable leaders, read more from Dwane here.

4. These questions are designed to bust bureaucracy before it starts.

As VP of Engineering at Airbnb with an impressive track record behind him, Mike Curtis has seen the dire impact that bureaucracy can have on a company. In his experience, hiring well to begin with is one of the most powerful antidotes to paralyzing bureaucracy. You want to recruit and onboard people you know you can trust, so you that you don’t have to set up a bunch of newfangled process just to ensure productivity and quality.

To hire specifically for this type of trustworthiness, Curtis recommends allocating at least 45 minutes to an interview that is entirely about culture and character. Diversity of backgrounds and opinions is championed at Airbnb, so ‘Culture fit’ is about finding people who share the high-performance work ethic and belief in the company’s mission. If people don’t share your conviction in your company’s success, they aren’t a fit.

At Airbnb, Curtis found that these four moves truly extract the most value out of this type of interview:

Let them shine first. For the first 15 minutes of your culture interview, let a candidate describe a project they’re particularly proud of. The idea here is to get a sense of what excites them — is it technical challenges, for example, or perhaps personal interactions? “Try to suss out what gives this person energy,” Curtis says.

Then make them uncomfortable. The other side of that coin is that you want to learn how candidates react when they’re not excited, too. Ask them about difficult experiences, or moments when they were somehow not in control. Some of Curtis’s go-to questions are:“Describe a time you really disagreed with management on something. What happened?” and “Think of a time you had to cut corners on a project in a way you weren’t proud of to make a deadline. How did you handle it?” This exercise is all about reactions. “Does the candidate start pointing fingers and say, ‘This is why I couldn’t get my job done, this is why this company is so screwed up’? Or do they start talking about how they understood another person’s point of view and collaborated on a solution?”

Calibrate your results. It’s easy to see if someone nailed a coding challenge. It’s a lot harder to get comparable reads on candidates when you’re working with a group of different interviewers. It takes time to get on the same page, but you can help the process along. “We get all our interviewers together in a room and have them review several packets at the same time to help expedite the process of getting to some kind of calibration on what’s important to us,” Curtis says. Essentially, try to make the subjective as objective as you can.

Watch out for signs of coaching. If a candidate seems to have uncanny command of your internal language, take note. The public domain is exploding with tips and tricks from past interviewees and journalists. “Especially as your company starts getting more popular or well-known, there’s going to be a lot of stuff about you out on the Internet. If people start quoting things to you that they obviously read in an article or something that is your own internal language, they were probably coached. They either read something or they talked to somebody who works at the company,” Curtis says. That’s not to say you should reject them immediately, just don’t let yourself be swayed.

For more from Curtis on not only how to hire, but onboard and train new employees to head bureaucracy off at the pass, read more of our interview with him here.

5. Recruiting practices and questions for hiring ‘Originals’.

Bestselling author and Wharton professor Adam Grant has spent years researching and interviewing people he refers to as ‘originals’. In his book of same name, he shows how to identify, foster and nurture nonconformists — and the brilliant benefits they bring to their work and the organizations they join. Here are the questions he suggests asking to recognize and recruit them in a startup setting:

Tell me about the last time that you encountered a rule in an organization that you thought made no sense. What was the rule? What did you do and what was the result? “You’re not excited about candidates who just let it go. But you also don’t want somebody who says, ‘Yeah I saw this rule, marched into my boss’ office, argued and quit over it,” says Grant. “What you’re looking for is somebody who says, ‘I saw this rule that I thought didn’t make sense. I first did some research to figure out how it was created and why it was this way. I spoke to a couple of people who’d been at the organization longer than I had, asking if they knew what it was initially set out to do. If they didn’t know, I reached out to some people who have influence and sought their advice on ways forward to improve the rule and made a few suggestions on how. I got tasked to lead the committee to change the rule. We made a change and here’s the evidence that we had an impact.’ That’s an original who’s learned to be a tempered radical.”

Why shouldn’t I hire you? “In Originals, I talk about founder Rufus Griscom, who pitched his startup Babble to investors by listing three reasons not to invest in his business. Sarah Robb O’Hagan once opened her job application the same way, describing why she shouldn’t be hired. In one breath, she outlined which qualifications she didn’t meet, but also why she was suited to do it anyway,” says Grant. “She challenges the job description and shows that she can bring something different than what a company thinks it needs. Part of why this worked is that, in one fell swoop, she shows extreme awareness: not only of her abilities, but also of the proposed requirements — and why some don’t really matter.”

It’s your first few months on the job. What questions would you first ask and to whom? Presidential candidates are often asked what they plan to accomplish in their first 100 days in office, and hiring managers tend to evaluate candidates for leadership positions similarly. “This idea came from one of my collaborators, Reb Rebele, an applied positive psychology expert who leads many of our hiring projects,” says Grant. “He observed that when new people are coming in, their first few months should be as much about learning as doing. Originals distinguish themselves by asking questions that no one else has thought to ask, and posing them to people who have fresh perspectives to offer. Ask candidates what questions they’d want to ask in their first two months on the job, and who their ideal sources would be. Listen for examples of open-ended questions — rather than just yes/no or testing-my-own-thinking styles of inquiry — as well as a willingness to draw from and challenge many sources of information.”

How would you improve our interview process? “I find this question powerful for a couple of reasons. One, it’s an opportunity to see if they’re willing to speak up. Two, it’s a window into their thinking process. When they encounter something that they don’t like, do they have the instinct not only to raise why it may be broken but also suggest how it can be better?” asks Grant. “It’s a chance to learn about their tendency to share opinions that might be unpopular but beneficial. It gives you a little bit of perspective on their ability and inclination to improve their environment.”

For more on fostering an environment where original talents can truly thrive, read more of our exclusive interview with Adam Grant.

6. Interview questions for hiring the best product managers.

Todd Jackson has led product organizations across some of the best companies in tech, from Google to Facebook to Twitter. Now VP of Product at Dropbox, he’s worked with hundreds of product managers — and hired dozens — over the course of his career. In every product manager interview, he recommends making sure a candidate fits the following criteria:

  • Intellectual ability
  • Communication
  • Leadership
  • Effectiveness within the company culture
  • Knows that users wants
  • Strategic/ Analytical Thinking
  • Technical background
  • Entrepreneurial spirit

Below, Jackson lists the questions he’s found to be the most valuable when interviewing product management candidates in person, what he believes good answers sound like, and the responses that should give you pause.

QUESTION 1 (Product Sense): Name a product that you think is exceptionally well-designed – ideally a non-electronic product. Tell me what makes it well-designed. (Testing intellectual ability, communication, and whether they know what customers want.)

WEAK ANSWER: Something superficial or cliché. “If they don’t go into a lot of detail and say something fluffy like, ‘My electric toothbrush is so great, it’s won a bunch of design awards,’ that’s a strike against them.”

GOOD ANSWER: First, the candidate will get excited to talk about a product they admire, and it will show. “One of the best answers I heard was about the Micro Kickboard scooter for kids – I remember the candidate getting really excited telling me all the details: ‘I recently noticed how thoughtfully designed my niece’s scooter is. It’s the mini scooter that you see a lot of kids riding lately. It’s got two big polyurethane wheels in front and a third small one in the back, so it goes over cracks and bumps smoothly and prevents faceplants. Also, instead of handlebars that turn, it has a ‘lean-to-steer’ design which is really intuitive for kids, teaching them how to steer by shifting their weight. And it’s also just super easy to assemble and disassemble—basically just two parts that click together.’”

Particularly strong candidates will look at the product from the user’s perspective and talk about the problem it solves. In the above example, “the candidate spoke about how the users of the product (kids) are actually different than the customers of the product (parents) and all the product design and marketing ramifications of that, which I though was quite insightful.” The candidate will have a lot to say and will be very enthusiastic as they speak, especially about the very small details that provide a finished and delightful experience. “That’s how you know the difference between a passionate product person and someone who just wants a job.”

To take it up a notch, you can follow up with the question: “What would you improve about it?” or “If you were the CEO of the company that produced this product, and you wanted to sell 10X as many, what would you do?” Look for educated guesses or reasonable assumptions about the market for the product, who the target buyer is, how the market could expand, the constraints of production, etc. Those are the components that should drive the next best step for the product, it shouldn’t just be a random idea.

Note: It can be easy for PM candidates to prepare for this question. You can make sure they’re thinking on their feet by constraining the space they choose from. For instance, the example must be a physical or non-electronic product or one they have at home.

QUESTION 2 (Technical Skill): In as much detail as possible, tell me what happens when I type into my browser and hit enter. (Testing intellectual ability, communication skills and technical background.)

WEAK ANSWER: Their response might be rudimentary or confused. You could get an answer like, “I see the Yahoo homepage, right?”

GOOD ANSWER: Something like, “Your browser generates an HTTP request. A DNS lookup gets the IP address of the host. The server receives the request, checks for cookies to see if you’re logged in, and eventually generates an HTTP response containing the content you should see. Your browser receives the response, parses the DOM and starts to render the page. CSS, images and Javascript are loaded to modify the page.”

The strongest candidates can answer this question in good detail, taking about five minutes to walk you through the process. This is a good level-setting question for product managers so you can see where they stand technically. They don’t have to hit every single action that happens. Watch out especially for candidates who say they’ve programmed in the last few years but are clueless about this question. That’s definitely a red flag.

If you think that candidates may have prepared for this type of question, you can mix it up by drilling them on specifics at various junctures of their response. Or you can ask them similar questions about the fundamentals of iOS or Android programming if they have a lot of mobile experience.

QUESTION 3 (Leadership): Tell me about a time when you disagreed with engineers and designers on your team. What did you do? (Tests communication, leadership and effectiveness within the company culture)

WEAK ANSWER: There will be allusion to finger-pointing, or mention of blame. The tone of their response will be generally negative, and you might see a dip in self awareness, complemented by a spike in defensiveness. They’ll be more concerned with smoothing over their role in the confrontation than sticking to the facts.

GOOD ANSWER: They’ll demonstrate leadership by diagnosing root causes of the conflict. They’ll show humility. “One candidate told me she couldn’t agree with her engineering and design team on one feature — they all wanted to build it and she didn’t. She said, ‘Okay let’s time-bound it. We’ll do the idea, but if it doesn’t pay off in four weeks, we’re going to change it to this other idea.’ I thought that was a great solution to avoid gridlock.” The candidate knew when to push back and when to disagree and commit.

A candidate who ends their response by saying what they learned from the situation and how they applied these lessons going forward should get serious bonus points.

QUESTION 4: What are all the implications of self-driving cars? (Tests strategic and analytical thinking and entrepreneurial spirit.)

WEAK ANSWER: A response that is boring, cursory, or disorganized. They might throw out some obvious answers, like unemployment for taxi drivers, or self-driving big rigs. But they won’t go deeper into the ripple effects in other industries that will create a whole new wave of businesses. They’ll stay in the inner ring of cause and effect.

GOOD ANSWER: Showing vision and imagination, they’ll paint you a picture of what could happen. Maybe car seats will be arranged in a circle around a coffee table! No one will own cars anymore, which means no one will have garages anymore. “I got an amazing answer to this one the other day: ‘Google will open-source the software for self-driving cars so that any manufacturer can build them, the way they offer Android,’” says Jackson. “I have no idea if that will be true or not, but I thought it was pretty creative.”

Most importantly, the answer should come packaged in some sort of organizational framework. Maybe they’ll say how life will change for drivers, and then the auto industry, and then urban planning. Ideas should be presented within themes, not as a free-association jumble.

QUESTION 5: What aspect of product management do you find the least interesting?

WEAK ANSWER: A PM who complains about doing nitty gritty work (e.g. taking notes, scheduling meetings) and implies that these things are beneath them.

GOOD ANSWER: A great PM understands that they need to lead from the back, and they relish their role as an unsung hero. The candidate doesn’t have to say they love the tough nitty-gritty stuff, but they should get points for acknowledging the grungy parts of PM work and why it’s important to be in service to the team and mission their supporting.

QUESTION 6: Why do you want to work at this company or on this product?

WEAK ANSWER: “X industry/company is getting a lot of buzz. Everyone is talking about it. It’s really hot right now.”

GOOD ANSWER: Clearly passionate about the industry, company or project. Look for specific ideas and plans for what they’d want to do and how they want to make things better. This indicates that they really did their homework and have thought deeply about the company. In particular, keep your eyes peeled for long-term thinking, which indicates commitment to the industry or type of product. For example, is the person talking about what robots or drones will look like in 5 or 10 years? Or do they just talk about how robots and drones are exciting now? Here are some examples:

I’ve always wanted to work in X industry, I’ve done Y and Z in the last couple years to really prepare for this career move.

Company X has a huge competitive advantage because of Y.

I have been using product X for a while, and I really like feature Y. I think feature Z could really improve growth/engagement/monetization and here’s why…

You want people who are excited about the space, not just this one opportunity.

For more on finding, vetting and closing the best product management candidates, read more from Todd Jackson here.

This article originally appeared on First Round Review.

About HackerTrail

HackerTrail is a curated marketplace exclusively for IT talent ranging from developers to infrastructure specialists to data scientists. Using clever technology and gamification, HackerTrail connects the right candidate to the right job opportunities with top companies across Southeast Asia.

Looking to grow your tech team more efficiently? Post your tech jobs for free* and lock-in interviews with the right tech talent on today! Want to find out how to optimise your job postings to receive top profiles of pre-curated, responsive candidates? Get in touch with our Customer Success team at

*For a limited period only till March 2018.

A Fresh Grad’s Insider Tip On Surviving Your First IT Job

In an increasingly competitive work environment, we’ve all been programmed to be solely focused on success and to perceive failure as a negative thing. But in the age of digital transformation, many companies are flipping the switch. They are starting to realize that failure creates an opportunity for us to think beyond and innovate which is imperative to business success. Rabiah echoed similar sentiments as she shares with us her recent experience as a IT developer and the immense learning opportunities that were granted during her stint.

Why did you join GovTech’s Technology Associate Programme?

I joined this programme because it provides me the flexibility in experiencing different kinds of IT areas and further discover what I’m passionate about. It also gives me greater exposure on what’s really out there in the working world, going beyond what was taught in school, simultaneously gaining new knowledge and hands-on experience.

Tell us about the culture at GovTech and what you like about it.

I really really really love the openness and collaborative culture and people at Hive. Everyone is very passionate and it’s even more wonderful that they are always enthusiastic in sharing and conveying their knowledge with one another. Continuous learning and sharing knowledge is another culture that I love about GovTech. I’ve been here for almost 6 months and the people around me feel more like my friends rather than colleagues, even those who are not within my team so that’s great!

How has TAP benefited you?

Before I officially started working, GovTech had a sharing session on some of the projects that we could work on and gave us the opportunity to decide which we were most interested in to try out as a way to kickstart our career. I think it is a great initiative because entering the working world as a fresh graduate can be a terrifying experience, as you don’t know what to expect, thus the sharing session really helped to ease my worries. Also, the freedom to choose gave me a sense of ownership over what I’m doing right now. Plus, TAP provides us with options to try out new things so it is amazing that I am able to gain various technical hands-on experiences to improve myself professionally and deliver quality work.

Share about the most interesting project you have worked on at GovTech.

I’m currently working on Business Grant Portal (BGP) as the backend development of the application. Working on this project gives me a sense of purpose because I’m helping to streamline the grant application processes so that it’ll be easier for both agencies and businesses to manage and track their grant applications in a more sustainable and efficient way.

Also, I have the opportunity to gain hands-on experience on one of the top BPM softwares called Appian to handle the backend processes. It’s pretty cool how powerful bespoke software is in speeding up the development work as compared to the conventional way of coding everything from scratch, which could take years to finish given that BGP is quite a big project!

Share one key takeaway from the TAP programme

The TAP programme presents an abundance of opportunities. Willingness to learn is one of the essential qualities because it’s what keeps you motivated to experience new challenges and grow as an individual in both personal and professional aspects.

Do not be afraid to make mistakes because you can’t learn anything from being perfect. You should be familiar with this quote if you have watched The Haunted Mansion starring Eddie Murphy – “You try you fail, you try you fail. But the only true failure is when you stop trying”. So fail fast and learn faster!

What is the one advice you would give to those considering applying for the TAP programme?

BE BOLD. If you have the hunger to experience new challenges and innovative creative solutions via IT, join TAP for a fulfilling career. Believe in yourself and unleash your potential with GovTech!


Are you looking for a workplace that invest in the growth of its people, and provides a culture of strong collaborative and learning exchange? GovTech could be the workplace for you.  At GovTech, we are on a search for agile tech leaders with a breadth of knowledge and depth of expertise, through our Technology Associate Programme (TAP). This is an exclusive leadership trainee programme for top-notch technology seekers who will be groomed to take on management and technical roles with us.

Jump-start your career in the technology industry; join now by applying to the GovTech Technology Associate Programme. You can find out more about GovTech Technology Associate Programme here.

Working at GovTech: A Fresh Grad’s Perspective

With the increasing prevalence of cyber attacks, more and more companies are looking into hiring professionals to keep their information safe. Cybersecurity is certainly financially lucrative but these professionals are not doing it just for the paycheck. We speak to Keith, who shares with us his recent experience as an Incident Responder- drawing parallels to a firefighter, and the immense value his role brings to the company. In addition, we have Keith’s mentor, Liyana Fauzi, from the Strategic Planning and International Division to share with us how her GovTech journey has helped in her mentorship with Keith.

Why did you join GovTech’s Technology Associate Programme? 

Before I graduated, I was actively looking for a job in the Cyber Security technical field. One distinct reason on why I applied to GovTech’s TAP was the programme’s structure. I personally felt that the programme was well crafted for fresh graduates who wanted to develop a career in the IT industry. The programme encourages rotation, a mentor to guide you and offers several job roles to select from to kick-start your career.

Describe a typical working day at GovTech

I am an Incident Responder in the Cyber Security Operations team. What that basically means is that, my role is comparable to the functionality of a firefighter when a fire breaks out. The firefighter will be alerted of the incident immediately and tasked to contain the fire. They will then need to remediate the issue, provide root cause analysis on how the fire started as well as recommendations on how to prevent such a situation from happening in future. When the firefighters are not reacting to incidents, they will be at the station finding means to increase their skills or sharpen the tools they have.

This is similar to the reactive and proactive role as an Incident Responder. When a cyber-security incident occurs, we will be there to perform both forensic/memory image on the system and bring it back for further analysis.  

My typical workday typically consists of these 3 fundamental roles- malware analyst, data/log analyst and incident response. Malware analysis involves examining malicious scripts/executables and determine what are its capabilities. This could involve reverse-engineering an executable in assembly language. In addition, as a data/log analyst, I am involved in analysing the huge amount of raw data from network, application and database logs. In order to understand how the incident happened over the network, I have to correlate the data from multiple sources and make sense of what the adversary was trying to perform. Lastly, for incident response, I work as an incident Handler for security events.

As a proactive individual, I am always finding ways to reduce the time taken for investigation either by automating the investigation process or by looking for new tools out in the market which could aid in investigation.

However, GovTech is not all about work; till date I was involved in many other exciting events such as being part of the planning committee for Cyber Security Group (CSG). I also had the opportunity to participate in GovTech’s Dinner and Dance performance which gave me the opportunity to make a lot of wonderful friends from the different departments. My team also makes an effort every once in a month to head out and enjoy ourselves with activities like bowling, badminton, dinners and drinks, and many more!

Talk about the technical skills you have been working on at TAP?

Since my time here in GovTech, I have been exposed to various technical skills such as reverse engineering, data analytics and scripting. For reverse engineering, my role as a malware analyst is to understand the capabilities of a malware. This involves looking at assembly codes, understanding different API calls or even looking at malicious scripts/programs. In data analytics, there are countless opportunities to work on big data. I picked up numerous pre-processing techniques and analytical skills such as R, Python, Splunk, Tableau. As for scripting, I am continuously improving on our investigation tools as well as scripting languages such as Python, bash or Powershell.

What do you enjoy the most about working for GovTech?  

As we are the “firefighters” for the Whole-of-Government, the investigation we perform is for the government. By solving incidents, I get a sense of satisfaction as I am ensuring a safer environment for us to work in.

What is the one advice you would give to those considering applying for the TAP programme?

If you’re looking for a quick and challenging environment, GovTech will be the place for you. A personal advice on what I tell my juniors is that as a fresh graduate entering into the IT industry, there are just too many different roles. You will not know if the role suits you unless you try it out. Look for an organization which offers you the opportunity for rotation so you can grow as an individual.

Share one key takeaway from the TAP programme

As part of TAP, we are each paired with a mentor who is more senior in the organisation. My mentor, Liyana has guided me through my times here in GovTech. She ensured that I understood the organisation structure, check in if there were any challenges faced and asking if I needed any help that she can help with. It is really heartwarming to have an awesome mentor.

Liyana, share with us your mentorship experience with Keith.

I was matched with Keith and another mentee through a fun matchmaking/interview session. As Keith and I are from different teams in GovTech, I saw my role as a  mentor in general work matters, and not so much the technicalities of his domain area. This mentorship experience enabled me to reflect upon how it was for me when I first joined the then-IDA as a relatively fresh grad too, and to try to pick out some of the lessons I’ve learnt along the way since then; things that I could share with Keith. I have tried to keep the mentorship experience pretty light and to provide an open space for candid discussions. We would typically meet over coffee to talk about how he’s doing at work, what’s happening with the organisation (given that there have been many changes), and to also share my experience in navigating the workplace such as how to manage stakeholders or how my mentees could meet their meet career aspirations.

How has your GovTech journey helped your mentorship with Keith? 

What helped me in my mentorship was mainly (a) things I picked up from other seniors, (b) having gone through certain GovTech programmes and (c) forging friendships with other mentors. For example, one piece of workplace advice that I hold closely is not to be afraid to ask and actively pursue opportunities that one was interested in. This piece of advice was lent to me by another senior and it is something I share with my mentees too, and I think it could be useful for the TAPs who are just starting out at work. Programmes that I had completed in my GovTech journey such as the EDGE Programme and the Sectoral Inter-agency Projects have also provided me with some insight into what the other agencies are doing, how agencies view GovTech’s work and how to manage cross-agency issues. To me, it is important for my mentees to know how their work has impact on other agencies’. In addition, as all mentors had to go through a two-day course, the friendships I developed with other mentors has also been very helpful in this journey as we could exchange ideas about topics to discuss with our own individual mentees.


Are you an advocate of the innovative use of technology and how it can enhance the lives of fellow Singaporeans? GovTech Technology Associate Programme (TAP) could be a place for you to start. TAP is an exclusive leadership trainee programme carefully crafted to develop and hone your technical knowledge and professional skills.  Upon selection, you’ll participate in 24 months of specialist training and grooming to take on technical roles within GovTech that will accelerate your career development.

Make an impact on the future of technology; join now by applying to the GovTech Technology Associate Programme. You can find out more about GovTech Technology Associate Programme here.


Hiring Trends: 2016 wrap-up with HackerTrail

As we wind up 2016 and chalk-out our strategy for the new year, let’s take a look back at how this year molded the recruitment circuit. Irrespective of the growing candidate pool, the recruitment market continued to stay aggressive with companies competing with each other to attract top talent. The hiring strategies this year were also heavily influenced by employers in their efforts to woo and retain millennials.

Here is a look at the hiring practices that dominated 2016:

Social Media Recruitment 

The initiation of social media in recruitment practices has opened new avenues for companies over the years and 2016 was no different. According to a survey by LinkedIn’s global recruiting trends, 47% of the respondents stated that their outbound recruitment strategies involved social media. Social media outreach is empowering employers to go beyond traditional job posts and establish a continued relationship with prospective candidates. Employers are grasping the concept of being “switched on” on relevant social media platforms to build a strong presence to showcase their company brand and culture to their respective target audience.

Employer Branding

Employer branding continues to play a significant role in recruitment strategy. According to a survey by Jobvite, 59% of the respondents used social media to understand the company culture of organizations they wanted to work with as well as the perks and benefits that came with the role. Companies are putting immense emphasis on their value proposition as employers and working towards the culture they want to foster. This is not just to attract new candidates but ensure that they retain their top talent as well. Here’s how one company found success with video content on employer branding:

Recruitment Technology

The recruitment tech scene this year leaped beyond aggregators and market places. From the introduction of AI in automating recruitment workflows to writing unique machine learning algorithms for efficient candidate screening, technology is redefining the recruitment sphere. Companies are not just using technology to revamp their workflows but also using it to build focused and reliable assessment methods. For employers who engage HackerTrail to recruit, the hiring processes go beyond mere interviews as HackerTrail’s proprietary technology allows to automagically curate candidates, minimize the human bias and maintain the focus on quality. Coding challenges via gamification are put in place to test candidate skills, eliminating the element of chance from the process. This also gives candidates an opportunity to experience the job scope first hand and have fun while they are at it.

“Hackertrail was both an amazing experience and an unconventional interview process that allowed me to connect with my future employers through interesting challenges. It gave me a good preview of what to expect in my future role as a web developer and I thoroughly enjoyed the stretch of my technical capabilities while going through the tasks!”

– Yang LJ

(Top Talent on HackerTrail recruited by a government agency)

Predictive Analytics

Like every business function, human resources are heavily relying on predictive analytics to understand future scenarios and bet on their strategy and other executive decisions. Companies are using predictive analytics to understand their candidates better based on their interviews, submissions, work experiences and other data points. Many companies build models to assess their candidates and determine their potential fit in the company. Companies are also using predictive analytics on existing employee data to scrape for patterns to model their ideal candidate and shortlist accordingly. HackerTrail focuses on two key hiring metrics: speed and quality to empower employers to focus on the right candidates and shorten their time to hire.

This year has been a “candidate’s market” more than ever before with 2016 witnessing the industry restructuring their recruitment approach from “push” to “pull” – a focus on attracting and nurturing a healthy talent pool rather than blanket outreach and active scouting. Recruitment strategies anchoring firmly on technology and analytics are bound to up the notch in the coming year. With emphasis on efficiency and metrics, automation will be the focus in 2017 and the key for companies to fit into the rapidly evolving innovation landscape of recruitment.

We look forward to sharing some exciting news in the early part of the new year so do keep in touch by following us on LinkedIn, Facebook and Twitter.

Till then, here’s us wishing you best wishes for the new year ahead!

New year, new recruitment strategy? Here is one place to start:

Performance Tips for a Rails Stack

Watch Althaf Hameez, Lead Engineer at Grab, do a quick presentation on the performance tips they use at Grab for a rails stack.

He goes on to say that it’s not about using rails; it’s how you design your app.

Watch on as he shares more about the tips they use at Grab:

If you want to be part of this exciting startup and experiment with innovative technologies, then check out the roles that Grab is currently hiring for!

Grab is currently expanding their team and HackerTrail has partnered up with them to source for key developer roles here in Singapore. Crack the challenge at HackerTrail (yes, we have our own as well and you get win cool prizes like the Apple Watch and iPad Mini 4) and get shortlisted by Grab today.

Are you connected with us? Follow HackerTrail on LinkedIn, Facebook and Twitter to find out about the up and coming tech jobs in Southeast Asia.

Programmers Beware – UX is not just for designers

Perhaps one of the biggest missed opportunities in Tech in recent history is UX.

Somehow, UX became the domain of Product Designers and User Interface Designers.

While they definitely are the right people to be thinking about web pages, mobile app screens and so on, we’ve missed a huge part of what we engineers work on everyday: SDKs and APIs.

We live in a time where “the API economy” exists and has tangible monetary and strategic value and yet these UXs are seldom considered. Additionally, consider how many functions a programmer interacts with every day and yet how little (read: almost none) time is spent on the UX of these functions.

What is UX?

First let me give you my perspective on UX. UX stands for “User Experience” or to put it another way, “usability”.

UX is not black art; you don’t even need to study it. I believe it can be uncovered through logic, persistence and experience.

I believe a good UX can be discovered using the following “UX Discovery Survey”.

Ask yourself (or your team) these quick 5 questions and you will be well on your way to create better UXs.

  • Who/What is the user? – Yes, users can be other systems and not just people.
  • What do they want to achieve? – Often the answer to this is a list of things, this is fine. However it’s generally possible to apply the 80/20 rule; meaning users will want to do 1 thing 80% of the time and the rest about 20%. We should always over-optimize for the 80%; even if it means making the 20% a lot more complicated or inconvenient.
  • What are they capable of? – What skills do they have? What domain knowledge do they have? What kind of experience? When designing systems for others there is often a huge difference between these factors for the user and the creator. This factor shows up a lot more when the answer to “Who/What is the user” is a human and not a system.
  • What can I do to make their life easier? – This is really the driving force behind UX, focus on the user and how to please them. Is there anything similar out there that the user already knows how to use? – The best interfaces are often ubiquitous or intuitive. The focus here is on modelling the interface to do what the user expects it to do, without prior training or experience with it. If you ever have access to the end user, try asking them these questions:

    “What do you think it should do?”

    “What did you expect to happen when you did X?”

Let me show you what I mean with some examples of Engineering UX:

A REST API called from a Mobile Application

When the app in question starts, it must make a call to the server to login and then use the returned credentials to make another to download the latest news.

What’s wrong with this?

This makes 2 round trips to the server, which results in:

  • 2 potential points of failure.
  • Double the network latency.
  • Additional code complexity of handling the additional points of failure.
  • Additional code complexity of handling the “session” between calls.

Finding a better UX

Let’s run through the “UX Discovery Survey”:

  • Who/What is the user? – The user here is not the programmer using the API but the mobile application.
  • What do they want to achieve? – They want to load the data from the server in the fastest possible manner using the least amount of battery and data as possible.
  • What are they capable of? – It’s app. It’s capable of whatever the app programmer is capable of.
  • What can I do to make their life easier? – One call is always going to be easier to code than two. One point of failure is always easier to handle than two.
  • Is there anything similar out there that the user already knows how to use? – Not applicable here.

Merge the requests together and have the app send either the login credentials or the session as part of the request for news.

While the call to the server is slightly more complicated, this is completely overshadowed by the complexity of coordinating 2 calls and failure points that it removes.


Yes, this adds some complexity to the server side but the server is significantly easier to test, maintain and update than the mobile app.

A REST API called from a Mobile Application (Redux)

Some time passes from the above example and the app is updated and now it needs to download the weather and the news when it starts. In common REST ideology we consider the news and weather to be separate entities and therefore the request is to add a separate endpoint in order to be RESTful.

What’s wrong with this?

We are back to making 2 round trips to the server. But this time they are concurrent, which results in:

  • 2 potential points of failure (again).
  • Additional code complexity of handling the additional points of failure and partial failures (again).
  • Paying battery and data charges for 2 calls (again).

Finding a better UX

Let’s run through the “UX Discovery Survey”:

Unsurprisingly, the answers will be similar to the previous section.

However, let’s now also consider the user of the app (in addition to the app as the user of the API)

  • Who/What is the user? – This time let’s consider the problem from the app user’s perspective.
  • What do they want to achieve? – The answer to this question becomes the key to understanding how the app should behave. Does the user need both pieces of info in an “all or nothing” way? Would partial info be better than none? Does the user need all of that info when the app starts or could they wait for retries? Bigger more complicated calls are bound to take a little longer. Users these days are fairly used to content that “fills itself in” eventually but they doesn’t mean they like it. Beyond that, not all information is of equal value to the user. If we are making a news app, the weather may be a “nice to have” for most users.
  • What are they capable of? – As before.
  • What can I do to make their life easier? – As before, this is the key. Whatever the user most wants/needs wins.
  • Is there anything similar out there that the user already knows how to use? – Not applicable here.


Sadly, my answer here is “it depends”. I would look to make as few round trips as possible and sacrifice RESTful correctness for performance or a better UX. The focus should always be on the end user and their needs. Both explicit (seeing the data/using the app) and implicit (costing less battery and data).

There is often a temptation to follow whatever is easiest or quickiest to implement. This is a valid optimization when you need to get to market as fast as possible but it is also a debt, akin to technical debt, that will need to be paid sooner or later.


This time an internal (behind the firewall) service publishes an RPC API that allows a user to download an eBook. However this book should only be accessible to certain users.

As this service is not publically accessible we could ignore the validation and assume that calls to the API are only made in cases where the permission have already been verified.

What’s wrong with this?

  • If the calling system is not aware of whether the user is permitted to perform this action, they will need to load this permission (perhaps from another system) before making the request.
  • If a second system also needs to make this API call, then the logic to validate the user can perform the action would need to be duplicated into this new system.
  • Any attempt to cache this permission in the calling systems would likely be inefficient and prone to duplication.

Finding a better UX

Let’s run through the “UX Discovery Survey”:

  • Who/What is the user? – The other systems / API consumers.
  • What do they want to achieve? – They want to download the book on behalf of their user, if the user is permitted to do so.
  • What are they capable of? – Anything.
  • What can I do to make their life easier? – We could take complete ownership of the problem and allow our users to make blind / dumb calls to our API and we take care of everything else.
  • Is there anything similar out there that the user already knows how to use? – This question needs to asked within the problem space / company you are in. If all of your APIs are trusted then it might be better to follow that style rather than force your users to learn / handle your different way of doing things. Word of caution though: APIs should very often be stateless and require no more knowledge than how to call it; if all of your APIs are trusted then I suggest you raise that issue with your team.


You could introduce a gateway service between the callers and the destination; however this is likely adding complexity, latency and another service to build, manage and maintain. A generally more effective option is to push the validation logic into the RPC server.

This will:

  • Eliminate any duplication between multiple clients.
  • Likely improve the overall performance as the storage / caching of the permissions can be optimized for this use-case.
  • Improve the UX to the users by allowing them to blindly make the request.

Code APIs

The general problem here is the fact that code inherently makes more sense to the person writing it, when they are writing it, than it does the others and even to the writer in the future. Seldom do we think about other users when we are writing our functions.

Consider the following code:

<span style="color: #000000;"><code>AddBalance(5, false)</code></span>

What does the false indicate?

Finding a better UX

Let’s run through the “UX Discovery Survey”:

  • Who/What is the user? – Your future self. Your current and future team members.
  • What do they want to achieve? – They want to use your code so they don’t have to write their own.
  • What are they capable of? – There are many answers to this question, some nice and some not so nice. Generally, it’s better to assume the skill level is low and so is the domain knowledge.
  • What can I do to make their life easier? – Personally, I am lazy. This laziness forces me to come from a place of “what interface would allow my future self to use this without thinking or learning?”
  • Is there anything similar out there that the user already knows how to use? – Consistency in programming style, naming and many other things is programming will go a long way to a better UX. Often people will make the argument that a certain piece of code is “X style” where X is the current programming language or framework. I used to see this as a weak argument but as the teams I worked in got larger, consistency of style (preferably the team’s agreed and published style) has proven extremely valuable in terms of allowing folks to change teams, share code and tips and most importantly learn from each other.


What happens to the usability if we replace the boolean parameter with 2 functions?




In actual fact the result will often be 3 functions. These 2 above public / exported functions and the original function / common code as private.

Boolean arguments are an easy target but there are many other easy and quick wins, consider this function:

<span style="color: #000000;"><code>var day = toDay("Monday")</code></span>

What happens if we call it like this?

var day = toDay("MONDAY")
 var day = toDay("monday")
 var day = toDay("mon")

These are great examples of “What can I do to make their life easier?”.

A good UX would consider all reasonable ways a user might use or misuse the interface and in many cases support them instead of forcing the user to learn and then remember the exact format required.


  • UX is not just about Visual User Interfaces.
  • APIs and SDKs are also user interfaces.
  • Programmers are also users.
  • Other systems are also users.
  • UX is about designing the interface or interaction from the user’s perspective.
  • It’s about considering the user’s desires, tendencies and capabilities.
  • It’s about making the system feel like “it just works”.

Finally, I would mention that the best UXs are the result of iterative and interactive efforts.

The best way to answer the questions of “What do they want to achieve?”, “What are they capable of?” and “What can I do to make their life easier?” is to give the interface to a real user, watch what they do it with it and how. Then respond by making the interface work they way they thought it would instead of teaching them otherwise.

It is always better (and easier) to change the UX to match the user than the other way around.


Article adapted from “Programmers Beware – UX is not just for designers” by Corey Scott


Grab is currently expanding their team and HackerTrail has partnered up with them to source for key developer roles here in Singapore. Crack the challenge at HackerTrail (yes, we have our own as well and you get win cool prizes like the Apple Watch and iPad Mini 4) and get shortlisted by Grab today.

Are you connected with us? Follow HackerTrail on LinkedIn, Facebook and Twitter to find out about the up and coming tech jobs in Southeast Asia.

Do First Impressions Really Count?

Here’s the hard truth: 80% of hiring managers will decide within the first 10 minutes of an interview whether to hire you or not. While every second in that interview room might feel like forever, anxiety might affect your responses to your potential employers. Here’s how you can work on the first impression that you’re putting forward.

Do Your Research

Before the big day, find out as much as you can about the company. A few simple clicks on the organisation’s website will usually reveal the company’s history andother useful facts, like their employee headcount, or who’s in charge of the department you’re hoping to work in.

…And Know Your Interviewer And The Company

With this knowledge, you’ll sound more prepared and stand out as a candidate who is interested in the particular company. Showing interest in the company can also be translated as a “fit” for the company’s culture, boosting your chances of interview success.

Get There On Time

This cannot be stressed enough! Always plan ahead and arrive earlier than the scheduled time. If the interview venue is particularly out of the way, or located in in an area that you’re unfamiliar with, do your research online or go down in person!

Dress to Impress

The saying “Dress for the job you want, not the job you have” still holds true here. We’ve shared tips on what to wear before; find them in our “5 Things To Remember At Your Job Interview” post here.

The First Handshake

It may not seem like much, but 60% of employers say that they will judge a candidate based on their handshake.

Never, ever offer a limp fish/dead fish handshake. Practice until you achieve a firm grip that means business.

Your 30-Second Pitch

Also known as your “elevator pitch”, you should be able to sum up your career history, achievements, and personal qualities within 30 seconds. Who are you? What do you do? Where do you want to go, or what are you looking for? These are the 3 questions that should be answered by the end of your half-minute.

Tips for your pitch include telling stories or anecdotes, eliminating jargon, practicing your pitch on friends and colleagues, and recording yourself on video to spot your own verbal cues and body language. Is your mini-speech interesting enough to captivate your audience? Is it even interesting to yourself? Practice your pitch regularly.

Body Posture

Speaking of body language, this graphic taken from one of our previous blog posts captures the essential body language to-dos during an interview.

Ask The Right Questions

From our post about “Interviewing Your Interviewer”, we mentioned that asking your potential employer questions lays down two things:

“Firstly, when done correctly, the questions you ask confirm your qualifications as a candidate for the position.

Secondly, you are interviewing the employer just as much as the employer is interviewing you. This is your opportunity to find out if this is an organisation where you want to work.”

More on what questions to ask your interviewer here.

Overall, practice, practice, and practice. You’ve got one shot at what could potentially be the best experience in your career, and now that you know how important the first 10 minutes are, you better start preparing for it!