Entry No. 305

How To Be a Successful Intern

We’ve had a number of technical interns here in FCS over the years. Some do really well: by the end of their internships they find themselves delivering major projects directly to clients. Others don’t do as well. Here are some things we’ve noticed are common to the more successful ones.

Before we dive into these common factors, though, let’s talk a little about internships in general. What should you be looking for in an internship?

Internship Goals

The key to understanding internships is that you’re there to learn two things:

  1. Technical skills. This is a no brainer: you’re a programmer, you take on a software engineering internship to learn real-world technical skills. The way code is written in the industry is different from school, and this is where you get to learn that difference.
  2. Work/life exposure. The actual experience of working in a company. This is what people refer to when they say they’re looking for ‘people with job experience’: what they actually mean is that working in a job involves setting the right expectations. People expect new employees to come in with the right attitude, calibrated to the job they’re hired to do.

Most interns we meet at FCS know that they should be focusing on learning all the technical skills they can. And this might be obvious to you too. But what is interesting is that you should also be maximising your work exposure.

This is not very obvious. Some new hires we’ve seen come in with vastly different expectations. Some expect to be spoon-fed skills. Others are unhappy if they are assigned work that they aren’t interested in. An internship is the best place for you to learn what your expectations should be.

As an intern, you’re in the unique position of being able to see the inner workings of a company, without being tied to it. An internship is just a temporary job, after all. You don’t have to stay after your n months are up. This is both an disadvantage and an advantage.

The disadvantage is that sometimes, you can’t see how the whole company works because you’re the most junior person in the room. The advantage, however, is that you can compare across multiple companies (this is true if you do multiple internships). Comparing across internships is how you figure out what kind of company you would like to work for in your career.

(I strongly urge you to consider doing at least 2 internships – one at a big company, and one at a small company during your university life. Find a way to make it happen.)

While you’re at the internship, take the time to learn everything you can about the company. How does it make its money? Who are the best engineers? What is the leadership like? What weaknesses do you notice about this company, and how might you make it better if you were in a position of power? How are conflicts resolved, and how are engineering decisions made?

Talk to your manager, and make friends with the seniors above you.

These seem like irrelevant questions, but they turn out to be very important in your career. Knowing how a company makes its money teaches you to see if you’re in a profit-centre or a cost-centre. It also tells you what the most valuable jobs look like in other, similar companies.

Company weaknesses are even more important to notice: they might not be a deal-breaker to you right now as an intern, but if the full-timers in your company are quitting because of something, then you know what to watch out for it in the future companies you apply to.

3 months is long enough to pick up on a broad set of experiences, if you’re willing to put in the time and listen. Ask the full-timers what career and life decisions they’ve made, and then decide for yourself if you want to make the same decisions in your life.

Now let’s look at some qualities the best interns seem to share:

1. Knowing when to ask questions

This is tricky. One of the most annoying traits a junior employee can have is the tendency to keep asking questions about the most basic things. This is annoying because you begin to waste the time of senior employees, whose time is more valuable than yours.

As a junior employee, you do want to be effective, and it is true that you know less than your seniors. So what’s the right balance between asking for help and struggling with your problems by yourself?

I have two ideas that may help:

The first idea is to ask questions according to the following template: “I have a problem with X. I have tried A, B and C, but it doesn’t work. Instead, when I tried A I got bad result P, when I tried B I got bad result Q, and when I tried C I got weird result R.”

Until you are able to give a list of approaches that you’ve tried and failed, don’t ask a senior.

The second idea is to time box stuff you don’t understand. Need to implement a feature and don’t have any idea how to do it? Give yourself X minutes, set a timer, and then at the end of those X minutes ask a senior.

The first idea forces you to make sufficient effort, and the second idea prevents you from wasting too much time when some guidance may be useful.

2. Ask for regular reviews

Internships are a great opportunity to get real industry experience. To maximise this opportunity, maximise the feedback you get.

If your company has some form of monthly managerial review, that’s great. But even if you do have these reviews, given the limited amount of time you have at a company, it’s probably a good idea to get informal reviews from seniors at a higher frequency than just monthly.

These reviews could be as simple as “hey, could we have a quick chat about that project I worked on this week?” with your primary manager. And if you’ve collaborated with seniors from other teams, it might make sense to approach them for some feedback at the end of the week, or the end of the collaboration as well.

3. Work harder than a full-timer

Now, before I begin on this, let me say up front that work/life balance is important to get right in your life. Work/life balance is so important to the rest of your career, in fact, that I urge you to figure out your limit as an intern, instead of figuring it out while you’re a full-timer.

What do I mean by this? Well, the stakes for burnout are much lower as an intern than as a full-timer. Internships are book-ended by academic semesters, because you get to go back to school after an internship is over. And internships are good places to level up, seeing as you have a clear amount of time, and clear goals to achieve. Pushing yourself to get to those goals within the set timeframe is an obvious thing to do.

This is probably going to be controversial, but I recommend using your internship as an opportunity to figure out where your limits are, so you know when to stop when you’re finally working as a full-timer. Work late into the night, try one or two all-nighters, and most importantly, notice when you become resentful about the work you’re doing.

Resentment is the best signal I know that burnout is on the horizon. If you feel it, you know that burnout isn’t far away. And you’ll have learnt something important about yourself, I think, something you won’t have to learn the hard way when you’re working full time at a job.

This post is part of the FCS Career Guide for Software Engineers in Vietnam. Check the guide for more software engineering career advice.

Entry No. 295

Small but Effective

This short document will outline some skills and attitudes that would help you with your engineering career at Floating Cube. Engineers receive this document during orientation.


Floating Cube is a small company, and will likely remain small compared to other companies for some time. As of 2016 we are dedicated to building a small but effective team of engineers, who will be building up the foundation of all our future products. Notice what’s not in that sentence: it doesn’t say professional, or perfect. We don’t care that you wear nice clothes to the office. It instead says small and effective. Let’s talk about what this means.

Small teams allow individual engineers to make a large impact on the company. Being small also means being exposed to a lot of technologies and aspects of the business, and having the opportunity to build for the future.

Effective teams demand ability to execute. We care about how well you contribute to or accelerate the development of the rest of us. In return, we will take your growth seriously, and help you perform better for our benefit. By the time your time with us is up, our aim is that you will be able to leave at a higher level than when you came to us.

Here are some skills that would help you during your tenure here:

Debugging ability

Many things will break as Floating Cube grows. This includes code, modules during deployments, or processes (aka the way we do things) as we scale our company up. Your job as an engineer will include recognising when things are broken and pointing it out to us with the aim of fixing things.

Fearlessness to dive into something you don’t know

Being part of a small team means that you will get to grow faster. How this actually happens is that you’ll be exposed to other aspects of building product that most engineers in a larger company won’t. To experience this, you must be fearless to dive into things you don’t know.

Don’t be afraid to modify 3rd party software. Don’t be afraid to dive into your teammate’s code to fix something for a client. Don’t be afraid to call a client to ask for more information, or debug his problem, or even visit his shop in Singapore to see how your software runs. All these things will make you better at building product.

A pragmatic approach to decision making

It’s nice to sit down and talk about best practices, or the ideal ways to do development. But in a small organisation, pressing technical or business problems exist today. This may sometimes mean doing non-optimal technical, process, or people-related things.

A useful rule to use is to ask yourself “what action will increase the probability that the whole team succeeds?” when facing one of these decisions. Know when to get things done, but know also when to push back to make things better. Pick your battles for the benefit of the team.

A tool building mindset

By definition, a small but effective team means that we have to increase the productivity of every member of the team. Building tools is an engineer’s solution to get more done with the same number of people. Do your work with an eye towards automation, or streamlining processes to make everyone’s lives easier.

A strong generalist mindset

Floating Cube is at the stage where we’re building many new platforms for our future products. This may include using a new programming language, operating system, or framework tomorrow. All our engineers are expected to be able to pick up new things on the go. (We think this is the right attitude towards a career in our industry, anyway). Be prepared to move to a new platform tomorrow.

Be a player, not a victim

There are two responses to every event: we can either be victims and blame any problem (a slipped project deadline, a product launch that flops, or conflicts with teammates) as being due to external circumstances. Or, we can be players, and identify the aspects that are within our sphere of influence and focus our energy and efforts toward what we can actually affect and fix. Do the latter. Be a player. =)

Grit, combined with a willingness to learn and introspect

Grit is the ability to keep at something over a long period of time. Applying grit to self improvement will benefit everyone at the company, but most importantly yourself.

Floating Cube does reviews once every month. Use these sessions to reflect on the challenges you’ve faced in the past month. Focus on what you’ve learnt on your job, and what you’ve learnt about yourself while meeting your challenges. Then work with your manager on what you’d like to aim for in the coming month.

Featured image from Soreen D on Flickr, original content for this piece was by Edmund Lau on Quora, but adapted for FCS’s onboarding process.

Entry No. 270

The Value of Side Projects

When doing recruiting for Floating Cube Studios, I’ve found it rare to find students who have had side projects. Most of the candidates I’ve interviewed have only shown me school projects. I’m not completely sure why that is.

One possible reason could be that the university holidays here in Vietnam aren’t that long. Another could be that many students take on part-time jobs during the semester and during the school breaks – often, these roles aren’t technical. Students wait tables and help out in shops instead of taking on programming-related jobs.

And yet, when it comes to finding a software engineering job, successful, well executed side projects are often the easiest way to measure a programmer’s ability.

Even the very fact that you have side projects sends a signal to a potential employer that you at least like programming.

I want to argue that building side projects is the single most value-added activity a young programmer can be doing. These projects are even more helpful for those who get bad grades in school, yet still want to work in software engineering.

Here’s why.

1. Side projects indicate interest and motivation. You don’t come back from school and code on a side project if you aren’t self motivated. Side projects that you build out of interest tells me, as an employer, that you’re interested in problems outside of school. And if the project is successfully completed, it tells me that you have enough self motivation to see something through to the end. These are incredible skills that are valued in any programming role.

2. A portfolio of side projects also indicates exposure to external technology. The very best IT schools don’t teach specific technologies or tools. They instead teach the basics of programming and app development, and trust that the student will be able to go out and learn the rest on his or her own. This makes absolute sense: no university can constantly keep up with the latest developments in software engineering! Side projects are the easiest, if not the best way to learn cutting-edge development practices.

3. Side projects provide a good way of measuring skill. Why do companies hire people with good grades? Well, one reason is that grades are a way of measuring your ability. Companies think that candidates with good grades will translate to programmers who have good skill. However, in IT we can measure your skill directly: by reading your code! At FCS, we don’t look at grades so much. We read the candidate’s code, and listen to him or her speak about it. Students with bad grades can get hired in IT if they show they can write good code.

In fact, this last point has an even stranger conclusion: if you don’t have a degree from a University, or you graduated with a non-IT degree but can code, apply to software firms. You’re likely to get a job anyway.

It’s important to recognise that this is a huge advantage in our field. The ability to measure future performance directly, instead of using grades, means that anyone can become a software engineer. It also means the best way to become a good programmer is to program, not to take tests!

How do you get started?

There are many free books and resources related to learning new programming languages or frameworks. But it’s important to not spend too much time reading them (without actual coding).

The best way to get started on a side project is to find an interesting problem to solve. Ideally, your first problem should not require a solution that is too complicated to build.

I still remember the first side project I built: I had a friend in university who had a problem with parking in his university. Every once a month, the students at his school were required to sign into the university website and apply for a parking slot. This service was a first-come-first-serve basis: the first 200 people who submitted their details after 8am on the 1st day of the month got the parking space. So, on the 1st of every month, hundreds of students would camp by their computers, refreshing the page repeatedly for the button to appear.

I was in my first semester of university, and I had just learnt programming. I thought I could help him by writing a script to do everything automatically for him. The script could then loop repeatedly until it has succeeded in booking a parking slot.

As it turns out, this was a very useful project to do. As an excuse, I chose to learn the Python programming language, and then to learn to set it up with cron on a CentOS server I had just bought. It took me many painful hours, but I eventually got it to work.

Today, Python is my favourite programming language. And my friend never went without a parking slot for his entire university life.

A few other things that may help:

  • Use IRC when you are stuck and need help. If Google fails, and repeatedly banging your head against the wall doesn’t work, log in to freenode and go to the language channel to ask for help (e.g. #PHP if you are programming PHP, #Django if you are building something in Django, and so on).
  • If that fails, use StackOverflow!
  • Last, but not least: here is a list of free books you can use to start your learning.

Happy hacking!

This post is part of the FCS Career Guide for Software Engineers in Vietnam. Check the guide for more software engineering career advice.

Entry No. 261

Learning Many Frameworks vs Specialising In One

One of the most surprising things I’ve learnt about software engineers in Saigon is that many want to specialise in just one programming language or platform.

This is surprising to me because this attitude isn’t as common in Singapore. Software engineers in Singapore would at least say that learning new things is a good thing, even if they don’t really practice it.

But some Vietnamese engineers that I’ve spoken to have told me that they think learning new things – especially new things outside their circle of competence – is bad!

Some of them tell me that this is old Vietnamese wisdom: that if you specialise in more than one skill, you won’t be a master in any of them. Some tell me that their professors in University teach them to do this. And I am not the only one to have experienced this attitude: other software project managers have confirmed seeing this opinion in Saigon.

The net result is that I’ve met Vietnamese engineers who refuse to code in or learn platforms that are outside their selected speciality. For instance, Android engineers who refuse to touch iOS, or PHP engineers who refuse to write backends in any other language.

So which should you pick? Should you stick to one framework, or be the generalist that does all?

The answer to this isn’t that simple. It’s not true that one is good and the other bad. The real answer is this: whichever you pick, ensure your ability to learn new things does not disappear.

Learning is Painful

My main worry whenever I hear a Vietnamese engineer tell me that they don’t want to learn a new platform is that they’d forget how painful it is to learn something completely new.

This may sound strange if you’re fresh out of university, or currently an IT student. “Learning isn’t that painful!” you might say, “It’s normal!”

But give it a few years. Once you’ve spent 10 years, for example, getting good at iOS or PHP, you’ll find that learning something completely new can be very painful, especially in comparison to coding in a framework or language that you’re already an expert in.

This is especially dangerous in our industry, where things change quickly. Maybe today you’re a well-paid, valuable Android engineer. But if over the course of the next 5 years Android dies, or if Google decides to switch Android to a completely new language, you’ll be forced to learn something new or risk being unemployable.

Let’s be clear: the risk isn’t that you’ll suddenly get fired. The risk is that you’ll slowly get stuck in a company, never being promoted, and then when you’re finally let go you find that getting a job is suddenly a lot more difficult.

The flip side of this is that engineers who can learn quickly are often regarded as more valuable than engineers who can only do one thing. Companies like Google, for instance, never hire software engineers based purely on programming language skill: instead, they test programmers on algorithms and problem solving ability. Their reasoning? If you’re smart enough to pass an algorithms interview, you’re smart enough to pick up whatever language you’ll need to pick up at Google. More importantly, you’ll be smart enough to keep learning new languages as the company’s needs change.

But Learning Takes Time

There is, however, a flip side to this. It is true that constantly learning the shiniest new thing will come at the cost of being very good at one platform. You cannot become a master of one thing if you are dividing your time to learn many new things.

Also, I’ve met senior engineers in Vietnam who tell me that their families are more important to them. They don’t have that much time to learn new things, so why not spend it on getting good at the one thing that they already know and use? This is also true.

The truth is that both concerns are valid. This is why my argument isn’t to pick learning many things vs learning just one thing, but to ensure your ability to learn new things does not disappear. So long as you keep some base level of learning around, you’ll do fine regardless of which view you take.

This post is part of the FCS Career Guide for Software Engineers in Vietnam. Check the guide for more software engineering career advice.

Entry No. 250

Profit Centres vs Cost Centres

Profit centres vs cost centres is something I wish someone had told me earlier in my career.

This idea applies to just about any job you do, no matter what industry you’re in. It is a powerful way of looking at your work, and figuring out how good the job would be for your career in the long run.

Here’s how it works:

There are two kinds of places you can work in:

  1. You can be working in a profit centre, or
  2. You can be working in a cost centre

A profit centre is a job that makes money for the company. For example, if you’re working in a bank, the bankers are the profit centres – they’re where the bank makes most of its money. If you’re working for a tech company, the programmers are the profit centres. If you’re working for an accounting firm, the accountants are the profit centres. You get the idea.

Companies also have cost centres. These are places in the company that are regarded as the cost of doing business. So for instance, in a company like Google, the finance department and legal department are regarded as cost centres. They’re not directly tied to how Google makes its millions and millions of dollars each year; instead they are regarded as people you have to pay in order to get business done. On the other hand, banks regard their IT departments as cost centres. The bankers make all the money while the programmers are a cost of modern banking.

Here’s what this means for you: all things being equal, work for a profit centre, not a cost centre.

1) If you are in a profit centre, the company will regard you as one of the most important parts of the company. After all, how well you perform is linked directly to how much profits it gains!

2) Therefore the company is highly motivated to invest in you. People working in profit centres enjoy lots of invisible benefits: the company will spend more on them, will train them better, will work hard to keep them. On top of that, companies will try and recruit the best people to work in their profit centres, which means that your fellow colleagues, your managers, and their bosses are likely to be really good people you can learn from.

3) New projects that you want to push are more likely to be approved. You will have more freedom to start new initiatives. And so on so forth.

On the other hand, if you are working in a cost centre, you’re likely to suffer from a lack of invisible benefits. New initiatives are harder to push through, your colleagues won’t be as heavily recruited, and the company won’t work so hard to keep you.

This idea explains a lot about job and salary types. It explains why salespeople tend to be amongst the highest paid regardless of industry – because the sales force is directly linked to how much money a company makes. It also explains why programmers in Google enjoy more benefits than programmers in large banks.

Notice that the ‘profit centre vs cost centre’ argument does not say anything about how much you’re paid. If you are a lawyer in the legal department of a large company, you would probably be paid just as well as if you were working in a law firm. But you will learn less.

One last note: this idea also means that sometimes, the best way to get what you want is to position yourself as a profit centre to your boss, as opposed to a cost centre. Internal company politics are built around appearances. If you are in a cost centre, your best strategy is to sell yourself as a profit centre.

It can be entirely possible that an IT department is regarded as a profit centre inside a bank, if the head of the department knows how to sell his team as important to the bank’s long term goals (or if the CEO thinks IT is important).

Here’s a real world example: working in AIA’s IT team in Singapore is pretty good, because the current AIA CEO believes technology will be a huge competitive advantage for its business. The current team is paid well, and given quite a bit of freedom to innovate.

All things being equal, work for a profit centre, not a cost centre.

This post is part of the FCS Career Guide for Software Engineers in Vietnam. Check the guide for more software engineering career advice.

Entry No. 235

Salary vs Growth?

As a fresh graduate, should you go after a high-paying job, or look for places you can grow?

My answer to this is deceptively simple: so long as the job pays an acceptable salary, ignore salary and pick a job where you can grow.

Or, to express this as an SQL query:

SELECT * FROM jobs WHERE salary > x ORDER BY learning_rate

Why Companies Pay High Salaries

A high salary can be a very unreliable metric to use. This is because companies pay high salaries for one of two reasons: i) they pay you because you’re good. Or ii) they pay you well because the job sucks.

(There’s actually a third reason: because these companies are from overseas, and can afford to pay high salaries, but I’ll talk about that in a bit).

As a fresh graduate, you’re not likely to be very good. You may be on your way to being good, you may be a genius at exams, but unless you created Linux in University, like Linus Torvalds did, you simply aren’t worth as much. Therefore it’s more likely that the company is paying you a lot because the job stinks, and people don’t want to do it.

How can a job stink? Well, when I was just out of university, some of my highest paid friends worked on oil rigs, for petroleum companies. They were petrochemical engineers, and they were paid highly because they would live on oil rigs for months at a time, far away from friends, family, and good food.

Similarly, outsourcing companies sometimes pay high salaries, especially when compared to the average wage. This is usually a Very Bad Sign. These companies do this because you’re not going to learn as much. They also do this because their work is so soul-crushingly boring (imagine integrating SDKs for crappy games day-after-day) that you’ll want to shoot yourself in the head after a bit.

Now, I’m not saying you should get a job with a low salary. What I’m saying is: don’t be motivated by salary, at least not when you’re a fresh grad.

Instead, evaluate the job on other characteristics. So long as the job pays >= average, look at whether the job will allow you to grow faster and become better than all your peers. The second criteria matters more than the first.

Evaluating jobs like that will also allow you to pick jobs from overseas companies that pay high simply because they can. For instance, a company that sells software in the US makes a lot of money, so they can spend a lot on employees in Saigon when they open an office here. This is one situation in which a high salary does not mean a lousy job.

Why Choose Growth?

If salaries aren’t as important, why choose personal growth?

This is obvious if you pause to think about it. Remember when I said that companies pay good salaries because you deserve it? Well, a few years down the road, you will become good enough to justify a high salary. And your friends who started out of college with sucky-jobs-that-paid-well wouldn’t be so easily promoted.

They wouldn’t be so easily promoted because of two reasons: firstly, the rate at which you learn compounds. The more you know, the faster you learn. Sooner or later, you leave those who don’t learn as much behind.

Secondly, we are in an industry that rewards learning. The software world changes very quickly. People who don’t learn to learn, especially in the early years of their careers, will be crushed by the rate of change in this industry.

It is for this reason that I believe picking a job where your rate of learning is high will be the most important thing you can do for your career. This is especially true when you are young.

“Wait a minute!” some of you may say, “That’s not true! Some companies promote you based on how long you’ve been with the company. Others promote you based on how many years of experience you have on the job.”

The best companies in our industry value skills, not years of experience on the job. The companies that do ask you for your years of experience aren’t companies that you want to work for anyway. (Think about it: do you want to work for a company who promotes people based on seniority? That isn’t likely to be a company that you want to work for, because your boss is likely to be an idiot. Why is he likely to be an idiot? Because all the good people leave).

A good way of thinking about this tradeoff is that some jobs allow you to invest in yourself. Others allow you to cash out on your skills.

When you’re a fresh graduate, out of university, pick a job that allows you to invest in yourself.

Good Signs

How do you know a company is a place where you can learn a lot? Well, there are a few signs. When you’re interviewing with them, ask the following questions:

  1. Does the company take employee growth seriously?
  2. Does the company provide good mentorship?
  3. Are there code reviews?
  4. Is there a structured on-boarding program for new hires?
  5. Does the company provide you with books, or send you to seminars?

Some of the answers to these questions depend on the kind of company you work for. Product companies and certain kinds of consulting companies, for instance, are more motivated to grow their employees. Outsourcing companies and certain IT departments aren’t.

Be careful which kind of company you work for. Your learning rate matters to your future career.

This post is part of the FCS Career Guide for Software Engineers in Vietnam. Check the guide for more software engineering career advice.

Entry No. 218

The Value Chain of Software Companies in Vietnam

If you’re a software engineer in Vietnam, there are 4 types of companies you can work for. These companies exist on a spectrum of value. As you consider what kind of company you would like to work in, it pays to pause and consider each option.

Currently, Vietnam’s tech ecosystem has the following types of companies:

  • Outsourcing companies
  • IT departments of large, non-IT companies
  • Consulting companies
  • Product companies

Outsourcing companies

Outsourcing companies take a spec and turn it into code. Roles in these companies are sometimes called ‘code-monkey work’ – you’re just a programmer that has to implement whatever is given to you. Examples of some outsourcing contracts:

  • A games company in Europe wants integration of some analytics SDKs in their portfolio of apps, but doesn’t have enough manpower in their games development teams to do so. They hire a relatively cheap software company in Vietnam to do this for them. Your job: to integrate libraries across a dozen different apps.
  • A financial services company wants to build a stock tracker app for their customers. They hire a company in Europe. The European company sits down with the financial services company to understand the requirements, and then writes a spec. They then hire an outsourcing company in Vietnam and give them the spec. The European company pays the outsourcing company and keeps the rest as profit.

Outsourcing companies make up the majority of software companies in Vietnam – and naturally, they’re not very high-value places to work in. This is problematic for you, as a software engineer. Because outsourcing companies compete on cost (the cheaper service wins), software engineers at outsourcing companies will be pushed to be fast, not good.

Therefore, there is only so much you can learn in an outsourcing company.

An IT department of a large, non-IT company

IT departments build technology solutions for their company. This parent company is usually not an IT company.

This type of software engineering job is an interesting one to work in. For instance, you could be a software engineer in a bank, building the bank’s website or mobile services. Or you could be a software engineer for Proctor & Gamble, building internal tools for their managers to use.

Jobs in IT departments can be good or bad. How good your job is depends on how important the department is regarded inside the parent company. If the parent company regards the IT department as a valuable and strategic part of achieving its goals, then you will do well as a software engineer. On the other hand, if the parent company regards the IT department as a ‘cost-centre’ (i.e. the IT department is just the cost of doing business) then it would not be a very good software engineering job.

The tricky thing about this is that it’s often impossible to see how important the department is to the parent company until you’re already inside. The best trick to decide if it’s a good place to work in is to get to know someone who is already working inside the company, and then to ask him or her.

Consulting companies

Consulting companies build apps for clients. They look a little like outsourcing companies, but they’re not. For starters, consulting firms are supposed to come up with solutions for business problems. They do more than converting a list of features into code.

Let’s say, for instance, that a bank wants to build an app to increase usage of its credit card products. A consulting company would be hired by the bank to figure out the app strategy, the feature list, the deployment plan and the look and feel of the app. The consulting company then executes on all of this, while giving advice to the bank.

This is a consulting company, not an outsourcing one: the consulting company provides guidance to the bank on the best way to achieve the bank’s goals. The best consulting companies act like partners to their clients: both equally invested in their client’s success.

One large advantage of working in a consulting company is that you get to explore new technologies as you wish, for client projects. Of course, some clients want their projects to be implemented with a certain technology. But occasionally clients don’t care, beyond wanting the app to be done. In those cases engineers are free to pick the programming languages and frameworks they would like to use.

(Floating Cube Studios, by the way, is a bit of a mix – it is both a consulting and a product company).

Product companies 

Product companies are companies that build and own their own products. Because the engineers own the codebase of the product they’re working on, product companies tend to invest more time and energy into training and growing their engineers.

This applies to small companies like Ticketbox.vn, as well as large companies like Google, Facebook, and Atlassian. There’s a lot more nuance to whether a product company is good to work for (things like is your boss good, do you get along with your colleagues, are you being paid enough), but all other things being equal, product companies are good places to work in. The only trade-off is that you would not have an excuse to play with new technologies for each new project as you would in a consulting company.


If you’re a programmer in Vietnam, you need to consider your career prospects carefully. Where you work determines what kind of growth you would have as a software engineer.

If you have the opportunity: pick companies that are higher up in the value chain. The more value your company provides, the more opportunities you will have to learn. Which is to say: if you have a choice, don’t work for an outsourcing company. It’s not good for your career.

This post is part of the FCS Career Guide for Software Engineers in Vietnam. Check the guide for more software engineering career advice.

Entry No. 104

A Redesign, 5 Years Coming

It’s been 5 years since Floating Cube Studios first set up in Singapore and Saigon. We’ve gone though quite a bit since then: built apps for clients a couple hundred times our size, saw the evolution (and ever-escalating war) between Android, iOS and their respective app stores, and finally launched of a couple apps of our own, to varying degrees of success.

Today, I’m pleased to announce that we (finally) have a new web site, with special thanks to FCS’s design team (and specifically, Cong, who saw through the development of this from conception to deployment).

In many ways, this post is yet-another-random-firm’s-prognostication-while-announcing-something-boring-like-a-new-website blog post. Probably nobody will read this. But I want to pause here to note that we’re currently in the midst of a change. Floating Cube’s been through 5 years of app store exuberance. Those early years of the mobile rush – along with the optimism and easy successes – are long past.

Hieu, the technical lead, Trung, the design lead, and I are currently seeing through a change in direction for Floating Cube’s next few years. Asia is still at the cusp of a digital revolution unlike anything the West has ever seen. If you think of the first 20 years of the Internet as belonging to the West, then I’d wager the next 20 will see wide-scale changes in the wake of spreading information technology – and that most of the changes that matter will occur in Asia.

Being in Singapore and Vietnam thus gives us a unique opportunity: we’ll be in the centre of these changes – or at least a short flight away from most of them. But saying that is the easy part. Building a company to take advantage of that uncertain future is our real challenge.

Here’s to seeing how it goes.

Cedric – Project Manager,
Floating Cube Studios

Entry No. 62

Everything you need to know about how our blog works.

Awesome picture, init? Picture caption located outside the grid to the left of the picture like this.
Awesome picture, init? Picture caption located outside the grid to the left of the picture like this.

Body text for the blog section will be a 10-columns centered container. The font will be Georgia to enhance the legibility of the blog post. Let’s have a little history lesson about this typeface, Georgia. According to Wikipedia, Georgia is a transitional serif typeface designed in 1993 by Matthew Carter and hinted by Tom Rickner for the Microsoft Corporation, as the serif companion to the first Microsoft sans serif screen font, Verdana. Microsoft released the initial version of the font on November 1, 1996 as part of the core fonts for the Web collection. Later, it was bundled with Internet Explorer 4.0 supplemental font pack.

Georgia is designed for clarity on a computer monitor even at small sizes, partially effective due to a large x-height. The typeface is named after a tabloid headline titled “Alien heads found in Georgia.”

The Georgia typeface is similar to Times New Roman, but with many subtle differences: Georgia is larger than Times at the same point size, and has a greater x-height at the same actual size; Times New Roman is slightly narrower, with a more vertical axis; and Georgia’s serifs are slightly wider and have blunter, flatter ends. Georgia incorporates influences from Clarendon-style typefaces, especially in b, r, j, and c (uppercase and lowercase). Figures (numerals) are an exception: Georgia uses text (old-style) figures whereas Times New Roman has lining figures.

That was an interesting lesson for you. Did you notice the link to Wikipedia up there has a different colour? That’s how links are supposed to be styled. Now let’s see some quote and its style, shall we?

“I have a dream!” – Martin Luther King Jr.

The quote uses the font Circular by Linotype. And it has a different color as well, same as hyperlink. The font size is 36px. That’s pretty much what will be in a blog post. Let’s make this post a little longer with dummy text.

Oh but wait, last thing to include is some styling for the code tag. Let’s do it.

//a bunch of code goes here


print “Equal”;

} else {

print “Not equal”;


That’s it. Pretty simple isn’t it? Since the blog post is finished we will have an option to comments, likes and share this post.