Truly great things are never achieved alone, they always are team efforts. This is true for general business, product development, sports, family life or pretty much any other domain you could think of. Wherever multiple people are required to get a job done, coordination therefore becomes critical.

Coordination can be among multiple people with similar skill sets (e.g. a number of Android developers or a number of designers), or just as often, coordinating between various different skill sets to achieve a bigger goal (e.g. building a product with a developer, a designer, a PM, a QA, a sysadmin, etc.).

Successful task coordination and delegation therefore are key in doing great work. While it definitely takes a lot of practice and experience to successfully delegate and everybody develops their own style over time, there are a few guidelines which can increase the likelihood of success.

Based on my own experience coordinating various teams over the past 10 years, from various sizes, cultures and styles, I find the likelihood of a positive outcome to dramatically improve when the following questions have properly been considered:

1. Is the task and the output expectation clearly defined?
2. Does the other person have the skills to execute the task?
3. Does the other person have the authority to execute the task?
4. Have I handed off tasks to this person before and know “how he/she ticks” and how to set her up for success?

This article will explain these 4 considerations in more detail as well as give concrete tips on how to improve your task delegation.

1. Proper task definition

A common mistake I often encounter when people delegate a task (myself included) is that the person did not actually think of the desired outcome properly before delegating.

Sometimes, this can be due to a lack of specific knowledge of the person trying to delegate a task. An example could be when a business person asks a tech person to “assess if somebody is a good tech hire” without having pre-defined what “good” means (e.g. no guidance in terms of what kind of experience would be relevant, what the goals of that role are, the critical success factors, etc.)

Other times, it could be due to either ignorance (e.g. in the prior example, the lack of understanding that “a good tech hire” is a rather subjective judgement and hence, not easy to answer with yes/no), or because of a lack of time invested to properly think about the task.

It is important to understand that this does not have to mean that you micro-manage every person you are working with. A task can be delegated with a vague description (e.g. “create a product strategy”) — but in that case, it is crucial that the person delegating the task and the person supposed to execute that task jointly discuss what the real purpose of this task is.

In the example of “creating a product strategy” , it could be that a CEO asks a VP Product to come up with the product strategy which is supposed to support the overall business goal of growing revenues by 50% while also increasing customer retention. The CEO may not have a clear sense of how to do that, hence, pass this major task to a VP Product. Yet, the VP Product should make sure he clarifies the real drivers for this task and not just accept the request to “create a product strategy”. Otherwise, he may find himself surprised if his self-chosen priority and resulting strategy to minimise technical debt is not met with the expected enthusiasm.

Clear scope and requirements need to be understood as a shared responsibility between the person delegating and the person receiving a task. The person delegating the task should ensure he tries to clearly communicate the task but also the person receiving the task should not hesitate to ask any questions and clarify until a common understanding is established. One relatively straightforward way of verifying a mutual understanding can be to ask the person you delegated the task to, to paraphrase the task and ask them to explain their approach to solving and what the solution will roughly look like. This way you can check whether this matches your expectations and if not, do early corrections without significant time being wasted.

In summary, however, no matter whether the task is small or very large, without explicitly setting a clear goal and discussing what “success” would look like, chances of a happy outcome radically go down.

2. Ensuring appropriate task-skill fit

In one of the first management retreats I attended, the HR director of that company held a presentation on how to deal with poor employee performance. One of the key messages was to ensure a clear understanding of poor employee performance cause (potentially perceived). A key distinction made in her talk was to understand whether an employee is demonstrating poor performance because he is not motivated to perform better, or, whether he is motivated but does not have the skills to perform better.

Over time, continuously putting people into jobs where they do not have the necessary skills will lead to people losing motivation. However, depending on the organization and culture, in my experience (especially in the startup or social entrepreneurship world) it is quite rare for people to show very low motivation levels from the get go if they are generally treated fairly. A more common case with people who appear to perform poorly seems to be that they are put on tasks where they do not have the appropriate skills.

While it is rare for somebody to be hired for one thing and then being asked to work on something completely different (e.g. hiring a designer and then asking them to do sysadmin work), it is very common to be overly optimistic or ignorant of the scales and complexities of tasks. Selling newspapers on the street is different from selling enterprise software contracts to governments. Building Wordpress websites with some customised features is different from building core analytics engines for big data projects. While many people will intuitively agree with this, the reality is often grey and distinctions are not easy to realize.

This is further caused by the natural dilemma between trying to help people grow by stretching them far outside of their comfort zone, and (unconsciously) setting them up for failures by asking too much of a person. Finding the right balance between a tough “good” challenge and a pure hail mary task requires a lot of experience and insight into both a person’s abilities and a task’s requirement. Through critical self-reflection and over an extended time period, you can sometimes see a personal trend, whether you may be “asking too much” of the people you delegate to despite the best of intentions.

In the case of poor performance due to lack of appropriate skills, there usually tend to be three major options:

a) ask the person to do a different task

b) train the person to do that task if it makes sense from a cost/return perspective

c) let go of the person

While the implications of option (a) are obvious, option (b) and © deserve a bit more explanation.

A company’s mission typically is different from a school in so far that training somebody to do a particular task is an investment decision. Is the time spent on training that person justified? Are there good reasons to believe that the person will quickly pick up the skill and deliver good value? Or is it a long shot and it would be much more economical to hire somebody else for that task?

As an example, if I were supposed to design an entire website from scratch, I would struggle to do a great job. Essentially, I would have to start from zero and after a few years of training, I may be able to do a reasonable job. At that point however, the company would have had to invest a very large amount of time and money into me, when in reality there are many highly talented designers available who could hit the ground running quickly. Therefore, in this case from a business perspective, it probably would not be a good idea to try and train me.

If I am somebody with great overall development skills, deep architecture knowledge and adequate leadership experience, and now I am supposed to lead a project in a new programming language, it will be natural to think about how I can be quickly learn and adapt within a few weeks and the overall benefit I already brought to the table is significant.

For case (b), an assessment has to happen of how big the gap is and whether it makes sense for the company to try and train the person to bridge that gap or whether finding someone else.

Case © can often be very difficult for young managers as it seems harsh to let go of somebody who is very motivated yet does not perform.

Personally, I am no friend of firing quickly and have a certain level of skepticism towards this option as I have found many less experienced managers to be overly fast to assume the person “isn’t working out” when it could be at least partially due to the way that person is being managed.

Despite maybe sounding slightly counterintuitive, I would argue that in these cases, a manager almost has a moral obligation to work with the employee on a clean way to let the employee go. Ultimately, that situation is neither long-term feasible for the company, nor the employee and a manager has no right to “waste” an employee’s time by trying to ignore the problem and not helping the employee find a better environment or set up elsewhere.

Understanding an employee’s skills in order to matching skills and tasks is a task that requires experience and a lot of skills of the manager. The reality often is quite messy with few clear cases of mismatches and a lot of grey areas. Keeping such basic considerations in mind however, can definitely help to improve the likelihood of success.

3. Authority to execute a task

Imagine Jose Mourinho, a professional football manager, were to attend an amateur club’s football match. There is little doubt that he will be a more experienced and better manager than the manager of that amateur football club.

However, sitting from the sideline, he has no authority to give orders to the team and even if he were to demand one player to be substituted for another player, it would not happen unless the actual manager decides to make such substitution. At the same time, even though Mourinho may be the expert, nobody expects him to be calling the shots either. He has the skills, but is not responsible, doesn’t have the authority to execute and is not under the expectation of leading that team.

This extreme example is fairly intuitive and the dynamics in football teams are well enough understood to follow this case. However, in teams similar situations can arise where somebody would delegate a task to somebody else who may have the skills and now is under the expectation to perform, but does not have the authority. This could be because in order for that person to do their job, they require input from a third person, yet, that third person is not aware of his required contribution or, in particularly bad cases, refuses to cooperate. As a manager, therefore, it is crucial to ensure that when you hand off a task, you not only pass on the expectation for the person to perform, but also provide that person with the authority to perform accordingly.

Providing somebody with the authority to behave in certain ways requires trust in that person’s judgement and that can be tough, especially for inexperienced managers. Full authority without any oversight can also be problematic, hence striking the right balance is key. In my experience, that is best achieved if both parties know each other reasonably well leading to the fourth consideration: prior joint experience.

4. Prior joint experience

Managing people by definition has to do with people and the relationships you build with them. Each relationship is unique and relationships change over time (whether better or worse depends on the investment both parties make into the relationship). If you have worked very closely with somebody for an extended time period, sometimes a simple sentence is enough to convey a complex idea. That same content however may need a one hour meeting with somebody you have not worked with before.

When working with somebody new, I like to roughly apply a principle called “additive increase — multiplicative decrease” — something I first heard of a long time ago, surprisingly, with regards to a completely different domain: network traffic congestion handling.

The idea hereby is simple, because network bandwidth is limited overall and it is unclear at any given point how many different users are using that bandwidth, your computer would linearly increase the amount of data sent per time unit starting from a very low base line as long as no collision is detected. If things go well, over time you will enjoy a faster and faster connection. However, the rate of data transfer is halved each time a collision is detected. Therefore, it could be viewed as a carefully optimistic approach with strong “insurance” if things don’t go well because it decreases much faster than it increases.

When working together with somebody for the first time, I like to follow a somewhat similar approach. I will carefully try and start by handing off smaller tasks. If that seems to go well, I will keep handing bigger and bigger tasks while taking a more and more hands-off approach. However, if things didn’t go well, instead of slightly correcting, I would get much more involved for a short period of time before gradually handing off again.

I am a fairly optimistic person by nature and time is always limited and probably my biggest constraint. Hence, unless things blow up, I assume they are ok. However, this can mean that problems may remain unnoticed for a bit longer than they ideally should. Therefore, I personally find it to be much better for me to then take stronger immediate corrective action (exponential decrease) if things don’t go well, rather than being too slow in adjusting (linear decrease).

This approach can also work for other areas of management like on-boarding people — you work with them the full first day, then maybe half the second day, spend two hours with them on the third day, one hour on the fourth day and then maybe stick with a rhythm of one hour every 2–3 days if things seem to go well. If there are signs of a problem though, instead of spending slightly more time with them, you immediately spend a LOT more time with them. This in my experience allows for better overall return on time spent, as ultimately problem prevention and early solving almost always ends up being less resource consuming overall than fixing a problem when it as become so big that it can not be ignored anymore.

Whether you chose this kind of heuristic or a different approach certainly depends on your own personality, experience and style. The important takeaway message from my perspective here though is that, again, task delegation and management depends on the particular person you are dealing with and the more time you spend together, the more likely it is for the two of you to develop a good joint working mode.

Conclusion

In this article we started by looking at some of the components of successful task delegation. Based on four specific questions, I tried to show you that often a rich experience and good judgement is required which leads to successful task definition being a somewhat “messy” problem. Being a crucial piece of management, we have seen how task delegation also quickly touches other considerations, introducing additional complexity. However, all said and done — I do believe that by keeping the aforementioned aspects in mind, you can dramatically improve your awareness of what task delegation includes and therefore improve your chances of success over time.

Please feel free to share any questions, insights or other good guiding principles you have found in the comments section below as I also believe that this is an area where everybody can keep learning and there always is further room for improvement (definitely I know that this is the case for myself!)

Four Questions To Ask Yourself For Successful Task Delegation was originally published in Silicon Straits on Medium, where people are continuing the conversation by highlighting and responding to this story.

We started using Slack in August 2014, right when it came out of beta, with 44 users. Less than 2 years later, today, we are at 80 paid users. It’s no secret that we have paid quite a significant amount to Slack to date. What we got in return is a significant productivity gain plus an irreplaceable tool that blends perfectly into our unique culture supporting and reinforcing how we run the team.

Despite its incredible value-add to our process, very often when I recommended paying for Slack to some small medium start up teams, the reaction I got is mostly skeptical: “Why do I have to pay for something that can be used for free!”.

So here’s my attempt to put down some thoughts on how Slack has brought us a lot more value than what we paid for its use in cash. From a non-technical perspective:

The whole team is in one place, that includes clients

By going for premium plan, we can create and restrict access for our guests/clients to be in the same IM tool. Of course, some clients are skeptical at first. But when they actually get on the platform and are able to get in touch directly with the PM/Designer/Developer without needing to know their email addresses or their phone numbers, all the doubts disappear. The friction of communication suddenly becomes minimal.

Even between ourselves, Slack is being used to replace most of the other OTT services (Whatsapp, Viber, Line, FB Messenger). Simply, because everyone has Slack on their smartphone, and it works exactly like any other OTT, if not better. During non-work events like group road trips or weekend casual chatter, people are also using Slack to chat with co-workers instead of other IM platforms.

At the moment, we have more than 60 guests for free! Considering that’s more than half of the number of full team members, and we don’t have to pay for them to enjoy the same productivity as our full-timers, I think we got a damn good deal. You can argue though as some more conservative minds told me, that Skype or Lync could do the same. Not quite, because…

We integrated a whole lot of shit

Skype and Lync and other similar tools don’t offer quite the same openness. In order for this article to not be a sales pitch, I’m not going to go into the regular services you can find on the website. Currently we are at 52 integrations.

When we say Slack is really a big part of our process, it is mostly because we added a lot of cool services as part of daily communication.

Starting with email

Way before Slack had email integration as a standard service, we wrote our own custom email push-to-Slack bot. Using an easy-to-remember syntax with a prefix of ss-[groupname]@siliconstraits.com, we were able to hook up a lot of external communications into one place conveniently.

That means when a PM goes back and forth with clients, the whole team can see the email thread but doesn’t need to be cc’ed. That also means all our billing notifications are pushed into one place and the whole finance department is aware of the charges.

This email automation is more than just convenience. It allows us to keep the flat culture whereby nobody is accidentally left out of the loop.

Subconsciously, all members in a team feel like they know as much as the others and, more importantly, they have all the data points to work with. Minimizing office-politics and saving us from a real hassle and time-sink of context syncing.

Notifications make the whole difference

Like other teams who have been using Slack, the regular stuff helps tremendously. Notifications for when someone is being assigned a task, when a CI build failed, when a bug is detected, when someone pushes code, etc… basically pretty much all the events you can think of can be pushed to Slack.

Here is where Skype and Lync fall short: the flexibility to customize notifications. Personally, I’m in pretty much every private group there is, yet I rarely got overwhelmed by the information stream. I can change my settings separately for phone and laptop to reflect exactly my reading speed on each device.

Whenever a group starts to become too noisy, I re-set the notification such that I only get alerted for certain important keywords, or when my name got mentioned. I can stay on top of things that way and don’t get buried.

We really try to make full use of notifications and set some hard-rules for people to be productive. For instance, after 8pm, no one is supposed to use @group alerting in channels unless it’s emergency or the private group has a consensus. The @here tag is also super convenient for smaller groups, quickly disseminating important message to currently-online users and not being intrusive to offline/resting users.

And then we added more crazy shit

We cater lunch everyday. It used to be a piece of paper menu being passed around. Sometimes it got lost, as you could imagine, sometimes people couldn’t order because they came in late. Now it’s all in Slack.

There is an additional simple back-end page that our admin lady accesses to get the consolidated view before lunch and then places the order manually over phone.

[brag] It took me only 1 day to develop this integration yet the value it has brought to the team and the time saved is simply priceless.[/brag]

Slack’s openness leads to really interesting and creative usage. The tool enables us to convert quite a number of our offline to online processes.

Performance appraisal over Slack

At one point in time, for almost a year, we even had a simple peer-review mini-system over Slack. How it works was very simple. One types “/rate [1–10] [username]” at the end of the calendar month. The system would consolidate the ratings and showed color-coded differences. This immediately allowed management team to identify unspoken issues between two individuals. Again, it is really easy to implement such value-added tools for a team of developers like us. The mini-system has worked so well for us that the data we’ve learnt over the short period allowed us to build a much more comprehensive performance review framework specifically catered to the way we work (we hope to release this framework soon).

The perfect replacement for offices’ water-coolers

If you are unfamiliar with the water-cooler concept, here is a quick definition: it is a common place where impromptu discussions and/or gossip happens, as people have to bump to one another (to get water).

With a giant #public channel, where everyone is in, including our Alumni, no work-related discussion happens, it’s just pure nonsense — the good kind.

Anyone can say anything and everyone can see. It helps greatly given our flat structure: when there are newcomers, a simple announcement pulls everybody in to greet and meet the new guys. It makes everyone equal.

There are other team-focused and work-focus water-coolers, in which team members don’t necessarily have to discuss about work but still somehow relevant to the projects they are in. Usually these exclude management team members so that people can freely speak their mind and get help from others.

And of course, just like any other IM tools, anyone can directly message anyone via 1–1 channel — these different levels nicely reflect our open culture.

Adding the personal touch

As our headcount grew quickly, the challenge was how to maintain and facilitate offline personal interactions between so many people.

Initially, we discovered bonus.ly, a SaaS service with Slack integration. It helps one user to reward another user virtually for anything and for whatever reason. The idea was great and we used it for a while. But as the cost started to scale up, we found that it was time for us to write our own system.

We learnt a lot from bonus.ly and we made several small tweaks to the way reward system works. Instead of a full-flesh web interface, we streamlined everything to command lines. We changed the way messages are defined, remove even more friction to reward someone than before. We reset the allowance every month, and offer conversion to real cash for any team-bonding purpose.

We saved a bit of subscription fee and we have a perfect system that shapes how people are getting rewarded for their offline interaction.

It is amazing to observe that when a kind action is awarded publicly in our common channel, not only it brings recognition to the awardee, but also let others know more about his/her personalities. Personally I didn’t think any online tool could do that but Slack did.

Sum it up

There are other functional utilities to the way we use Slack daily but the ones above are some highlights on how it has helped us build and maintain the cultural dimensions we believe in of the team. I believe as organizations are moving towards a flatter and more open configuration, any small/medium team can benefit greatly by adopting Slack. Whether on a free plan or paid plan, there are ways you can maximize what you get from the service, it just takes a bit of tinkering and creativity.

Here’s why Slack has worked so well for us was originally published in Silicon Straits on Medium, where people are continuing the conversation by highlighting and responding to this story.

Just a quick note for an issue that you might get with Out of Memory in Golang.

As you know, slice in Golang is powerful and easy to use. With build-in func in Golang, it helps us resolving many problem in programming.

But, today, I want to discuss more about slice and its memory.

First thing, the easiest way to create slice is:

When you create a slice, 3 important information will be defined. It consists of a pointer to the array, the length of the segment, and its capacity (the maximum length of the segment).

The length is the number of elements referred to by the slice

The capacity is the number of elements in the underlying array (beginning at the element referred to by the slice pointer)

So, when you create slices with the way I posted above, the length and capacity will be minimum.

We move to the next section, the append function in Golang.

https://golang.org/pkg/builtin/#append

The append built-in function appends elements to the end of a slice. If it has sufficient capacity, the destination is resliced to accommodate the new elements. If it does not, a new underlying array will be allocated. Append returns the updated slice.

The problem that’s we frequently think the append will append new elements to the end of a slice and forget about if we don’t have enough capacity, it will allocate a new slice with different memory space.

And with the simplest ways to create the slice, the capacity always fit with the current element in slice. And unlucky, we see source code that puts function append to a loop or nested loop. Everything’s fine with quick loop, but with bigger loop, the append is nightmare, it’s will eat the memory hungrily.

You can imagine, each loop row will allocate a new memory with higher capacity and it’s not release yet. And we have:

Out of memory

The built-in Golang also supports us to pre-define the capacity, that make the append doesn’t allocate a new memory because of lack of capacity.

So, main idea when I write this post that is I hope we should think more about how memory is manipulated while coding.

And hope this will be helpful for you :)

Out of memory with Append in Golang was originally published in Silicon Straits on Medium, where people are continuing the conversation by highlighting and responding to this story.

Silicon Straits is turning three — it’s only been three short years but so many things have happened. A plethora of interesting projects and products have been built and countless deep and impactful internal and external relationships have been formed. Naturally, we feel a certain sense of pride regarding how far Silicon Straits has come. At the same time however, we are humbled by all the incredible support we have received over the years. Words can not fully capture this but nonetheless we would like to extend a huge THANK YOU to everybody who has been part of this journey.

To celebrate these three years, we want to go beyond a pure thank you post and rather share some of the perspectives and lessons learnt throughout this time.

Hear from Hai An (COO) who shares about organization as a product — a story of how we apply the product mindset to build the structure and culture of our company.

Organization-as-a-product

Kent, our CTO, tells us the story of building and scaling our product team, bringing everyone together.

Looking back and ahead

Jonas (CEO) writes a little bit about planning vs. execution and how this age-old dichotomy is approached at Silicon Straits.

Execution versus Planning: Fire and Water or Yin and Yang?

And finally, James (Executive Chairman) shares about his Ternary Thoughts on the Silicon Straits Tribe — a very personal reflection on how things started and some of the deep-held values.

Ternary Thoughts on the Silicon Straits Tribe

This mixture of topics, styles and perspectives reflects some of the values we cherish at Silicon Straits and what we aim for: diverse, slightly unconventional even bordering quirky sometimes but always honest and with a strong focus on providing value.

Our three-year journey included many transitions. Much has changed, but equally importantly, a lot has stayed the same. Let us take a short moment to watch our short video summarising our story so far:

With all of the above in mind, we would once more like to extend a warm thank you and we are all very much looking forward to the next 3 years!

3-year Anniversary Thanks to Our Friends was originally published in Silicon Straits on Medium, where people are continuing the conversation by highlighting and responding to this story.

Startups are supposed to be dynamic and fast-paced. Environments change, people change, swim or drown — that is the credo. In such chaotic environments, it is no wonder that many startups (and even businesses in general) feel under so much pressure to “do stuff”, that they simply feel like they do not have the time to pause and plan their actions first.

Furthermore, whether looking at business plans or product plans, history is full of examples where grand plans turned out to be terrible ideas when implemented. It is easy, therefore, to believe that planning is a waste of time and it is much better to take an experimental approach of “just do it”. After all, one of the most successful sports companies in the world became very successful with exactly that motto.

At Silicon Straits, we can see a lot of similarities — some of our plans never turn into reality and some of the plans which are implemented turn out to be poor ideas. However, I would argue that the appropriate planning still is essential for success, the key being an understanding of what “appropriate” means.

As one example, almost all of our most successful partnerships and efforts are not the result of a careful multi-year planning approach to business development but rather the result of “one thing leading to another” and “a guy knowing a guy…” In isolation, this might even seem more like luck than skill. However, in reality there is a clear pattern and plan which we work towards in order to keep creating such opportunities.

At Silicon Straits, we keep investing heavily into building our end-to-end product development capabilities. This allows us to enter into a number of complementary partnerships where strong partners can fully rely on us “taking care of the product” while they build the business — each side focusing on doing what they do best. We cannot exactly predict which products we will be building in one, two or five years but we know that we will have the development capabilities to work on impactful products.

With such simple plan in mind, the next crucial step lies in the execution of such plan. For the above example, the execution simply means continuously building different products, sharpening our skills and experience there and learning to identify what the key components are for us to excel and our partnerships to become successful. One important lesson of ours has been that we can provide most value if we fully control the product development process vs just providing part of the engineering, even if as part of a much bigger team. We learn more, improve more and provide more value by taking on end-to-end products instead of just delivering a mobile app for an entire solution, only a small piece of the backend or even just providing a few engineers in a certain technology. Such executional observations go back into our planning which refine the approach. One key requirement hereby is that the transparency in the organisation needs to be high as the different people and stakeholder need to have clear visibility into what’s happening in the different areas.

As can be seen, even though for many people plan and execution have a dichotomous relationship — in our experience, they rather belong closely together and should highly influence each other. This seems to be an increasingly widespread realization and can be witnessed in software development through the movement from the long-haul waterfall approach to rapid smaller bursts of planning and execution through agile methodologies, but also in general business where the traditional 50 page massive business plan is being replaced by smaller, more lightweight planning in order to reduce feedback cycles.

The biggest advantage of such shift is that it allows for optimizing across the three variables that used to be declared as incompatible in traditional academia: time, money and quality. Mistakes are almost always cheapest and fastest to fix if they have not been made yet in the real world, i.e. by identifying them in the planning phase. This helps reduce both development cost and time whilst improving the output quality. We all have found ourselves in situations where we were under so much pressure to get a job done that we ended up trying to force something to work for a whole day, just to realize at the end that had we taken a step back and thought about the problem for half an hour, we probably could have solved it much faster. A little bit of planning can go very far.

The opposite is very true as well though — planning meetings and annual budgets have such a bad reputation with “do-ers” for a good reason. More often than not, they take up so much time with limited useful outcome that everybody is left at the end wondering where all that time went. The incremental return on planning activities rapidly declines. This becomes even more the case as plans take on a longer and longer time horizon. These almost always have to assume certain parameters which are outside of the direct control of the involved parties, yet such parameters are almost never static. Whether you like it or not, todays’ plans are extremely unlikely to remain as good as they seem today during the next months and years. You can ignore this and “stick with the plan” because it was a “good, thoroughly researched” plan. This is what many larger companies can do as the increasing deviations of planned environment versus real environment do not directly threaten their core survival but rather only limit the effectiveness of any planned activities. Yet, we find a far better approach than dismissal or ignorance is to simply accept and even embrace this reality by never assuming a plan to be final. Rather, a plan should be used as a tool to approach a situation and ensure sufficient thought has been put into it without shying away from updating or even scrapping it should the original assumptions prove to be wrong or require changes.

The key to all of this in our experience therefore lies in a few observations:

1. Do not become too busy with “doing” so that you do not have any time left to plan.
2. Do not become too busy with planning so that you do not have any time left to “do”.
3. By cutting down cycle times and improving the feedback loop between planning and doing you can optimize the above balance.
4. Accept and embrace the fact that plans are transient without letting this undercut the importance of planning per se.

Such approach has served us well over our tumultuous past years and has helped take us to where we are today. Despite the plans we have for the future, it would be naive of us to believe they all will become reality no matter what — yet it is the successful balancing of planning and doing that creates rapid change and which we are convinced will continue to lead us into new exciting waters. At least that is our plan!

Execution versus Planning: Fire and Water or Yin and Yang? was originally published in Silicon Straits on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since the day we started at Silicon Straits, we have worked on projects of all shapes, from minimally viable products, to enterprise-grade web and mobile apps, and with partners of all sizes, from individuals and startups to public companies. We consider ourselves to be one of the rare product development companies in Southeast Asia. But Rome wasn’t built in a day. As we scaled our team of 3 to over 70 people in our Ho Chi Minh office over the past 3 years, we have had to change how we did things.

This is the story of our journey in transforming our project and engineering management.

Silicon Straits is not like any traditional company. We did not have a set path for it from the start. It always has been an exciting venture with risks and opportunities. As engineers, we want to build Silicon Straits like a system that could constantly scale and evolve over time. We identify problems, and keep pivoting for better solutions so that it would become better and better, day by day. Even though, we believe there is no system that has no flaw.

We have also attached the engineer mindset into every aspect of our system, from the structure, communication, to the relationship between people. So when things go wrong, we know where to trace for the root of the problems and resolve it.

This system, or you could imagine it like a modern tech product, has two main essential parts that make it work: the back end and the front end. People outside the company cannot see our back end. It is the back office which does all the operation stuff while the front end working with clients. For every projects we have delivered to clients, our front end gets the results and feedbacks, and sends them back to the back end to improve the system. After 3 years of operation, lots of things has happened and our system has changed a lot comparing to the very first version 3 years ago…

The story of our system

I and a few ancient pirates, who has been sticking with us for a long time, were sitting in a small office with a belief that our work one day would bear fruit. Because of the working experience we had shared at previous company, we were close and knew each other well. For the lack of resources, some of us were even working both in the back end and front end of the system. There was time we went to work without anything to do. There was no need to build a model and structure for a team that small. That was the first version of our system three years ago.

Six months later, we reached 30 pirates and started to lose a little bit of control. In order to make everything remain in our orbit, we changed our structure into a dynamic flat model where everyone was like a mercenary, we tackled many projects without forming a real team.

Everything was fine with a little tweak here and there until one year ago. We kept growing larger everyday. More (and ambitious) projects came in, more talented people joined our company. We grew to 50 people. Our back end was facing a challenge seeing that we could not keep track of everything. We could not look after and grow all the pirates like we did before. We knew if we did not do anything, our system would break. We all had the same thought in mind —The old system had to be destroyed to build a new one.

That’s when we restructured our model to squad model (so called version 3.0). We designed it with many connections from people to people, squad to squad, and squad to client.

Each squad is a special force and full-stack with all the roles that they can become a mini-startup themselves. Each squad will figure out what works best for them, based on common process and values. Then they also sharing their best practices with others squad. Most of all, our squads have their own autonomy, hence it boost their creativity and output. With this new model, we were able to tackle those big and crazy projects and continue to scale up the team.

Stay curious, keep tinkering

We are engineers, we are curious about every new things (shiny or not). In the progress of building our system, we have been always looking for interesting tools to make them into features of our system.

From very beginning, we used Slack and Trello for daily communication and working. We tried Bonus.ly and found out that we could make our own Bonus.ly and turn it into a gamification system to help bonding our people and also recognizing their talents, inputs and achievement — in a very engineering way.

We came across many tools, some worked for us and became our system’s features, some didn’t and was left behind. As our venture keeps sailing, we still keep searching for new tools to suit us best.

Not only looking for tools, sometime we also build our own tools, or framework for specific. To keep track of the growth of our pirates, we develop Growth Framework. It helps us grow these talented pirates faster than ever because it keeps track the development of all necessary skills for any specific role.

Let imagine it like Character Profile in any RPGs (Role-Playing Games) that help to see at current level which areas you are strong or weak at (melee, range, magic, sneaking, etc.) Then every quarter, our Squad Lead will review the progress for his/her members based on these profile, which providing constructive feedbacks much easier. This Pirate Profile and Growth Framework is uniquely designed for us, but we believe other startups could use, hence we are working on a version that could be “open-source” in future.

In addition, we also formulate a mechanism for our pirates to calculate their salary based on the Growth Framework, and it’s called Open Salary Formula. This formula help each individual knows how to link between their growth with their compensation. Making it transparent also creates an open culture where everyone could focus on growing themselves knowing that the compensation is the reflection and indicator of their value contributing to the company.

Building v4.0 and beyond

With our Silicon Straits Universe introduced early this year, this would also require another updates to the system. Unlike previous version, we were being forced to upgrade (or die), this time we will be more proactive and prepare in planning for the upgrade.

The joy of a engineer is seeing his product at work, and to us, seeing Silicon Straits growing day by day — not just headcount but the impact we are doing, it’s the ultimate joy. There will be more stories about this special product we are building (good and bad one), so stay tune!

P.S: If you want to be part of this upgrading and our amazing journey, you can check out our Career Page.

Organization-as-a-product was originally published in Silicon Straits on Medium, where people are continuing the conversation by highlighting and responding to this story.

Preamble

As an early-stage investor, entrepreneur and startup executive, I’m most attracted to the ‘magic’ of every company’s first few years after its founding. It’s when momentum (users or clients) is at its weakest, cash (revenue or capital) at its lowest, and talent (founder experience or team) in its shortest supply. Yet, it’s also an era in the company’s history where founders are most courageous, ambitions at its peak and possibilities seemingly endless. With every passing week and month, the founders and their team continue its free-fall off the side of a cliff as it desperately tries to transform the paper it has on hand into a parachute or an aeroplane to avoid joining the carcasses of their predecessors that line the bottom of the chasm they’re falling into.

Most companies don’t make it, but some do. Founders that were responsible for the successes of Apple, Facebook, Google, Tesla, Baidu or Alibaba are more easily recognised and celebrated by mass media — and understandably so — but just as it is when people tell me that Singapore’s past successes cannot be interpreted and applied verbatim to China’s current (and much larger) realities, a smaller success still has a role to play in informing and inspiring its denizens, and hopefully inspire others to do better.

I founded Silicon Straits Pte Ltd in Nov 2012 and consider it more of a ‘Singapore’ than a ‘China’ story. After raising a small seed round in Apr 2013, I co-founded Silicon Straits Foundry with Kent Nguyen and Andy Bui a month later, as a subsidiary of Silicon Straits. We set up our core design and engineering team in Ho Chi Minh City and come May 21, will celebrate its 3rd anniversary as part of the Silicon Straits tribe. Tuan had requested for me to contribute an article as part of the celebrations, so I decided to look back and share additional context and insights.

The Silicon Straits Origin Story

I first posted about Silicon Straits in Nov 2012 on my blog.

Silicon Straits is a tech venture foundry focused on Southeast Asia. We hope to contribute to the growing tech narrative in the region in a big way. We’d love to hear from entrepreneurs, developers, investors, media and neotenous individuals.

Looking back, the meanderings that led me to found Silicon Straits had begun even earlier in 2011, when my seed fund partner Joichi Ito had called me to discuss his MIT Media Lab plans. At that point, our US$5 million ‘Neoteny 2’ fund had not finished deploying our capital and had yet to see any exits. Without another partner with the right profile and track record, I realised I would not be able to raise a new and larger fund and keep going. It would be more than 2 years later before our fund returned more than USD6.7 million from 4 exits out of 24 investments — Viki, Catch, SeatMe and Lanyrd. I did not want to sit on my hands and pretend to the world that I was fully engaged; by mid-2012, most of the investments in our portfolio that we led had already completed subsequent financing rounds and no longer needed active management. I had gotten used to a certain tempo after working with Joi and the founders from our investment portfolio, and was restless.

At Joi’s suggestion, I then spent 4 months in the middle of 2012 hanging out with Pivotal Labs Singapore. Pivotal Labs USA had just been acquired by EMC. As a result, the Singapore office underwent an interesting gear shift after being sold to Digital Garage — of which Joi is co-founder and Board Member of — to form the Singapore arm of what was then known as New Context, which eventually got renamed to Neo. Few people know that pre-EMC Pivotal Labs and Digital Garage are Limited Partners in the ‘Neoteny 2’ fund back in May 2010, and that I’d been a non-executive director of Pivotal Labs Singapore pre- and post-acquisition by EMC. Pivotal Labs set up its Singapore operations shortly after our fund got going. It felt right for me to add to the management bandwidth during this transition period given the context I had, and be helpful . It was interesting to see New Context sell agile software development in the form of paired engineers at SGD2,000 per man day on time-materials basis, as compared to the mainstream fixed scope fixed budget approach. I ultimately didn’t stick around because I felt I was getting in the way of the rest of the management team; I wasn’t full-time but had higher cheque signing limits than the practice lead. He didn’t report to me, nor I to him. I wasn’t fully convinced with how the Singapore office was being managed by New Context HQ in the US, and couldn’t bring myself to make the commitment to go the full 100%. I made a quick withdrawal to avoid turning a full-time role with New Context Singapore into my Vietnam War.

NB: Ironically, in Mar 2015, Neo had shuttered its Powell office after its Edgecase-acquired team had dropped from 33 to 12 people after 3 years. More recently, Neo was acquired by now-EMC owned Pivotal Labs, with Neo Singapore shuttering and joining the Pivotal Labs Singapore team.

I went back to the drawing board. I hadn’t figured out the complete plan, but realised I needed to start somewhere. I decided to take the easiest next step, which was to decide on a new name. The Neoteny brand belongs to Joi; I needed to build my own.

The Silicon Straits Brand

The evolution of the Silicon Straits logo happened over 3 iterations in a year. I had created a crappy word mark in Photoshop in Nov 2012 when I first bought our domain name. I chose the name ‘Silicon Straits’ to represent the spirit of Silicon Valley amidst the Strait of Malacca, an important waterway that touches much of Southeast Asia. It was the first name that came to mind, and only name that stuck.

The second iteration came about after I commissioned a 99designs contest. It lasted for 5 months.

The 3rd and current iteration was produced by outofstock as part of their scope to design our Singapore office that doubled up as a co-working space and fab lab. The double ‘S’ analogy stuck and was further refined, resulting in a simplified double-displaced semi-circle and logo.

By the time I raised our S$512,500 seed round in end-Apr 2013, the description of what Silicon Straits had become:

Silicon Straits is a venture foundry in Southeast Asia that operates at the intersection of ideas, talent & capital and invests in the convergence of design, hardware & software.

Investing in the Convergence of Design, Hardware and Software

I had envisioned two key activities for Silicon Straits; early-stage incubation and investment and product development. I knew what was needed for the former, but needed partners for the latter. I also needed working capital to get started. I had next-to-nothing when we got started.

My first investor was Lim Kia Hong. KH was introduced to me by Grace Chng, and coincidentally stayed just across the road from me. He felt like the business father I never had; the two of us spent hours often into the wee hours of the night swapping notes and discussing ideas for new business. Despite his age (50+) and accomplishments (successful entrepreneur, tech distribution, listed companies, etc), he was young at heart and always gave me sound advice. He knew I needed working capital through our discussions and offered to be my first investor.

My second investor was Dileep Nath. Dileep is the father of Sanjay Nath, one of the 2 partners at Blume Ventures, an India-focused seed fund that were co-investors with me in my ‘Neoteny 2’ fund. Dileep felt like the business grandfather I never had. His smile and gentle demeanour belied the post-40 risky/crazy move of quitting law and co-founding Kanbay, which eventually listed on NASDAQ and was acquired by Capgemini for US$1.25 billion. I believed Dileep to be the antidote to my impatience and was delighted when he agreed to invest.

My third investor was Ivan Lee. Ivan was introduced to me by a common friend and had sold his stakes in Thai Express for US$80 million. He was nearest to me in age and felt like the business brother I never had. He wasn’t as hardcore a geek as I was, but always had an affinity for tech despite starting his career in the F&B industry. He offered to invest without having met KH or Dileep.

My fourth investor was Teruhide Sato. Teru was an investor in my ‘Neoteny 2’ fund with Joi, individually and through the company he founded and listed, Beenos. We’ve known each other since 2010, and he had then just relocated his family to Singapore.

My fifth and final investor was none other than Joichi Ito. It made sense to invite Joi to the party since he was the progenitor of my post-government journey.

With a mere S$512,500 and since Apr 2013 , I oversaw the growth of Silicon Straits into an innovation tribe in Southeast Asia that builds products, companies, foster communities and makes seed investments. Today, the Silicon Straits tribe has a team of over 70+ across offices in Singapore and Ho Chi Minh City, and oversees US$15 million in early- stage investments. Apart from the remaining portfolio in my ‘Neoteny 2’ fund with Joi, Silicon Straits is a shareholder in companies such as SmoothOps, Burpple, Livi, Caarly, Hipvan, Ztore, GreyOrange, Neoteny 3 and Carro. Unlike a proper venture fund, we make between 2 to 4 investments a year ranging from $20K to 50K a pop. We’re not really investing a lot, but that’s because we’re doing it entirely from our parent company’s balance sheet, and need to juggle the allocation between working capital to fund growth and our investment allocation.

Operating at the Intersection of Ideas, Talent & Capital

I first met Kent Nguyen in 2011 when he was an engineer at Anideo. I had actually met his twin brother Torin Nguyen slightly earlier, when Torin was hired by bunnie as one of Chumby Industries’ first engineers in Singapore. Kent had been introduced to me by AJ Solimine as the ‘hotshot developer from Vietnam’ on the newly formed Anideo team, backed by Eduardo Saverin.

I reconnected with Kent in December 2012 when I was doing my rounds to identify a suitable CTO. By then, Kent had left Anideo and was spending his time between Singapore and Ho Chi Minh City. He was the most compatible CTO I had dated over that 2-month period. I learnt that he had a small team of 3+ in Ho Chi Minh City under TGM Tech supporting the tech needs of its parent company TGM Holdings, which had been formed by ex-NUS graduates from Vietnam. I’ve always found the Vietnamese to possess amazing work ethics and a thirst for exposure and knowledge. I visited Kent and his partner Andy (Bui Hai An) at the Ho Chi Minh City downtown office they had shared with 2359media; it wasn’t much, but between Kent and Andy, I spotted the beginnings of something and managed to convince them to leave TGM and join forces with me to co-found Silicon Straits Foundry. Everything moved at light-speed after that.

I invested the startup capital required out of Silicon Straits, contributed my entire business network of contacts and prospective clients and worked with Kent and Andy to move our Vietnam operations into our District 7 office, at the same time that I was renovating our Singapore office. Those were crazy times; I was responsible for sales and business development, while Kent was responsible for engineering and project management and Andy was overseeing business and people operations. The relationships I’ve garnered since my IDA and Neoteny Labs days ensured that we’d never need sales people, and saw us growing our Vietnam team from 3 to 30 in 6 months, and then to 40 and beyond by the end of our 12th calendar month of operations. We’ve had to tear up our plans and change our processes several times in order to cope with growth. We’ve made mistakes and learnt from them in our hiring and people operations. We’ve had amazing customers who came and stayed with us as we raised our man day rates from S$150 per man day to S$350 per man day (and up).

Despite keeping the team entirely in Ho Chi Minh City, or Saigon as I’d affectionately call the city, Silicon Straits Foundry became our playground to foster design, hardware and software tinkering while retaining sufficient organisation to deliver MVPs to individuals, bootstrapped or funded startups, or scalable mission-critical enterprise software to large organisations across Southeast Asia. We took on straight consulting jobs that were at our usual man day rates. We experimented with cost-plus and equity hybrid models to partake in the risk and upside of our partner-clients. We even developed and launched two SaaS products for the Vietnam market, and invested design and engineering resources to launch an Uber-for-household services play in Hanoi and Ho Chi Minh City, only for our operating partner to try to screw us of our shares and IP (to his detriment). It didn’t always work, but we learnt from our mistakes and failures and scored some pretty big wins along the way, with clientele like SingPost eCommerce (vPost), Starhub, Bluebird, 7-Eleven Indonesia and 7-Eleven Vietnam.

The Next Lap

I stayed at the operating helm as CEO for over 2 years before appointing Jonas Eichhorst as my replacement in Aug 2015. I assumed the role of Executive Chairman and focused on the meta- and macro- aspects of Silicon Straits’ proverbial next lap.

Apart from spending 80% of my time as Vice President (International) at GreyOrange since 1 Jun 2015, helping Samay Kohli and Akash Gupta with building out GreyOrange’s Asia Pacific team and entry and expansion into the markets of Southeast Asia, Japan, China, Taiwan and Korea, I’ve been pondering upon our tribe’s future. Indonesia has always been an interesting market for us. We’re set for our highest-ever multi-million revenue year come 31 December 2016 and are on track for our third profitable year of operations as a group. Consulting is but a means to an end, and we’re starting to see some long-awaited validation in the form of the tech architecture, design and product development work we’re doing for 7-Eleven Vietnam and Bluebird Indonesia. How this shift from software engineering towards product development can take on further purpose and scale, is something I challenge every one of our tribe members to take on and contribute towards.

NB: One of our Vietnam tribe members had a sudden stroke on 21 Mar 2016 and passed away unexpectedly. He has been with us since almost the beginning of our journey, and it was a big emotional blow to the Saigon team. He was 24.

On our 3rd birthday this coming weekend, I wish us all happy celebrations. To Khoa, may you rest in peace and be in a better place. You will be dearly missed by one and all.

Ternary Thoughts on the Silicon Straits Tribe was originally published in Silicon Straits on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quincy Larson chỉ là một “anh chàng công sở”. Một ngày nọ, anh ta quyết định mình muốn học code. Anh hỏi ý kiến mọi người xung quanh. Thế rồi, anh bắt đầu với một chút Ruby và lướt qua vài ngôn ngữ như Scala, Clojure và Go. Anh học Emacs rồi đến Vim và ngay cả Dvorak keyboard layout cũng không chừa. Anh chọn Linux, vọc Lisp và viết code Python trong khi sống chung với command line hơn nửa năm.

Như một chiếc lá vật vờ giữa cơn bão, mỗi lời khuyên thổi bay Quincy từ ngã này sang ngã khác cho đến khi anh học hết “mọi khoá học online có thể nghĩ đến”. Đến cuối cùng, dù đã có được một công việc trong lĩnh vực phát triển phần mềm, Quincy:

… tin chắc rằng những lập trình viên trông có vẻ bình thường mà tôi gặp thực ra là những kẻ điên đã từng trải qua, xong lại bị đàn áp, bởi những tổn thương khi học code.

Bạn có cảm thấy điều này rất quen không?

Giai đoạn I: Trăng mật tay trong tay

Thật khó để đổ lỗi cho những ai mang theo những kì vọng quá cao khi đến với cái nghề lập trình.

Một mặt, bạn nghe những lời đồn đại sự khó khăn đáng sợ của lập trình từ lúc còn nhỏ, như những câu chuyện mà người lớn hay hù doạ trẻ nhỏ để chúng đi học những ngành khoa học xã hội.

Mặt khác, hiện tượng “Learn to Code” đã tạo nên một chuyển biến tuyệt vời khi phá vỡ những rào cản và cho mọi người thấy rằng lập trình thực ra cũng khá vô hại. Những công cụ như Codeademy, Treehouse và Code School xuất hiện với những cử chỉ thân thiện đảm bảo ngay cả bạn (à không, tất cả mọi người!) không chỉ học code mà còn trở thành một developer thành thạo.

Bất ngờ thay, vấn đề ở đây không phải là nỗi sợ khi học lập trình, mà là những hi vọng và kì vọng thái quá.

Hơn nữa, trong hầu hết câu chuyện, những công cụ mở đường này làm rất tốt việc dẫn dắt bạn như một đứa nhóc băng qua con đường với những thứ đáng sợ như biến, lệnh điều kiện và căn bản của cú pháp lập trình. Khi bạn chinh phục hết thử thách này đến thử thách khác như những trò chơi, sự tự tin của bạn tăng lên. Bạn nghĩ rằng sau tất cả chuyện này, bạn có thể làm được! Nó khó như thế nào chứ? Chẳng mấy chốc bạn sẽ sớm trở thành một developer thôi!

Vấn đề là ở đây, bạn đang trong giai đoạn mà tôi gọi là “Trăng mật tay trong tay”. Mặc dù bạn có thể cảm thấy như điểm cuối của chặng đường ở đâu đó quanh đây, nhưng bạn thực sự chỉ mới đi được vài bước của cả quãng đường. Mọi thứ chỉ mới bắt đầu…

Biểu đồ minh hoạ cuộc hành trình phía trước

Trước khi chúng ta đi sâu vào Giai đoạn II, hãy nhìn một bức tranh lớn hơn.

Trong bài viết này, tôi sẽ dẫn bạn đi qua bốn giai đoạn của cuộc hành trình học code và những điều bạn cần làm để sống sót vượt qua chúng. Bạn cũng sẽ thấy làm thế nào hai yếu tố chính mật độ tài nguyên và phạm vi kiến thức cần thiết, quyết định cuộc hành trình này.

Chuyến viễn du để đến được giai đoạn sẵn sàng cho công việc có thể được vẽ nên từ sự thay đổi mức độ tự tin của bạn khi năng lực của bạn ngày phát triển.

Đây là một mối quan hệ tương quan bởi sự tự tin của bạn có liên hệ với niềm vui của bạn, và khi sự tự tin và năng lực của bạn giao nhau cũng là thời điểm bạn chính thức “sẵn sàng cho công việc”.

Chúng ta sẽ đi vào những thử thách đặc biệt của ba giai đoạn còn lại chốc nữa thôi, nhưng đây là những thứ mà chúng có dính dáng với nhau:

1. Trăng mật tay trong tay là quãng thời gian vui vẻ khi mà các khoá học trực tuyến hướng dẫn bạn vượt qua những bài học tưởng chừng như khó khăn nhưng hoàn toàn có thể thực hiện được nhờ sự hỗ trợ của chúng. Bạn sẽ chính thức học những cú pháp cơ bản nhưng cảm thấy vô cùng hài lòng với thành quả đạt được.
2. Dốc mơ hồ là khoảnh khoắc bạn đau đớn nhận ra rằng mọi thứ thật khó khăn khi quãng thời gian trăng mật chấm dứt và nó cho bạn cảm giác bạn không thể làm tất cả mọi chuyện bằng chính sức mình. Những thách thức chính mà bạn gặp là liên tục sửa lỗi và không biết nên đặt câu hỏi nào cho hợp lý khi bạn chiến đấu để đạt được bất kỳ nguồn động lực để tiến tới.
3. Sa mạc tuyệt vọng là một hành trình dai dẳng và đơn độc đi qua vùng đất chưa từng được khai phá, nơi mỗi hướng đi mới đều trông như đúng đắn nhưng bạn thường đi quanh quẩn và cảm thấy đói khát những nguồn tài nguyên có thể giúp mình vượt qua nơi hoang vu này. Hãy cẩn thận với những “ảo ảnh sa mạc”, chúng như những bài hát cám dỗ bạn xuống địa ngục.
4. Cất cánh ngoạn mục là thời điểm bạn cuối cùng cũng tìm thấy con đường băng qua sa mạc và kết nối mọi thứ về cách xây dựng và phát triển ứng dụng. Nhưng code của bạn vẫn còn bị giấu kín và mỏng manh như một ngôi nhà giấy. Bạn có được tự tin bởi vì ứng dụng của bạn chạy được, bạn đã thành thạo vài phương pháp thông dụng. Bạn bè của bạn nghĩ rằng giao diện của ứng dụng thật tuyệt nhưng bạn lại sợ hãi khi nhìn vào bên trong nó và bạn không biết làm thế nào để có được code “thành phẩm” (production ready). Làm thế nào bạn rút ngắn khoảng cách để có một công việc thực sự?

Tôi đã phỏng vấn hàng trăm developer đầy tham vọng vài năm trước đây và nghe cùng một câu chuyện lặp đi lặp lại. Mục đích của tôi khi thực hiện bài viết này là giúp bạn tiếp cận cuộc hành trình học code thật cẩn thận, lên kế hoạch đầy đủ và tránh phải rơi vào những cái bẫy thường gặp mà những người đi trước mắc phải.

Bây giờ thì chúng ta quay lại Giai đoạn II…

Giai đoạn II: Dốc mơ hồ

Vậy là, bạn đang ở Giai doạn I — “Trăng mật tay trong tay”, kiểm tra đống huy hiệu và những thử thách đã hoàn thành khi sự tự tin và năng lực của bạn đang tăng lên. Chuyện này cũng không tệ lắm… chả có chút khó khăn nào. Bạn chạm đến “Đỉnh cao của sự hào hứng phi lý” (Peak of Irrational Exuberance)…

Hãy cẩn thận! Bạn sắp bước qua cái ngưỡng làm sụp đổ bao kẻ hiếu học và bị tống vào khu vực “học code khó quá”. Thời điểm chính xác chuyện này xảy ra là khoảnh khắc đầu tiên bạn ngồi xuống trước máy tính, mở trình soạn thảo, và thử xây dựng một project từ con số không mà không có sự trợ giúp nào từ trình duyệt, những đoạn code có sẵn hoặc những gợi ý hữu ích.

Chết thật!!!

Bạn có thể cố gắng kéo chút hơi tàn bằng cách làm theo các bài hướng dẫn (tutorial), nhưng không ai có thể chạm được bầu trời mà không rời khỏi mặt đất, và, đến một lúc nào đó, bạn sẽ phải tạo ra điều kì diệu chỉ từ một tập tin rỗng. Bạn đã bước vào giai đoạn thứ hai, nơi mà sự tự tin rơi thẳng xuống mặt đất — “Dốc mơ hồ”:

Rồi bạn cũng bắt tay vào làm. Bạn chiến đấu và lần mò ra giải pháp chỉ vừa đủ các tính năng nhưng có gì đó vẫn còn thiếu. Cuộc chiến của bạn với các “con bọ” (bugs) căng thẳng đến nỗi ngay cả phim Starship Troopers trông cũng hết sức bình thường. Bạn cảm giác mỗi một chiến thắng đều nhờ vào công sức của anh cả Google và sự tự tin của bạn tụt dốc thê thảm.

Đây là giai đoạn đặc biệt bực bội đối với cả người huấn luyện cũng như tất cả học viên. Lập trình có lẽ không phải là một nghề hoàn hảo cho tất cả mọi người, nhưng chúng tôi muốn bạn tiến bộ bởi vì đôi khi những điều bất hợp lý trong câu chuyện có thể trở thành những điểm nhấn thành công nhất.

Khi khoảnh khắc tay trong tay kết thúc, các học viên bị dồn đến bờ vực và bị yêu cầu phải nhảy xuống, nhiều người tuyệt vời đầy tiềm năng va đập vào những tảng đá thất vọng mà không học được cách để cất cánh bay lên.

Điều đáng sợ là bạn vẫn chưa được chạm đến những thứ thú vị. Giai đoạn thứ hai này, Dốc mơ hồ, vẫn còn rất sớm trong cả cuộc hành trình. Một khi bạn cuối cùng cũng tiêu diệt đủ “bọ” để chấm dứt tai hoạ thứ tám của Ai Cập và hoàn thành một vài project — đánh dấu sự chấm dứt của Giai đoạn II — bạn vẫn chỉ vừa mới bắt đầu.

Đối với những ai thực sự sẵn sàng tìm kiếm một công việc, sống sót vượt qua Dốc mơ hồ thường là thời điểm bạn quyết định bắt đầu một cuộc sống mới. Nhưng vẫn còn rất nhiều thứ. Và, thật không may, bạn chỉ mới bước vào “Sa mạc Tuyệt vọng”.

Hai yếu tố đóng vai trò quan trọng trong tất cả mọi chuyện

Vậy cái gì thực sự tạo nên khác biệt giữa một giai đoạn và giai đoạn sau nó? Tại sao Giai đoạn II (Dốc mơ hồ) lại kinh khủng so với Giai đoạn I (Trăng mật tay trong tay)? Hiểu ra chuyện này sẽ giúp bạn nhận ra rằng đó không hẳn là lỗi của bạn nếu như cuộc hành trình của bạn giống như những gì tôi vừa mô tả.

Nói một cách đơn giản, có hai yếu tố chính trong mỗi giai đoạn: Mật độ Tài nguyên và Phạm vi Kiến thức. Cùng xem chúng là gì trước khi chúng ta đi vào khám phá chúng quyết định Giai đoạn III như thế nào.

Yếu tố 1: Mật độ Tài nguyên

Như tôi vừa nói ở trên, khi bạn vừa mới bắt đầu, dường như có hàng triệu nguồn tài nguyên ở ngoài kia cố gắng lôi kéo bạn vào con đường viết code. Quả thật đúng như vậy!

Thử tìm kiếm từ khoá “Learn to Code” và bạn sẽ bị đập vào mắt một đống thứ hữu ích như công cụ, trình soạn thảo, videos, và bài hướng dẫn. Bất ngờ hơn nữa, chúng cũng rất tốt! Từ trước đến nay tôi chưa từng thấy có nhiều phương pháp để bắt đầu học code như vậy.

Nhưng thật không may, vào các giai đoạn sau, mật độ tài nguyên cũng thưa thớt dần. Bất cứ ai nhảy từ lính mới sang sĩ quan có thể nhận ra sự khác biệt to lớn giữa nguồn tài nguyên hiện hữu khi bạn mới bắt đầu so với khi bạn lần đầu tiên tìm kiếm sự giúp đỡ để phát triển những thứ của riêng bạn mà không cần sự hỗ trợ của các khoá học.

Vấn đề này càng thể hiện rõ ràng hơn khi lượng kiến thức cũng tăng nhanh chóng mặt khi bước vào Giai đoạn III, và đây là một trong những lý do mà chúng tôi gọi đó là giai đoạn “Sa mạc Tuyệt vọng”. Một khi bạn vượt qua giai đoạn này và bắt đầu trở nên thoải mái với những thứ bạn cần tìm kiếm, nguồn tài nguyên quay trở lại và bạn có thể học hỏi từ nhiều công cụ kĩ thuật như các blog công nghệ và screencasts. Một phần trong đó là hiểu ra cách đặt câu hỏi như thế nào.

Mật độ tài nguyên sẽ trông như thế này ở từng giai đoạn (càng nhiều đường gạch cho thấy có nhiều tài nguyên hơn):

Yếu tố 2: Phạm vi kiến thức

Bây giờ chúng ta sẽ nói về một yếu tố quan trọng khác — Phạm vi Kiến thức. Dưới đây là hình minh hoạ độ rộng của các chủ đề chính mà bạn phải học ở mỗi giai đoạn. Nó trông như thế này:

Khi mới bắt đầu học, những điều bạn cần biết khá ít. Tất cả mọi người bất chấp mục đích, ngôn ngữ, bối cảnh đều phải tìm hiểu vòng lặp for dùng như thế nào, làm sao để xây dựng các điều kiện logic, và các cấu trúc cơ bản của cú pháp lập trình. Thậm chí cũng chẳng có mấy bài học nền tảng ở giai đoạn này vì thế Phạm vi Kiến thức cũng rất hẹp.

Ngay khi bạn học xong những điều cơ bản, bạn thấy sự mở rộng nhanh chóng của Phạm vi Kiến thức khi bạn bắn đầu tìm hiểu những thứ khó hơn như hiểu các lỗi xảy ra và khi nào thì sử dụng những đoạn code mà bạn biết cách sử dụng. Bắt đầu có chút khác biệt ở đây bởi vì không có câu trả lời “chính xác” cho một câu hỏi… mọi thứ trở nên mờ mờ ảo ảo.

Khi bạn tiến vào giai đoạn ba, quả bóng kiến thức càng to hơn nữa. Bạn lúc này phải biết công cụ nào dùng cho mục đích nào, ngôn ngữ nào phải học, nắm vững kiến thức Khoa học Máy tính nền tảng, cách viết modular code, lý thuyết hướng đối tượng, cách viết code tốt, và làm thế nào để tìm được trợ giúp (đây chỉ là vài cái bạn phải biết). Mỗi lần viếng thăm Google hoặc Hacker News đưa bạn xuống một hang động kì bí khác và nhiều thứ dồn dập đến mà bạn chẳng biết chúng là gì nhưng có cảm giác là bạn cần phải biết về chúng.

Bạn không biết những cái bạn không biết.

Chỉ khi cuối cùng bạn lần ra vài manh mối và tìm được con đường rời khỏi sa mạc, phạm vi kiến thức cũng bắt đầu hẹp lại. Khi ấy, bạn tìm thấy công nghệ bạn lựa chọn và vị trí của nó trong ecosystem. Bạn cuối cùng biết được những cái bạn không biết và lên kế hoạch vượt qua nó. Bạn sẽ tiếp tục cần nhiều sự tập trung hơn nữa khi bạn tiến về phía trước và bắt đầu công việc mới của mình.

Giai đoạn III: Sa mạc Tuyệt vọng

Sau khi hiểu thấu những yếu tố này, bạn có thể thấy rằng Dốc mơ hồ thật ra chỉ là một ngã rẽ. Hậu quả gây ra do sự kết hợp kinh khủng của sự gia tăng chóng mặt Phạm vi Kiến Thức và sự thiếu hụt Mật độ Tài nguyên là thứ mà tôi gọi là “Sa mạc Tuyệt vọng”

Về bản chất, sa mạc này là nơi bạn nhận ra là ở đâu đó có điểm cuối bạn cần tìm nhưng bạn không biết cách để đến được đó.

Cuộc hành trình băng qua sa mạc dài dăng dẳng và đầy rẫy hiểm nguy. Bạn sẽ thấy bản thân bị cám dỗ bởi các “Ảo ảnh Sa mạc” trong suốt chặng đường — hàng tá nguồn tài nguyên hấp dẫn xuất hiện tưởng chừng như nắm giữ lời giải cho những gì bạn đang tìm kiếm nhưng chúng lại làm bạn thất vọng, một lần nữa, tại cái nơi mà chỉ có cát và cát kéo dài suốt tận chân trời.

Có thể bạn sẽ đăng ký vài khoá học MOOC ở Coursera hay Udacity hay edX. Hoặc bạn tìm thấy một bài hướng dẫn có mục đích giúp bạn đi hết chặng đường. Bạn từng nghĩ mình đã học được bài học của giai đoạn Trăng mật tay trong tay — không có câu trả lời nào dễ dàng — nhưng sự dụ dỗ được giải thoát quá to lớn và bạn rơi vào lời hứa rằng thứ này sẽ giúp bạn đến đích mà những chỗ khác không thể làm được.

Bạn không thể học tất cả điều này chỉ trong một tuần, một tháng hoặc một khoá học dù cho bất cứ ai nói gì đi nữa, vì thế đừng mắc bẫy!

Có rất nhiều thứ phải học hơn bạn nghĩ đấy. Thậm chí nếu bạn có thể làm vài ứng dụng chạy được, rất khó để không phải cảm thấy lạc lối trong một kế hoạch lớn hơn để trở thành một chuyên gia đích thực. Thật khó để đo được tiến bộ của bạn. Làm thế nào bạn biết được mình cần học gì hay những thứ bạn học có chính xác không?

Thậm chí ngay cả khi bạn nhắm đúng hướng, vẫn rất khó khăn để biết được tiến độ của mình. Bạn có thể cảm thấy hoàn toàn lạc lối cho đến khoảnh khắc khi bạn nhận ra cuối cùng mình cũng có thể xây dựng thứ gì đó trông ổn và chạy được như mình mong đợi. Nhưng, với đầy đủ điều kiện và một chiếc la bàn tốt, bạn thậm chí có thể tung ra vài project “thực sự” đầu tiên và bạn nhận ra bạn cuối cùng cũng đã hiểu.

Chắc chắn là mọi việc đến giờ luôn khó khăn, nhưng có thể công việc phát triển web cũng không đến nỗi tệ lắm… Hãy suy nghĩ tích cực chút xíu đi nào!

Giai đoạn IV: Cất cánh Ngoạn mục

Bạn đã vượt qua sa mạc và sự tự tin trong bạn đang tăng lên. Kĩ năng Google của bạn trở nên xuất sắc và bạn cuối cùng có thể hiểu được những bài blog dài ngoằn và cả screencast nữa. Có thể bạn đã đi sâu vào một ngôn ngữ cụ thể hoặc framework và bạn cảm thấy tự tin khi có thể xây dựng và công bố một ứng dụng đầy đủ tính năng.

Đây là khoảnh khắc “Cất cánh Ngoạn mục”:

Mọi thứ trông ổn ở bên ngoài nhưng bạn biết rằng ở tận sâu thẩm bên trong bạn vẫn chưa xong.

Bạn có thể làm cho ứng dụng đó chạy nhưng chuyện gì đang diễn ra ở bên dưới? Code của bạn đầy rẫy chắp vá, và tệ nhất là bạn thậm chí còn không biết chỗ nào không ổn. Sự thông minh sáng suốt của bạn bị chống trả bởi những lỗi vụn vặt và, tệ hơn nữa, một sự nghi ngờ len lỏi khi bạn thâm chí còn không biết là mình đang làm gì.

Đây là một giai đoạn lưỡng cực. Bạn cảm giác như một nửa của bạn là một lập trình viên được trang bị đầy đủ và một nửa kia là một tay gà mờ dấn thân vào một nơi quá sâu vì bị che mắt. Bạn càng tiến bộ lên, bạn càng cảm thấy cảm giác nhộn nhạo không chắc chắn lớn lên khi có ai đó sẽ chỉ ra bạn là một kẻ bịp bợm.

Bạn cảm giác như bạn đã trở thành một lập trình viên nhưng khoảng cách giữa code bạn viết và sản phẩm của một “chuyên gia” không có chỗ nào liên quan với nhau…

Nhưng đến cuối cùng, bạn sẽ làm được! Đã có rất nhiều lúc bạn tưởng chừng như không làm được rồi! Sa mạc Tuyệt vọng đã ở phía sau và Dốc mơ hồ chỉ là một ký ức xa xăm. Bạn cuối cùng, thực sự, bắt đầu cất cánh. Bạn học hỏi nhanh hơn và thông minh hơn bao giờ hết và, cuối cùng, bạn tiếp thu những giải pháp tốt nhất để đống kiến thức lộn xộn của bạn kết hợp lại thành bộ kĩ năng cần thiết cho công việc.

Giai đoạn Cất cánh Ngoạn mục luôn luôn tốn nhiều thời gian hơn bạn nghĩ và cảm giác dai dẳng hiện hữu bởi vì bạn đã đến quá gần đích… nhưng trước sau gì bạn cũng sẽ đặt chân đến. Nếu bạn đủ kiên trì theo những cách đúng đắn, bạn sẽ thuyết phục ai đó trả tiền cho bạn để bạn tiếp tục học hỏi. Công việc là của bạn.

Làm sao để sống sót vượt qua cuộc hành trình này?

Cuộc hành trình này thường sẽ vô cùng khốc liệt. Điều quan trọng là bạn hiểu được mình sẽ đối mặt với những gì, nếu như bạn muốn làm điều này một mình. Nhưng bạn không cần phải làm vậy. Có nhiều lối tắt để giải quyết những vấn đề này. Học code không quá dễ như mọi người lầm tưởng nhưng cũng không quá khó như trong sâu thẩm nỗi tuyệt vọng của bạn.

Dưới đây, tôi sẽ giới thiệu một số chiến thuật quan trọng bạn có thể sử dụng để luôn giữ mình tiến về một hướng đúng đắn.

I: Sống sót vượt qua giai đoạn Trăng mật tay trong tay

Sự phong phú của những nguồn tài nguyên hiện có trong giai đoạn Trăng mật tay trong tay khiến cho nó khá thú vị. Họ đã làm rất tốt khi giúp bạn hình thành một lối suy nghĩ logic bạn cần cho những giai đoạn sau này. Đây là giai đoạn tuyệt vời để bắt đầu học code vì thế cứ thưởng thức nó và lưu ý hai điều sau:

1. Bắt đầu bằng việc thử các nguồn tài nguyên khác nhau để tìm ra bạn học tốt nhất ở nơi nào và những loại project nào tạo hứng thú nhiều nhất cho bạn. Đó có thể là Khan Academy với những thử thách ngắn, các bài thực tập ngay trên trình duyệt của Codecademy, quyển Learn to Program của Chris Pine hoặc trải nghiệm thú vị try Ruby của Code School. Nếu bạn có hứng thú với javascript thì FreeCodeCamp cũng là một lựa chọn không tồi. Hãy cởi mở khi bắt đầu và phớt lờ suy nghĩ bạn nên học những gì… tất cả code đều như nhau ở giai đoạn này.
2. Sau đó chọn một và bám lấy nó khi bạn đã tìm ra cái nào phù hợp với mình. Hãy hoàn thành các bài học giới thiệu của họ, chúng sẽ cung cấp những kiến thức cơ bản để bạn có thể viết những đoạn mã hoặc ứng dụng đơn giản. Sau đó hãy sẵn sàng bắt đầu xây dựng những thứ của riêng bạn.

II: Sống sót vượt qua giai đoạn Dốc mơ hồ

Hầu như tất cả mọi người sẽ trải qua Dốc mơ hồ bởi vì cách duy nhất để trở thành một developer là… develop. Bạn có thể giả vờ xây dựng một cái gì đó dựa theo các hướng dẫn (hoặc các bài hướng dẫn mạo nhận là các khoá học “hoàn chỉnh”), nhưng bạn chỉ đang cố lẩn tránh mà thôi. Các bài hướng dẫn là một cách tốt để làm quen một chút với những kiến thức nâng cao nhưng bạn sẽ cần phải chấm dứt sự ỷ lại này và đối diện với hiện thực vào một lúc nào đó.

Ba gợi ý giúp bạn chuyển sang xây dựng những thứ của riêng mình:

1. Làm chung với người khác, thậm chí dù người đó cũng là lính mới như bạn. Bạn sẽ ngạc nhiên mọi chuyện dễ dàng hơn biết bao khi debug những lỗi vô cùng khó khi có nhiều hơn hai con mắt.
2. Đọc code của người khác để làm quen với cách viết code tốt. Cố gắng hiểu tại sao tác giả đoạn code đó lại làm như thế. Bạn không thể trở thành một tiểu thuyết gia mà không đọc một quyển sách nào, đúng không? Hãy luôn quan sát cách các developer khác giải quyết những vấn đề hoặc project nhỏ.
3. Bắt đầu nhỏ và phát triển liên tục. Bạn nên có các project lớn thú vị cho tương lai, nhưng bạn cần phải quen thuộc với việc debug và tìm kiếm các nguồn tài nguyên có những thử thách tương đối. Chẳng có cách nào khác có thể thay thế được kinh nghiệm.

III: Sống sót vượt qua giai đoạn Sa mạc Tuyệt vọng

Một khi bạn đã quen thuộc với công việc debug, vấn đề lớn nhất của bạn là sự đòi hỏi của một lượng lớn kiến thức và bạn hoàn toàn lạc lối khi không biết làm thế nào để học được tất cả chúng… đây chính là Sa mạc Tuyệt vọng. Trong trường hợp này, cái bạn cần là một sự kiên định tiến về phía trước. Ảo ảnh Sa mạc thể hiện ở những ngã rẽ thú vị, những hang động chằn chịt và những chương trình học-nhanh-kĩ-năng-X, tất cả chúng đều lãng phí thời gian của bạn.

Đây là những lưu ý giúp bạn thoát khỏi Sa mạc Tuyệt vọng:

1. Có một mục tiêu mạnh mẽ cho thứ bạn muốn đạt được bởi vì nếu không bạn sẽ lẩn quẩn học những thứ thú vị nhưng chẳng mang lại ích lợi nào cả. Nếu bạn có thời gian rảnh, hãy bỏ qua những thứ này…
2. Tìm một con đường chắc chắn trực tiếp dẫn bạn đến mục tiêu bạn đặt ra và xác minh là nó thực sự sẽ giúp bạn đến đích. Đây là lúc bạn cần đào sâu hơn bên dưới những khẩu hiệu marketing và những gương mặt rạng rỡ trên các website hoặc bìa sách và hỏi bản thân rằng “liệu thứ này có giúp mình hoàn thành mục tiêu mình đề ra?”
3. Tập trung và tránh các quấy nhiễu, bởi vì nếu bạn là loại người có hứng thú với việc học code, bạn cũng là loại người hứng thú với mọi thứ thú vị. Khi cảm thấy khó khăn khi code, bạn cần phải tiếp tục tiến tới thay vì thử nghiệm mấy thứ trông có vẻ hay ho.

Nếu bạn có thể tìm ra một con đường và đeo đuổi nó, bạn cuối cùng sẽ tiến vào giai đoạn tiếp theo thay vì lãng phí nhiều tháng hoặc mấy năm trời theo đuổi những ảo ảnh trên các đồi cát của sa mạc.

IV: Sống sót vượt qua giai đoạn Cất cánh Ngoạn mục

Cất cánh Ngoạn mục là giai đoạn chuyển giao khó khăn nhất. Bạn có thể phát triển ứng dụng nhưng bạn thực sự muốn trở thành một web developer. Vượt qua giai đoạn này và đạt được các yêu cầu của công việc, bạn cần làm ba việc sau:

1. Tìm và làm theo các best practice trong lập trình. Bạn cần hiểu sự khác nhau giữa một giải pháp và giải pháp tốt nhất. Best practice là sự khác biệt lớn nhất giữa hacking và xây dựng một đoạn code chất lượng.
2. Kiểm tra lại kiến thức của bạn bởi vì bạn có thể bỏ lỡ vài lỗ hổng mà ngay cả bản thân bạn cũng chẳng biết. Bạn cần kiểm tra và khắc phục những lỗ hổng này.
3. Khắc phục những kĩ năng không hấp dẫn mà thường ngày hiếm khi được chú ý đến nhưng vô cùng quan trọng trong giai đoạn chuyển tiếp trở thành một chuyên gia. Những kĩ năng này bao gồm testing, data modeling, architecture và deployment, những thứ rất dễ bỏ sót nhưng hoàn toàn là nền tảng.

Yếu tố quan trọng để đạt được những việc này và vượt qua giai đoạn Cất cánh Ngoạn mục là nhận phản hồi. Tự học có thể hiệu quả nhưng code của bạn hiếm khi dễ đọc, chia thành từng phần, và dễ maintain, đây là những thứ cần thiết khi đi trên con đường lập trình chuyên nghiệp. Bạn cần làm việc với những người khác, những người sẽ thách thức kiến thức của bạn, đặt những câu hỏi khó khăn, và bắt bạn phải vá những lỗ hổng kiến thức của mình.

Hi vọng bạn sẽ thành công trên cuộc hành trình trở thành một developer của mình!

Biên dịch từ bài viết Why Learning to Code is So Damn Hard.

Tác giả: Nguyễn Giáp Hồng

Hành trình học code và Bí quyết để sống sót was originally published in Silicon Straits on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introducing the Silicon Straits Universe — where great people build great products to help create great companies.

This vision connects and guides us through all the dots we have created over the past few years after building over a hundred products all around the world with more than seventy people working at our core now (plus many many more in affiliated businesses).

Through various projects and products built directly in our foundry, we go way beyond conventional outsourcing and instead regularly form deep collaborations. This typically involves partnering with individuals, startups or existing enterprises who have deep domain expertise or market reach, an appetite for innovation, and are looking at jointly building great new businesses (co-creation)

Furthermore, we create our own internal products and groom them to be spun-off afterwards, preparing them to grow into sustainable businesses in their own right whilst having continuous access to the other elements of the ecosystem (spin-offs).

Finally, for some ventures, the missing link between the present and future success may be available resources, so we may just be able to help bridge that gap by investing money or time to help other people with their dreams.

Though important in their totality, in isolation, some of the steps we take and discoveries we make as well as some of the links we create might not be as clear or even seem random. However, together they keep opening up new horizons and connecting more dots to help shape and grow our Silicon Straits Universe. Our ongoing success over the past three years is the best validation, and we cannot wait to see how much further our universe will expand over the next 5 or even 10 years.

Author: Silicon Straits Saigon

Silicon Straits Universe was originally published in Silicon Straits on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. What is SIP?

Silicon Straits Internship Program (SIP) is our 12-week internship program aiming to provide real-life experience for mainly students.

2. What will you get?

You will get to:

1. Tackle real projects,
2. Perfect your technical skills,
3. Grow professionally,
4. Receive mentorship,
5. Have fun.

3. Who is this program for?

We’re looking for passionate candidates from all types of backgrounds (e.g. students from colleges or universities and/or currently working professionals). If you think you are a good fit for Silicon Straits, apply and tell us why — we always look for talents.

4. Where and When?

Our program will start from February 29th and will last for 12 weeks. You will be working full-time in our beautiful headquarter in District 7, HCM City.

5. What are we looking for?

6. When is the deadline for application?

You can submit your application anytime from January 3rd to 17th, 2016.

7. What is the hiring process?

(1) Application Submission: Fill the application form HERE and show us who you are.

(2) Technical Test: You will get an invitation to Technical Test at Silicon Straits office if your application has made us interested.

(3) Interview: If you pass the test, usually you will get an interview within 2 days. This is the time to talk with our technical and management teams so that you can show us your great technical ability and unique personality.

(4) Offer & Welcome: If we believe that you are the right candidate for the job, we will offer you an intern position. Congratulation on becoming a pirate and welcome aboard!

8. How to apply?

Now you’re interested, APPLY HERE. We’re looking forward to greeting you in person.

For more information about SIP 2016, please visit our website.

9. More questions?

Drop us an email at internship@siliconstraits.com.

Author: SS Internship Program

All about Silicon Straits Internship Program 2016 was originally published in Silicon Straits on Medium, where people are continuing the conversation by highlighting and responding to this story.