- Explain OOP concepts. Using one of your previous projects as an example.
OOP is a way of encapsulation a set of functions and data that are related to each other, that can be created, reused and extended.
A classic example of this is the Person class which is the base class, then from it you can extend it to create Teacher and Student.
class Person {
name;
constructor(name) {
this.name = name || 'Anonymous';
}
}
class Teacher extends Person {
teaches;
constructor(name, teaches = []) {
super(name);
this.teaches = teaches;
}
}
class Student extends Person {
classes;
constructor(name, classes = []) {
super(name);
this.classes = classes;
}
}It's a good way of doing things, but sometimes it makes refactoring difficult, not because of of OOP or classes, just because of classic inheritance and ideas and requirements change.
In the React space I haven't had to use it much in my last few positions as React mainly uses functions but it's not too different, you would just need to put this infront of local class variables to access them, and new the class to instatiate it.
- Have you ever experienced concurrency issue? If yes, provide a pseudocode example
Most concurrency issues are generally related to fetching data. A most common ways to solve the problem are to use Promise or Async/Await.
// The problem
const output = fetch('https://jsonplaceholder.typicode.com/users');
console.log(output); // OH NO! Something is wrong!
// Promise
let output;
fetch('https://jsonplaceholder.typicode.com/users').then((response) => {
return response.json();
}).then((data) => {
output = data;
console.log(data);
});
// Async/Await
let output;
// Cannot use await without async (yet)
async function fetchUsers() {
const response = await fetch('https://jsonplaceholder.typicode.com/users');
const data = await response.json();
output = data;
console.log(data);
}- Using pseudocode to create an XERO credit note. API is documented at https://developer.xero.com/documentation/api/accounting/creditnotes
// Get access token
accessToken = getXeroAccessToken();
fetch a POST to https://api.xero.com/api.xro/2.0/creditnotes
The header of the fetch MUST contain the accessToken data in authorization
The body of the fetch may contain {
Type, // Must have
Contact, // Must have
Date,
Status,
LineAmountTypes,
LineItems,
CurrencyCode,
CreditNoteNumber,
Reference,
SentToContact,
CurrencyRate,
BrandingThemeId
}
on success, return the response
on error, do error handler stuff- Given an array of numbers, write a function that finds the most frequently occurring number in the array. How would you optimise it for large datasets?
const largeArrayOfNumbers = [...];
const numbersCount = largeArrayOfNumbers.reduce((acc, num) => {
if(!acc[num]) {
acc[num] = 0;
}
acc[num] += 1;
return acc;
}, {});To optimise for large datasets you could use a library like danfojs. https://danfo.jsdata.org/. You could also use a web worker or worker threads to loop through threads concurrently for each unique number (using Set()).
- I am using Stripe to charge a customer $100. The call to stripe Charge Customer API failed. I then initiated the second call. Can you see any potential problem and how to avoid it?
Potential Issues:
- Double charge
- Stripe rate limit
- Race conditions
How I would avoid it would be, just erroring out and asking the user to try again. Logging the error to something like Sentry would be ideal so we can see if it's a wider issue.
- A user has purchased a monthly membership. The system needs to charge this user on the same day he/she joined each month. Create the pseudocode to charge member monthly on the same day of month.
function getMembersDue(date) {
// get members who have fees due today, or haven't paid yet
}
const listOfMembers = getMembersDue(todayDate);
listOfMembers.forEach((member) => {
const success = chargeMember(member);
if(!success) {
// handle error
return;
}
markMemberAsPaid(member);
// do other success ceremonies
});Could run this script as a crontab job on a server or equivalent.
- Describe how to write CLEAN architecture and SOLID Principles
Both CLEAN and SOLID are both design principles that are used to help organise where you place your code. CLEAN is typically used in the backend and SOLID is typically used in the frontend. They both want to achieve the same thing of having single responsibility and loose coupling. For me to program in each design principle I would get the code working as best I can with tests, then I would start to abstract each function written to it's own module where ever the design system deems appropriate.
One things i don't like about both design systems is that it wants you to abstract first. I prefer the thinking of "I will abstract when I can see the abstraction", which is the GO way of thinking.
- How do you approach a situation where a project manager (PM) has not provided clear requirements for a JIRA ticket?
I would try and see if there are other contextual clues that i'm missing and try to get the requirements from there. If there are no other contextual clues then I would send a message to the PM for an explanation or a kickoff for the ticket where hopefully the requirements become more clear.
- Can you describe a time when you had to collaborate with non-technical client to solve a problem? How did you ensure clear communication?
Generally when I had to collaborate with non-technical people it would be the Product Owners or Project Managers and when I explained the. Asking questions from both sides is a good way to ensure clear communication, then just before the meeting is ending, I would verbally summarise the problem and the action points. I would then document that in an email and send it to stakeholders.
To ensure clear communication, firstly I would be open to say that if I were to say something that the client did not understand, that I would be happy to explain it. I would then get the client to explain or demonstrate the issue at hand, if they were happy to. Sometimes what is documented is not what the client has issues with. After everything is explained or demonstrated, I would document and send a copy of my findings to the client. Then write a ticket so that I can fix or research the issue further.