DEV Community: SonicDev

My Experience Interviewing for a Senior Software Engineer Role

SonicDev — Fri, 28 Feb 2025 03:42:44 +0000

Early in 2025, I applied for a Senior/Principal Software Engineer position at a hospitality-focused company. The role aligned well with my experience—7 years in software engineering with expertise in ReactJS, NextJS, NodeJS, Prisma, and Postgres.

The Interview Challenge

During the interview, the Engineering Manager presented me with an MVP for a multi-tenant e-commerce application, along with an API architecture diagram and an Entity Relationship (ER) diagram. My task? Plan and design a feature for offers/discounts based on a client request.

My Approach

1. Clarifying the Requirements
I started by asking key questions:

Are the offers exclusive to this client?
- No. The feature should be scalable for future clients, but offers are exclusive to VIPs.

2. Designing the Database
Since VIP access and offers were the core elements, I decided to introduce two new tables:

Offers (to store discount details)
VIPs (to manage eligible customers)

3. Defining Frontend & Backend Tasks
To implement the feature, I outlined key development tasks:

Frontend:
- Add VIP selection to the maintenance page
- Add an offers configuration section
- Display applicable offers on the customer-facing page
Backend:
- Implement API functions for CRUD operations on offers

Follow-up Questions & My Responses

During the discussion, the Engineering Manager asked some thought-provoking follow-ups:

"How can we support different types of offers?"
- I went blank for a second, unsure of what they meant. They guided me to add a type column in the Offers table to support multiple offer types.
"How would you deploy this to production?"
- Assuming the pipeline was already set up, I explained that I would create a release and let the pipeline handle the rest—running tests, building, and deploying.
"How do you define success for this feature?"
- I initially answered, "If all the acceptance criteria in the ticket are met, then the feature is successful."
- I added that built-in analytics could provide insights—if the feature receives significant engagement (e.g., clicks or redemptions), it indicates real usage and value.

My Reflections

Looking back, I feel I did okay, but there were areas where I could have done better. I covered the software development lifecycle well, but I could have been more structured in handling unexpected questions.

The Outcome

I didn’t make it to the next step 🥹—but I took away valuable lessons from the experience.

What do you think of this interview? Have you ever had a similar experience?

Deploying NextJS app to mobile App Stores using CapacitorJS

SonicDev — Tue, 04 Jun 2024 03:51:32 +0000

Have you ever thought of having a single codebase for your web and mobile apps?

I was recently tasked with a SPIKE ticket to research the gap analysis of getting our app to Google Play and App Store. What immediately popped up in my head was react-native. So I searched for popular frameworks that supported this. The top choice was Solito. It solved 2 things:

NextJS navigation on mobile
patterns to build cross-platform apps

The problem was I had to rewrite a lot of code to convert it to react-native-web to support native components.
So I asked around the team for some perspective. One suggested CapacitorJS by Ionic. It was the perfect solution for the requirement!

Basic setup with my NextJS app

basically, follow this guide https://capacitorjs.com/docs/getting-started

Few things to make your life easier

Use JDK 17 (this is the best version to use with Android to prevent Gradle build issues)
- Use this guide to change your default version https://stackoverflow.com/a/24657630
Create an index.html file inside your /public dir that contains:

<head></head>

see the note here why you have to do this https://capacitorjs.com/docs/getting-started#add-capacitor-to-your-web-app

Common build errors with `npx cap sync`

if /out dir is missing, you have to update your next.config.js to include output: export instead of output: standalone
if Gradle build errors, check if you are using the correct JDK version
if iOS error
- update your XCode
- install cocoapods using brew install cocoapods

Conclusion

Easy, right? Just make sure your web app is responsive and it should just work smoothly. 🚀 Good luck, mates!

2 ways of making your form inputs accessible

SonicDev — Wed, 07 Jul 2021 06:36:34 +0000

Recently, my team has been working on accessibility for testing. And we've had problems with getting our input elements to be following the principles of the testing-library

As per the priority in the docs, we should be using getByRole most often for the test to resemble how the user interacts with it in the browser. For example:

// get the textbox that has the label of 'Bar'
getByRole('textbox', { name: 'Bar' });

So for us to use getByRole, we should make sure that the <input /> is related to the <label />.

There are 2 ways we can do this:

<label htmlFor="foo">Bar</label>
<input id="foo" type="text" />

and

<label>Bar
  <input type="text" />
</label>

This way, we can make sure that our form elements are accessible, not only by the user but also by our tests.

Cheers! ☕ 🍺

Reference: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/label

Testing an accessible UI

SonicDev — Tue, 29 Jun 2021 10:56:14 +0000

Recently, my team has been writing lots of Cypress tests before releasing a feature. And it struck us that while we were pushing on using testing library for both Cypress and ReactJS, we forgot something, and that is ACCESSIBILITY.

So let me give an example code of a simple UI component:

const TextField = () => (
  <div>
    <label>Foo</label>
    <input type="text" />
  </div> 
);

If we were using Enzyme, the test would be something like this:

it('should display correct value after typing in something', () => {
  const wrapper = shallow(<Textfield />);
  const input = wrapper.find('input');
  input.simulate('change', { target: { value: 'Hello' } });

  expect(input.value).toBe('Hello');
})

Not bad right? It looks okay, but it's not how I see the user will interact with it in the browser, because we are:

just finding a random HTML input tag
simulating an HTML event
checking the property value of an HTML input tag.

Now, maybe I'm just not that familiar on proper use of Enzyme. But once I've used testing-library/react, it changed my way of thinking in testing UI components.

If we were to change the Textfield component and make it more accessible:

const TextField = () => (
  <div>
    <label htmlFor="foo">Foo</label>
    <input id="foo" type="text" />
  </div> 
);

We set a relationship between the label and the input.

Using testing-library/react, we can come up with this test:

it('should display correct value after typing in something', () => {
  // render in browser
  render(<Textfield />);
  // Using the label here as the name of the input field
  const input = screen.getByLabelText('Foo');
  // simulate the user typing 'Bar'
  userEvent.type(input, 'Bar');
  // Check that the input with the label 'Foo' has a value of 'Bar'
  expect(input).toHaveValue('Bar');
  // we can also check if this is really the value displayed in the browser
  expect(screen.getByDisplayValue('Bar')).toBeInTheDocument();
})

We are guided by the guiding principle of Testing Library:

The more your tests resemble the way your software is used, the more confidence they can give you.

In conclusion, by thinking how the user would interact with a UI component in the browser, we can imagine how we would write our tests, at the same time, we can also increase the accessibility of our UI components.

🍻 Cheers and Happy Testing! 🛠️

M1 Macbook Air after 1 month of development

SonicDev — Tue, 09 Feb 2021 13:08:37 +0000

After years of dreaming of buying the perfect laptop, I finally bought it, the new M1 Macbook Air(512GB SSD and 8GB RAM version). Great build, good keyboard, no fans(yet no thermal issues), fast, light, great screen, good speakers, and a battery that lasts a day. So far, everything about it was good.

I was hesitant to buy this machine because I was worried that running my development software on Rosetta 2(non-native ARM) would hinder the performance. But I was amazed by how fast this machine is. Everything ran smoothly, and installations were like nothing even changed with the Mac.

The first and only time it had a hiccup on me was performance testing the Table component I created. I haven't implemented any optimizations on my table. So I tried displaying 5,000 rows in 1 go, and I've noticed some slowdowns when switching windows. I was curious if this was also present in my work laptop, a 10th gen Intel MacBook Pro with 16GB RAM. So I tried and did the same thing with it. It looks like it's only a bit faster(ahead by 2-3 seconds on the initial render of rows).

In my conclusion, I think it is an excellent machine. I think you won't need to upgrade any time soon if you buy any Apple Silicon powered Mac. It competes with the last-gen Macbook with higher specs, and if not always, faster. My M1 Macbook Air is a fanless machine that is not even hot to the touch than my Intel MacBook that is ALWAYS hot to the touch, and fans are always ramping up to the max. This is probably the best bang for buck machine for any developer.