Blog (tips) - Fred Wu's Tech

Tips for Job Interviews as a Junior Software Developer

ifredwu@gmail.com (Fred Wu) — Sun, 27 Sep 2020 05:56:03 +0000

As coding bootcamps such as Coder Academy and General Assembly churn out more and more software developers, and as more and more people start to realise the importance of software, companies these days are facing an increased amount of candidates applying for junior dev roles.

Recently we had to take down our job ad for a junior full stack React and Elixir role only a few days after posting it due to having received about 300 applications. Suffice to say, the competition is fierce at the entry-level end of the software engineer spectrum.

Software is eating the world. - Marc Andreessen

In the past three months alone I’ve had to sit through over a hundred interviews, many of which were for junior roles. Some candidates did really well but unfortunately the vast majority did quite poorly. In this article I am hoping to offer some tips and insights as a seasoned interviewer and hiring manager, to those who might be struggling landing an entry-level software engineer role.

I’ll break the tips into three sections: before an interview, during an interview and after an interview.

Before an Interview

This is arguably the most important stage of your interview - before it happens! Prepare yourself with enough knowledge and confidence in both software development and conversational skills in order to ace the interview and stand out amongst a sea of candidates.

Study Software Engineering Fundamentals

I get it, bootcamps and many online tutorials and courses focus on teaching the practical things to turn code into products. But just like running or even walking without correct postures, it can be incredibly dangerous over time.

My recommendation is to read on the basics of object-oriented programming, functional programming and some design patterns. For instance, build up some basic understanding of how the JavaScript prototype works or how the Ruby object model works can be extremely beneficial in progressing your technical capability on application design and architecture.

Get More Project Experience

Not having any substantial project experience on your CV is a sure way to significantly lower your chance of getting an interview.

Do junior developers really need substantial project experience, you may ask? Abso-fucking-lutely!

Build your own side projects, participate in open source projects, pick up some freelancing work - the choice is yours. These won’t be your most technically accomplished work, but they will help you accumulate experience, and more importantly to demonstrate your capability to your interviewers with real world experience.

Why Software Development?

I want you to put your hand on heart and answer this question honestly. If your answer is more money or FOMO, that’s okay, but be prepared to be disappointed with the reality - if you are not in this field because of your passion for building products or solving problems, you will find this a long and hard slog.

If you are passionate about building software, then let me tell you this - when you are starting your career you will have to give up your work life balance for a bit. That is, if you want to boost your career and progress quickly beyond being a junior developer.

My interest is in the future, because I am going to spend the rest of my life there. - Charles Kettering

Looking back at when I started my software career many moons ago, I never regretted giving up my social life early on in my career: I worked extremely hard, often did many jobs - a day job as a dev, a night job as a dev, freelancing and doing open source work all at the same time. Some would probably frown and say that I had no life, but I choose to believe that I was making sacrifices so I can become good at what I love doing in the shortest amount of time.

Research the Company You Apply For

If you are one of those who spam your CVs to every job opening, please consider changing your tactic. A well written cover letter will not only increase your chance of getting an interview, but also allow you to ask relevant questions during the interview.

Check out the company’s website and any social media pages on LinkedIn, Facebook and Instagram, etc. Do a bit of “stalking” on the people who work in the company, sometimes this will give you some insights into the type of work environment and culture the company has.

Doing enough research is not only for your own good - knowing whether you will enjoy working there should you end up getting a job offer, but also demonstrates your ability to do research and independent thinking to your interviewers.

Read, Listen and Communicate

This one might not be immediately obvious because it’s very high level and somewhat vague, bear with me.

Some people might be deep thinkers but really struggle to get their points across, and to communicate their ideas and thought process in a clear, concise and useful way. My advice is to read blogs, listen to talks and learn from other people on how they communicate. When you read and listen, pay more attention to how sentences are structured and how titbits of information are given.

The most powerful person in the world is the story teller. - Steve Jobs

And don’t forget to practice! Get comfortable talking to others on various topics in software development.

During an Interview

Hopefully the tips given thus far would help you secure an interview. Now it’s show time!

Turn Up On time, Have Equipment Sorted

Whether you are attending an on-location interview, or more likely during Covid, an online interview, make sure you turn up on time!

If it’s an online interview, also make sure you have whatever software needed (Zoom, etc) installed and tested. I’ve had a few occasions where the first five minutes of the interview was spent on the candidate trying to get their mic or speaker working - it’s not a huge deal, but it does show the lack of preparation and organisational skills.

A Smile Goes a Long Way

Understandably, interviewing is stressful. However, remember to put on a smile when you greet your interviewer and when you do small talks. Everything needs a balance of course, when you’re giving technical answers it’s probably not a good idea to smile.

If you know you get uncomfortable talking to strangers or when under pressure - do more practices! If you can’t find a friend or don’t have a partner to practice with, use a mirror!

Learn to Say “No, I don’t know”

When you don’t know something or can’t recall the details of something, just say it. As an interviewer, when I ask you a technical question I can see through your hmms and ahs. A “sorry, I don’t know” is a much better answer than one that doesn’t make sense.

Bonus point: “Sorry I don’t know, but I will look it up after this interview.”

Read Social Cues

This one can be extremely easy or extremely hard depending on your personality. For those who might struggle with reading social cues, try pay more attention to what type of questions you were asked.

If it was an introduction of yourself to kick off the interview, make it more than just two sentences but also under five minutes - this is usually a warm up for you to find your feet and calm your nerve, and for the interviewer to extract any interesting information as a discussion point later. It doesn’t have to be your memoir and you shouldn’t robotically talk through your entire education and work history.

If it was a technical question, always try to time-box it. Don’t drag on and repeat yourself just because you have already answered it quickly and concisely. When in doubt, ask the interviewers whether they have anything in particular they were looking for.

If it was an open ended question, try to explain your thought process as you explain it. As an interviewer, I’d hate to ask an open ended question and get a short yes/no back. At the same time, give interviewers room to interject and ask follow-up questions by pacing yourself.

Don’t Speak Too Fast

Okay, you might be very nervous, or English might not be your first language, so you tend to speak fast to “get through it”.

If that’s the case, work on your speech pattern, make it concious enough that you will recognise it when you speak too fast. If interviewers can’t get your points clearly, they might not always ask you to clarify - because if you kept doing it repeatedly, you would already be written off as a suitable candidate.

Be Humble

I totally understand that in a competitive job market you want to present yourself in the best light. Just be confident and speak the truths.

As someone who’s been doing interviews for years, I really dislike people who overstate their capability either on their CV or during the interview because these are often very obvious. Claiming to be an Elixir expert but not knowing how the supervision tree works is a sure way to score a black mark, for example.

Show Passion and Drive

To counter the point on over-selling yourself, what works better is to show interviewers your willingness and determination to learn. Remember, you are still a junior therefore we don’t expect you to know everything we know.

What we do expect, is your commitment to learning - not by saying it, but by demonstrating it. Remember the earlier tip on getting more project experience?

Ask Questions

Usually towards the end of the interview, we’d ask you if you have any questions. Don’t say “no”.

Doesn’t matter how much research you’ve done on a company, there are always insights someone who’s working at the company can give you. How do they manage the delivery? How do they support learning? What makes them enjoy working at the company?

Use this opportunity to gain insights into why you should be working at this company, and to demonstrate your interests in working at the company to the interviewers too.

After an Interview

After completing an interview, it’s an opportunity to do a little retrospective and do a follow up when necessary.

Close the Knowledge Gap

Don’t over-analyse on what you could have or should have said. Instead, spend your energy on solidifying the topics you couldn’t or didn’t provide good answers for. If you’ve said “don’t know” or “not sure” during the interview, now is your chance to make it “sure”.

Follow Up

If during the interview there have been things mentioned that you could provide links or more information on, be sure to act on it. You never know, maybe the clarification is just what the interviewers needed to help them make a decision.

To all the junior developers out there - enjoy the journey! You are in for an amazing ride, make every second count.

If you enjoyed this article, checkout my other tips articles:

]]>

Tips for Writing a Good CV / Résumé

ifredwu@gmail.com (Fred Wu) — Wed, 20 May 2020 08:59:24 +0000

Due to COVID-19, not many companies are hiring at the moment. The company I work for therefore is in a very fortunate position to still be thinking about growth and hiring.

As a hiring manager for almost a decade now, I’ve personally reviewed thousands of job applications and CVs, and many hiring managers would probably agree, the vast majority of CVs are terrible. Let’s change that!

During COVID-19 where more and more people are either losing jobs or having their work hours cut, we are experiencing an increased amount of applicants to our job ads. I’d say on average I spend about 30 seconds per applicant due to my busy schedule - most hiring managers are busy people, it is therefore crucial for candidates to realise the importance of having a CV that is clear, easy to read and most importantly sells yourself. And if you have a cover letter, which I highly encourage that you do, congratulations you just bought yourself another 30 seconds. ;)

I’m writing this post mostly from my own perspective - as a hiring manager in a tech company in the western culture (we’re based in Australia). Understandably, different cultural backgrounds and regions may have their own conventions, but certainly in Australia and many similar western cultures, there are things that you do and don’t do on a CV, and there are things that may help your CV stand out. Let’s talk about these things.

At the end of this post I will also share a copy of my own CV to help illustrate my points.

30 Seconds? Surely It’s Unfair to the Candidates

Yes, I agree, to think that you are only given 30 seconds for your perhaps carefully crafted CV and cover letter is definitely soul-crushing. But it is unfortunately the reality. I work for a company where I can still do the first round of vetting myself, many large corporations would use algorithms and/or HR people to reject your applications based on keywords and other things.

Knowing the reality and the constraints, there are a few things I’d like to address in the hope of improving your CV and your chance of scoring an interview, and in turn, helping myself and other hiring managers out there to have a better candidate CV screening experience.

Have a Pronounceable Name or Alias

This one surely would raise some eyebrows - you might think that your name is your identity and you should not change it for anyone. True, however, the reality is that a hard-to-pronounce name discourages your profile to be shared and spoken about. Why not add a pronounceable alias if means there’s an increased chance of getting an interview?

For clarity, I personally would never reject a candidate based on their name (or their cultural background for that matter), but I know some hiring managers might, and for some of them, they are NOT doing it on purpose. However, I have on several occasions had to ask a candidate how to correctly pronounce their name.

A Short Blurb on Who You Are

As a hiring manager, I care about who you are as a person - if you can summarise who you are as a professional in a sentence or two, it will help me determine whether you might be a good fit or not.

As an example, here’s a blurb about me:

A passionate and hands-on software executive with two decades of experience and an entrepreneurial mindset.

A long time open source developer who has created and contributed to a few dozens of projects, including Ruby on Rails.

In two sentences, I explained my industry experience as well as my open source contributions - two things that help define who I am as a working professional. It also invites more questions from hiring managers: what kind of things have I done as an entrepreneur; what other open source projects have I contributed to?

Work Rights

Many companies have restrictions or policies around who they can hire based on their residency and visa status. If you are not a resident or are on a particular visa, make it clear in your job application so you don’t end up wasting time for the employer and for yourself.

List Keywords, But Don’t Overdo It

In the tech space it is important to have keywords visible to highlight your skills. If you are a software developer, your tech stacks should be clearly stated in your CV. As a hiring manager, if I am hiring a PHP developer, I expect to see PHP mentioned in your CV. There are of course exceptions, for example when we were hiring Elixir developers I did not expect to see Elixir as a keyword simply due to the supply constraint.

It is a balancing act however - I’ve seen CVs where candidates put 20-50 keywords on their CVs. I’m sorry but unless you are extremely gifted, you cannot possibly be good at all those things. Do not put keywords on your CV simply because you’ve read an article on the subject.

Oh, and unless you’re going for a data entry role, I honestly don’t care about your Excel skills…

Do Not Overstate Your Capability

Similarly, try to avoid overselling your capability. I once interviewed a candidate who claimed to be an “expert” on Ruby. We were actually hiring for a non-Ruby position, but given the candidate’s CV, I questioned him on some advanced Ruby subjects during our interview and he struggled all the way through and was sweating bullets. Suffice to say that he did not get the job.

Be confident, but also be honest and be humble. Lying on your CV to get an interview is a waste of everyone’s time.

Keep Things Short

As I mentioned in the beginning, I spend on average 30 seconds on each CV. Keep things short and easy to read! I really don’t care about how awesome you were in your last dozens of projects - these will get covered during interviews.

On a CV I expect short and concise blurbs on what you did in each role. Also, take recency into account too - if you’ve been working in the industry for a decade or two, what you did 20 years ago really doesn’t matter as much, so save yourself some time and cut things short.

For example, here’s the blurb for my current role:

Leading a department of 25+ engineers to make great child care and education software. As part of the leadership team and reporting to the CEO, helping building and turning the company into a market leader.

And here are the blurbs for my older roles:

Yes, the blurbs for my older roles are left empty intentionally.

Now, again there are exceptions. If something happened a while ago but is interesting and relevant, do tell! For example, here’s the blurb for my oldest “role”:

Built my first ever website using Microsoft FrontPage Express, on a Pentium 166Mhz computer, uploaded via a 33.6kbps modem.

Explain Over-Qualified Titles

There were a few times where a “CTO” or even a “CEO” applied for a developer role. In most cases it wasn’t about over-qualification, but about what the candidate wanted to achieve professionally. So, either in the CV or in the cover letter, explain what you are looking for in your next role, otherwise you run the risk of being assessed as over-qualified.

Spare the Personal Details That Are Too Personal

This is predominantly a culture thing as I’ve seen it from mostly candidates of certain cultural backgrounds. I really don’t care about your age, gender, marital status or favourite sport. These things do not define who you are as a professional - we might talk about your favourite sport and food during the interview but they are irrelevant on your CV.

Space Things Out

Look up CRAP Principles - make sure your CV has enough white spaces and contrast, and has fonts that are readable! Scrolling through walls of text is no fun and is a sure way to get your CV dismissed.

2-4 Pages

This is not scientific, for me personally I prefer to see CVs of 2-4 pages. Use the length as a constraint to cut things down. There were several occasions where I ran into CVs with 10+ pages. I guarantee you, unless a hiring manager is extremely bored, he or she does not have time to read your War and Peace.

PDF Over Word

When possible, submit your CV in PDF format instead of Word format. Now, sometimes if you use a recruiter you’ll be asked to submit your CV in Word format so they can ~~fuck it up~~ add their branding. A PDF formatted CV ensures the correct formatting and layout always get shown to the hiring managers.

Cover Letter

Always attach a cover letter when possible, but keep it short too. Given the amount of CVs a hiring manager needs to go through, having a crafted cover letter is another way to grab their attention and increase your chance of getting an interview.

Don’t repeat the same information in the cover letter though. Your CV is about the facts of your experiences, your cover letter should be about your thoughts on why the company should hire you. Focus on the value you can bring to the table.

Find A Referral

When possible, find someone who can refer you. A referral gets preferential treatment during the CV screening stage and does not suffer from the same 30-second fate.

Pleasing Design

This one is a “nice-to-have”: if your CV is really well designed, you would earn another 30 seconds of my attention. ;)

These are the main points, hopefully they are helpful. To help illustrate, here is a copy of my own CV, with contact details removed.

If you enjoyed this article, checkout my other tips articles:

]]>

Tips for Becoming a Better Software Developer

ifredwu@gmail.com (Fred Wu) — Sun, 03 May 2020 06:34:25 +0000

Over the past decade or two, both as a software developer and as a manager I have accumulated a few tips for becoming a better software developer.

For context, I’ve been working as a software developer for more than a decade, mostly in small product-based companies; over the last decade or so I’ve worked as a team lead or manager in various capacities; and I’ve moonlighted as a consultant, freelancer and open source contributor in-between. Check out my LinkedIn profile and Github profile if you are interested.

Now, let’s break down the tips into three main areas: mindset, technical and people. The goal of this article is to raise awareness of the topics mentioned, if you want to understand more on a particular topic I encourage you to do your own research.

Mindset

Have a Growth Mindset

This one hopefully should be obvious, if you haven’t heard of it, please read more here.

Have a StarCraft Mindset

This one is “new”, I’ve given a talk that includes more details on what it means, check it out here. In essence, it’s a mindset that requires you to always consider things around you, and forces you to think beyond your narrowly focused task at hand.

Recognise the Dunning–Kruger Effect

I once interviewed a mid-level developer who rated himself as a 9.9 out of 10. The Dunning-Kruger effect is essentially the opposite of the Imposter Syndrome, both are very common in our field.

Agile is Not a Process, It’s a Mindset

Some people are overly obsessed with the processes of “being agile”. In truth, every organisation, every project and every team is different, there is no point to follow a set of processes that might slow you down and not add any value. Discover what being agile means to your team, your project and your organisation is an ongoing effort and should be treated as such.

Different Organisations Require Different Engineering Approaches

Some projects and organisations require tech-driven decisions be made upfront, some on the other hand require product-driven decisions instead. Knowing how your organisation operates and what it values plays a key part in understanding how software development should be approached.

A Sense of Entitlement Only Gets You So Far

Let’s be honest, as a software developer we are extremely lucky to be in a high demand field. As a result, many have started building a sense of entitlement - some ex-colleagues of mine even complained about the lack of tissue boxes in the office. Starting and running a business is extremely hard work, let’s all appreciate what we have before throwing a tantrum.

9-5 is Not Evil, Nor is Crazy Work Hours

Every now and then I see conflicts between people who share different philosophies on what work and career mean to them. We should embrace the different ways people prefer to spend their time and energy on, rather than force our own ideology on them. Discovering and knowing the difference between working at a giant corporation versus working at a small start-up is key to our happiness.

Pain and Gain, There’s Always a Trade-off

An extension of the 9-5 vs crazy work hours: adjust your expectation based on the effort you put in. You can’t have everything, prioritising family life over career building is 100% okay, as long as you know what you are giving up on, vice versa. In my 20s, many of my similarly aged friends and colleagues would go out and have fun after work and on weekends while I was in front of my computer building open source projects, is an example of a conscious trade-off I made.

Speed vs Quality

Internalising the need for speed and the need for quality should always be on our mind. Pursuing only quality or only speed will significantly limit your problem-solving capability as well as your career progression.

Think, Then Do

It’s a balance - don’t overthink it, but also don’t do without think first. When in doubt, ask more experienced people for advice and guidance.

Technical

Avoid Second System Syndrome

I’ve seen Second System Syndrome over and over again throughout my career. Some people always assume a rewrite is a much better approach than alternatives, more often than not though, it is not the case.

Micro-Services is Neither New nor the Holy Grail

There’s the age-long debate of monolith vs micro-services architecture, and SOA (Service-Oriented Architecture) has been around for decades. Each has its own pros and cons, don’t get bought into the hype because a blog post says so, or a particular product and company found it successful. Use the right tool for the right job.

TDD (Test-Driven Development) is not the Holy Grail

Just like micro-services, TDD is not the holy grail and should not be treated as much. Chasing the TDD dream without knowing its pros and cons is just as counter-productive as not doing TDD when necessary.

Code Aesthetics Matter

A lot of people treat coding as more of a scientific endeavour: they focus purely on the algorithms and results. Software development to me is a creative endeavour, and I often use white spaces and the general look and feel of the code base to determine how well-organised a project is - deeply nested code and long functions for instance are obvious ways to determine potential code smell.

You’ve all heard of the SOLID principles, but have you heard of the CRAP principles?

Read As Much Code As Possible

Don’t get me wrong, writing code is important, practice is important, but time and time again I come across developers who clearly have little exposure to established patterns and conventions.

Tech Stack Exposure and Diversity are Always a Good Thing

No matter whether you are in a highly specialised field or being a generalist, having exposure to different tech stacks and paradigms is always a good thing - it widens your field of vision and increases the boundary of your technical understanding. Don’t be the guy or gal who is known as “a \ developer”.

Have a Deeper Technical Understanding Helps

This is strictly speaking a “nice to have”, but I lost count of the number of candidates I interviewed who claimed to be a Ruby expert yet cannot explain the Ruby object model and have never heard of eigenclasses, or senior developers who cannot explain the difference between git merge and git rebase. Sure, you may not need the deep understanding in order to do your job, but it will certainly help!

People

Always Assume Incompetence over Malice

If you haven’t, read more about it here. Knowing this, and paired with having a growth mindset, you should therefore be encouraged to teach, educate and influence, rather than being defensive and participate in “us vs them”.

Truth = Visibility x Tolerance

This is another topic covered in my talk. If you find yourself regularly dissatisfied with the information you receive, ask yourself: what information is and isn’t available to you, and are you sure you have the stomach to tolerate the new information?

Rapport and Productivity are Built Over Time

Some people assume a team’s productivity is determined largely by team member’s individual capability, some also assume a 10x engineer is a reflection on one’s technical capability. It’s not. Productivity evolves over time - building rapport with those around you is often the unsung hero in productivity.

Champion Team Over Champion Individual

This one hopefully is obvious, but I just have to emphasis its importance. Please, if you struggle to work with your team, ask for help! If you have a team mate who is difficult to work with, reach out and help them!

Final Thoughts

Software development is evolving rapidly, some fundamentals however are always useful and relevant. I hope you find this article useful.

I’ve mentioned my talk a few times, but if you haven’t already, check it out below, it covers a few topics mentioned in this article, and some more. Also check out my tiny Youtube channel for more tech talks I’ve done in the past.

video: https://www.youtube.com/watch?v=MBczdO7RgNo

If you enjoyed this article, checkout my other tips articles:

]]>

[Rails Tip] Render views outside of Controllers or Views

ifredwu@gmail.com (Fred Wu) — Wed, 20 Jun 2012 09:09:00 +0000

Ever wondered how you could utilise the render method outside the context of Rails controllers and views? If you wonder why anyone would do that. Well, imagine you are building an awesome form builder, you need to output and/or store rendered partials in the buffer. How do you do that?

For example, what if you want to do this in your view?

<%=raw Awesome::FormBuilder.new(some_options).html %>

You could do something like this:

module Awesome
  class FormBuilder < AbstractController::Base
    include AbstractController::Rendering
    include ActionView::Context
    include ActionView::Helpers::CaptureHelper

    # set the view paths from your engine or from your application root, i.e. Rails.root
    self.view_paths = Awesome::Engine.root.join('app/views')

    def initialize(params)
      flush_output_buffer
      @_buffer = ''
      add_to_buffer(params)
    end

    def html
      @_buffer
    end

    private

    def add_to_buffer(params)
      # some logic to add rendered content to @_buffer
    end
  end
end

The idea is to mixin the render method, but also ensuring the view buffer is correctly reset with flush_output_buffer.

Hope that helps. :)

]]>

On Hiring: How To Be a Non-Technical Co-Founder

ifredwu@gmail.com (Fred Wu) — Sat, 28 Jan 2012 06:16:00 +0000

If you are looking at hiring developers, check out my article on this subject.

The goal or the dream of working on your own startup is always full of excitement. And apart from some rare cases such as Dropbox, you probably need one or more co-founders to work with you on The Next Big Thing ™.

Problem is, how do you (as a non-technical co-founder) find us? Or more specifically, how do you talk us into working with you instead of some other billion-dollar ideas?

To answer this question, we need to first ask, is there a billion-dollar idea? The short answer is: NO.

Idea is worthless.

Well, that’s not entirely true. I believe - idea, by itself, is worthless.

You will be surprised by the number of people contacting us and wanting to build a better Paypal or a better Amazon, without a concrete plan.

A more worthwhile idea should contain not only the end goal of the project, but also a plan to reach the goal. What should we ship in the Minimal Viable Product? What are our marketing channels? What metrics should we look at? How do we use social media to our advantage? etc, etc.

We Are Not Just Wozniak, Are You Like Steve Jobs?

Apple is pretty much started by Wozniak as the technical co-founder and Steve Jobs as the idea/business co-founder.

Let’s think about this for a second.

Steve Jobs did not just have ideas. Very early on, he persuaded Wozniak to produce and sell Apple I so they have some capital. Jobs was building the foundation. Without the foundation, there will be no failure or success to come.

On the other hand, Wozniak had no intention to become an entrepreneur, he was happy to stay as an engineer even after the early Apple success. Nowadays though, most of us techies are much more ambitious than that.

Ideally, as the technical co-founder, I would be doing most of Wozniak’s work, and both you and I would be doing Steve Job’s work.

Drawing from my personal experience, as a technical person, there are a few key attributes I look for in a co-founder (technical or otherwise).

Technical Ability

“Excuse me? Aren’t you the technical co-founder? Why are you looking for my technical ability?” You ask.

That is right. Even if you are not a developer by trade, having a certain degree of understanding of technologies is still crucial to most modern, web-based projects.

There has never been a better time to start learning to code. Why not give CodeYear and Khan Academy a try?

We all learnt physics and chemistry in high school even though most of us don’t require the knowledge in our day to day life. Let’s treat coding the same. Learn how to code will not only give you insights to how we solve problems, but will also close the communication gap between you and your technical co-founder.

Obsession

Wozniak is obsessed with electrical engineering and gadgets, Steve Jobs was obsessed with computer typefaces, good user experience and beautiful hardware.

What are you obsessed with?

Only when you are obsessed with something, can you answer questions like “what annoys you so much?”

As I wrote in an ealier article:

Inventions and innovations aren’t born out of happiness, they are born out of frustration, anger and sometimes, curiosity.

Curiosity

In web-based projects, it is surprisingly easy to have “what if …?” scenarios. Not sure which sign up form will have a higher conversion rate? Easy, just make two or more of them and run A/B tests.

Sometimes, as developers, we are so in the zone that we would keep on building stuff the way we envisioned. You will need to step in, pull us out, and say “hey, have you thought about …? What if …?”

Flickr as it is today would never have existed if the founders didn’t raise the question of “hey, how about doing just the photo uploading and sharing features?”

High Expectation

“This is shit!” “We can’t ship this!” If the product stinks, say so, and find ways to improve it. An MVP should always be half-polished, not half-arsed.

The original iPhone was shipped without 3rd party native apps support, or multi-tasking - it wasn’t ideal, but they didn’t effect the core user experience. Now look at PlayBook, it has the features most Android devices have, but the core user experience is so bad that the product never took off. If someone at RIM’s top management had the same obsession on user experience as Steve Job’s, PlayBook would never have shipped in such a bad shape.

Passion

Are you in this for the money? Or for something else? Wealth is rarely a good motivation for creating great products.

“It can potentially generate massive revenue and profit” is a big red flag to me when someone pitches their projects.

These are the key attributes I look for. Things like people connections and experience are also important but not essential. What about you? Do you look for any particular attributes in your potential co-founder(s)?

]]>

On Hiring: How Not to Annoy Developers

ifredwu@gmail.com (Fred Wu) — Thu, 26 Jan 2012 05:42:00 +0000

If you are looking at finding technical co-founders, check out my article on this subject.

In recent years developers become hotter and hotter - especially the good ones - they are hard to find, and they have plenty of employment options to choose from.

Some companies (or individuals who are seeking freelancers) go the extra miles to impress developers with attractive salary/rate and perks, which is nice. But surprisingly, many companies and individuals seem to have a habit of keep doing things that will annoy developers.

Over the years, I have personally encountered many situations that annoyed me as a developer. If you are looking for developers, here are a few things that I think you should be aware of.

Budget Gap

Find out what the developer’s salary/rate expectation is, there is no point if the developer is looking for $120k when you could only afford $80k. It’s absurd to think that you might be able to persuade them with a significant pay cut.

Timing of Hiring

Don’t advertise the position until you are fully ready to hire. Put a job ad up then go on holidays immediately after is a bizarre thing to do.

Recruiters

If you use recruitment agencies, please make sure you know them well enough and if not, do your fair share of research on them. Bad recruitment practices will cost you and damage your reputation. I once dealt with a recruiter who did not even bother to pass along my response to the offer back to the employer.

Technical Assessment

Unless you are Google or Facebook who have a huge pool of candidates to filter, it is probably a bad idea to test your candidate’s technical skills with brainfuck coding questions on paper or on whiteboards.

I am in favour of having candidates to do one or two coding tests (on their own, not during the interview) that will demonstrate their technical abilities without spending too much time or be under interview pressure. If a question is going to take a candidate more than a couple of hours to do, it is too much.

The technical questions should focus on the logic behind a candidate’s solutions, not what functions or libraries a candidate may or may not remember from the API documentation.

Also, pair programming is an excellent way for both parties to get a sense of what it is like to work together.

Communication Channel

This applies more to hiring remote workers and freelancers. If you are pitching your project to a developer, please at the very least write a sentence or two to explain what your project is.

“Would you have time to have a quick chat?” is simply not good enough - good developers are all very busy and are likely to have many projects or potential projects to work on. Even if the developers have the time to chat to you (without knowing what your project is), it is still better to have the conversation via emails so the developers can keep track of things.

Developer Relationship

Recently there is a company in Melbourne who burnt a huge bridge with some of the most respected and talented local developers. Now they are having trouble finding talents even with inflated salary/rate. Moral of the story is, please always treat developers properly.

So, these are the few things I can think of for now. How about you? I would love to hear your thoughts and stories on hiring developers.

Hacker News comments here.

]]>

[Rails Tip] Model Attributes Not Updating? `reset_column_information` To the Rescue!

ifredwu@gmail.com (Fred Wu) — Tue, 25 May 2010 10:58:00 +0000

So you were wondering why some of your model attributes weren’t updating properly? Well, it is perhaps because the db schema has changed but the changed schema has not been passed onto ActiveRecord, as is often the case in DB migration.

Taken from the ActiveRecord documentation:

Resets all the cached information about columns, which will cause them to be reloaded on the next request.

The most common usage pattern for this method is probably in a migration, when just after creating a table you want to populate it with some default values, eg:

class CreateJobLevels < ActiveRecord::Migration
  def self.up
    create_table :job_levels do |t|
      t.integer :id
      t.string :name

      t.timestamps
    end

    JobLevel.reset_column_information
    %w{assistant executive manager director}.each do |type|
      JobLevel.create(:name => type)
    end
  end

  def self.down
    drop_table :job_levels
  end
end

]]>

[jQuery Tip] Traverse/Parse HTML String

ifredwu@gmail.com (Fred Wu) — Wed, 28 Apr 2010 01:42:00 +0000

When you are getting an HTML string from an external source (e.g. from an AJAX get result) and you want to rip out a certain part of the HTML source, you need to make sure that the ‘certain part’ is not at the top level of the HTML source.

For example, we have the following HTML string:

Hello
World

If we want to get the first paragraph element by using:

// data is the HTML source
$('span#first', data)

The above code won’t work, because the p tags are at the top level. Instead, we can simply wrap the HTML source with a div tag and that’ll do it. :)

]]>

[Rails Tip] DataMapper M:M Association Bug and Workaround

ifredwu@gmail.com (Fred Wu) — Mon, 26 Apr 2010 23:35:00 +0000

It was confirmed that DataMapper is incorrectly setting table names in SQL JOINs.

So for instance, the following code would generate an SQL error:

type.jobs.all(:"country.name".like => "%#{params[:location]}%")

There is a workaround, however the workaround requires manual looping of the dataset thus produces N+1 queries.

type.jobs.all.reject do |job|
! job.country.name.downcase.include?(params[:location].downcase)
end

But at least it works. ;)

]]>

[Rails Tip] DataMapper Timestamps Bug and Workaround

ifredwu@gmail.com (Fred Wu) — Mon, 19 Apr 2010 08:22:00 +0000

It has been confirmed by DataMapper’s core developer Martin Gamsjaeger (snusnu) that it is a bug.

In short, created_[at|on] can be manually overridden, but updated_[at|on] cannot.

The workaround is simple, do it in two steps, for example:

job = Job.create(
  title: "Web Developer",
  created_at: Time.now - 2
)
job.update!(updated_at: Time.now - 1)

Please check the bug ticket to see when it’s getting fixed.

]]>