DEV Community: Michael Cheng

Singapore Tech Community Stance on Harassment

Michael Cheng — Sat, 31 Oct 2020 06:25:10 +0000

Harassment in the Singapore Tech Community

Members of the Singapore Tech Community, I would like to touch on the sensitive issue of harassment (including sexual harassment) in the community. Unbeknownst to many of us, this has been happening in Singapore for a while. It is not something that only plagues our western counterparts. It is happening within our shores.

As a leader in the community, I have personally received messages from members of the community who have experienced harassment. In the past few instances of receiving the complaints, we (myself along with other community leaders in the SingaporeJS, SingaporeCSS and JuniorDevSG meetup groups) have banned individuals from our meetup group activities. The culprits were notified and removed from all chats and user groups pages.

However, this does not mean the individuals have repented or the harassment has stopped. New people are being targeted.

Zero Tolerance Policy

Which prompts me to make this statement: We have a zero tolerance policy on harassment of any kind.

If we receive reports of harassment of members in our community, we will take action to exclude the culprit from further activities in order to ensure that our community remains a safe space for our members.

For the affected community members, we do not want you to suffer in silence. If anyone asks questions or says inappropriate things that make you feel uncomfortable or unsafe, please inform us. We want to help you, and if need be, take action against these bad actors in our community. And if necessary, legal recourse - for example, Protection from Harassment Act.

Ways of Reporting

You can email the report to report@engineers.sg or @miccheng on Telegram. Your identity will be kept secret.

You should also speak to the Admin of the group chats where you and the culprit are in. The culprit might also be targeting other members in that group.

Safe Community

We want the Singapore Tech Community to be a diverse and inclusive place, where everyone can feel safe in sharing knowledge and growing together in our craft.

Thank you for doing your part. 🙇‍♂️

Useful Links

How about a "transferrable" coding interview question?

Michael Cheng — Tue, 23 Jun 2020 11:44:20 +0000

Thinking about coding interview questions or take home assignments. We all come up with our own that we use to evaluate all our candidates. And it's a great tool for figuring out a candidate's capability to deliver working software.

Then I came across my friend's Tweet:

qian 🌺

@qiannyqian

Very 😒 at companies that just expect you to contribute two technical tests' worth without even a HR / screening call for the candidate to know about the company

Interviewing is a two way street FFS!!!

10:37 AM - 22 Jun 2020

2 10

I know of many job seekers who hunker down over weekends to do multiple coding assignments with fixed deadlines. Perhaps we are expecting too much or going overboard with our interview questions.

Culture Fit Interviews

Other than take home assignments, we also do live coding interviews to further evaluate a candidate's culture fit - how do they handle stressful situations, how do they troubleshoot a problem, can the candidate communicate well or articulate the technical decisions they make. These are good for gauging whether a candidate could be a suitable co-worker. So the culture aspect is quite specific to your company culture and what you look out for in a suitable candidate.

What i'm curious to know is if there can be a set of coding assignments that candidates can use to show that they know their shit. Not as formal as a certification, but more of a do you have a baseline competency for the role we are looking for.

How about online coding puzzle sites?

Sure, we can use HackerRank or something similar for this as a shared reference point for the candidate's capabilities. But those coding problems tend to incentivise a certain kind of behaviour. Coding for performance in a coding puzzle is not the same as writing well designed & maintainable code.

Make it transferrable?

Perhaps we should let candidates who don't make our cut to just bring their coding assessment to show the next company? I mean, you can say its your company's intellectual property... and it might encourage plagiarism... or give future candidates an unfair advantage if they know your coding test.

However, the flip side is this might actually accelerate the interview process. If the candidate is good, they wouldn't just copy pasta, they would do something properly (depending on the type of company you are in, copy pasta may or may not be a good thing).

No dramas...

Also, this may also ease the stress level of newbie coders who are bogged down with so many coding interview assignments from the companies they interview at.

What do you think?

Tips: How to be at the top of your game for live coding interviews!

Michael Cheng — Mon, 02 Mar 2020 11:09:34 +0000

If you are invited for an interview that involves live coding, here’s some tips for you to improve your performance. These are from my perspective as an interviewer:

Googling for syntax is fine. It shows us you are human.
Knowledge of different data structures show us you have enough experience to pick the right tool.
Also don't rush into writing code - plan ahead to show us that you understand the problem space. Also to help clarify your understanding of the question. Last thing you want to do is solve the wrong problem.
Related to 3 - don't spend too much time planning. This is a coding assessment, we want to see you write code, not dazzle us with your handwriting and pseudo code.
Manage your time: Clarify how much time you have for the assessment. That should inform you about how much to build. Its not cool to over-engineer when you only have 1 hour - but not solve the problem.
It's ok to ask questions. We like it when you ask us questions cos that shows you not a mindless drone.
Communicate - cos we are also looking for a co-worker we can collaborate with. Also, we can't read minds. So communicate what you are doing as you code. It shows us you are following a plan.
Even the most mysterious problems can be solved methodically. In a face to face interview, we are interested in your progression and process as much as the answer.

For extra brownie points:

Show proficiency in your tools - your IDE and keyboard skills. Know how to operate your IDE and demonstrate that you know the keyboard shortcuts.
Write tests to solve the puzzle. TDD is a super bonus point in my books.
MVP the solution quickly and then refactor.

I don't expect all devs to do the above 3. However, they are indicators of competence and mastery.

Hope this helps you when you go into your next interview grind.

Pair-Programming with CoderKungfu - sharing the "gospel" of pair-programming

Michael Cheng — Sun, 29 Dec 2019 09:19:52 +0000

Around June of 2019, when I was in between jobs, I decided to kill time by offering to do some pair-programming with anyone who would want to give it a try.

Pair-programming can be a rather strange experience if you are not accustomed to talking about your code to another person. But it is a muscle that you can train and something you can adopt as part of you software development workflow.

Format

I created a Calendly schedule and let people book 2 hours slots between 2 weeks in June. The sign-up form included questions about what they would like to achieve.

In order to have a productive time pair-programming, I needed a conducive environment. One that is quiet, has WiFi and power, and I can feel free to communicate openly with my pair without being disturbed. Fortunately, my appeal for a free space scored me a 1 month free membership at WeWork.

The venue was the WeWork Labs office at WeWork 380 Jalan Besar. Many thanks for my long time friend Adrian Tan (who runs WeWork Labs) for sponsoring.

Pairing up

Most who signed up were largely of 2 categories.

CTO or newly minted head of engineering

These were tech co-founder or people newly promoted to a technical lead role in their startup.

For them, the session was more like a consulting session where I gave them tips on hiring and managing an engineering team.

Junior Developers

These folks are in their first professional job as a software engineer. They are fresh graduates, mid-career switchers and most of them has not experienced what it was like to write code with pair-programming. For these, I mostly attempted a Code Kata (a coding puzzle) with them.

Bootcamp Students

I also did a session with the students from Trent Global's Diploma in Software Development. They are mostly mid-career switchers. I gave them some advice on how to prepare for the job market ahead.

Practical Tips for Effective Pair Programming

Here are some of the tips that i shared with them.

Be conversational. Talk through your thought process. Because people can't read minds.
Plan. Take time to plan what you hope to achieve at the beginning of the pairing session.
Take notes. I find that sometimes, it's faster to communicate ideas on paper/whiteboard than on the screen. I draw architectural diagrams and bullet points on paper (or on a whiteboard) to brainstorm ideas. An ex-colleague loves to fill up the monitor edges with post-it notes of the task list - and she would dutifully cross them off when its done.
Agree on a pairing workflow. There are many pairing technique. My favourite is the Ping-Pong method - where one pair writes a test, and the other pair writes the code that passes the test, and repeat. Another technique is a Driver-Navigator method - where one takes the helm (of the keyboard & mouse) and the other guides through the things that needs to be done. This technique is suitable when one has more knowledge of the code base and can help the other ramp up. Agree on a workflow and stick to it.
Focus on the work at hand. Don't get distracted by non-work PM, emails and social media pings. Don't waste the other pair's time.
Share keyboard time. Don't hog the keyboard. Let the other pair speak through code as well. Be patient with them.
Learn all the keyboard shortcuts. This is to be more efficient - reduces the time from thought to code. Also to not waste people's time. In a pairing situation, the pair usually agrees on an IDE or text editor to use. The one who is more familiar with the editor can use the opportunity to do more of the driving and show the other pair the frequently used shortcut keys. If you are afraid of constantly disrupting the "driver" to ask "what keyboard shortcut did you use?", you can try using this on-screen utility to help you display the shortcut keys used: https://github.com/keycastr/keycastr.
Use on screen cues to help bring focus. Use line number to help zoom in on code. Learn to bring focus to things on screen with the mouse cursor instead of your finger. The other pair's focus is on the monitor, so unless you are using the same monitor, they might not notice where your focus is when you point on your own monitor.
Take breaks. Do take breaks frequently. Once you reach a natural breakpoint, like after a Git check commit has been made, do take a short break to clear the mind. Pairing can be very intense and involves much concentration and focus - so taking frequent breaks will help rest your mind. As a guide, I take 15 minute breaks between every 1.5 to 2 hours of pairing time.

Conclusion

The session was eye-opening for the devs as it was the first time that they tried coding this way. It was interesting to see how they opened up and we had a good conversation on what the next steps were and how we should go about solving the coding puzzles.

I hope they will continue to learn and grow in their software engineering journey.

1-on-1 with Junior Developers

Michael Cheng — Wed, 25 Dec 2019 05:22:57 +0000

Just to share my experience mentoring junior developers via 1-on-1.

Recently, I did another experiment on doing things that doesn’t scale & filling gaps in the tech industry - adhoc 1-on-1 with junior developers. I first opened this up to the junior devs participating in the JuniorDevSG Mentoring Program.

Why?

As the organizer of the JuniorDevSG mentoring program, I was happy to help facilitate the mentoring groups and handle administrative things. But I had a nagging feeling that I needed to get in touch with the ground and see for myself if our efforts are making any impact.

And since I recently became a Reporting Officer (RO) at work, I needed some practice in doing 1-on-1.

Format

Essentially, I created a Calendly schedule and shared the link with the mentoring group. I only allocated Friday evening, Saturday evening and Sunday afternoons. I typically meet 2 persons per day.

I also opened this up to the mentors & the JuniorDevSG leadership team as I wanted to get to know them better too.

We met at StarBucks and just chatted for an hour on whatever they wish to talk about - their career advancement, advise on interview prep, or just chit chat.

In the sign-up form, I did ask about what they wish to talk about and their LinkedIn profile. The profile was so that I can familiarize myself with them before meeting them face to face.

Results

So broadly, here’s the groups of people I met:

Early Stage Junior Devs

Generally, most of the junior devs in this group needed advise on their career path. What it would look like going forward, how to move up the career ladder - becoming a better technical Individual Contributor (IC) and/or what’s beyond IC.

For this group, I assure them that there are companies who has Technical Tracks all the way to the top. But one thing common is that going beyond IC, one needs to take on more mentoring and coaching roles (either positionally or peer coaching of junior devs).

Mid-Career Switchers & Fresh Grads (or students about to graduate)

For this group, they needed advise on interview prep.

I reviewed their resumes and gave specific advice like highlighting their side projects / practice projects on GitHub. The GitHub link is more important than the live demo app link as interviewers want to see code they did rather than the “pretty visuals” of their app.

I also told them about the type of questions that they could ask in interviews:

How is the company’s onboarding process for new hires?
What is a typical day like for a dev in the company?
What is the dev workflow like? Do they do TDD, BDD, agile, retrospectives, use a project management tool, pair programming, etc.
Will there be a onboarding buddy/ mentor to help get familiar with things in the company?

These questions are highly important for teasing out details about the company culture. It also informs you about their readiness to mentor a new hire. If they don’t have a good answer to any of these, it might be a red flag.

As much as the face to face interview is the company checking if the candidate is a good fit, the candidate also needs to check if the company is suitable for them at their current stage of software engineering.

Intermediate Stage Developers

For these folks, it was more a catch up and sharing on practices that will help sharpen their skills.

My advise was doing code katas, side projects, and become more T-shaped in their skills.

Conclusion

It was definitely tiring to do this. I was actually on the verge of burn out before starting on this. But I needed to resolve the inner doubt about the impact of my work in the dev community. As such, I took a week to rest up before I started as I wanted to be centered before helping others.

For me, it was immensely satisfying to know of the impact of what I was doing in JuniorDevSG and Engineers.SG. And the 1-on-1 served as an opportunity to provide specific help for the individuals I met.

It was also an opportunity to catch up with the JuniorDevSG Leadership team on their motivations and goals for the group going forward.

Highly recommend doing 1-on-1s as an exercise in helping coach individuals with their software engineering journey.