title | description | slug | category | keywords | icon | order | draft |
---|---|---|---|---|---|---|---|
KM Tech Test |
Analysis & Review |
/km-test |
jobs |
test, tech-test, jobs, github, process |
doc |
1 |
0 |
Hypothetically we are at a point where a developer (me) has raised a problem Pull Request. The problem being that the requirements include the ability to filter a list of Campaigns by date range and it does not
Because this task is unusually clear and precise, I can infer the Quality Assurance tests that my feature must pass include but are not be limited to;
- Does it filter by Search String?
- Does it filter by Date?
- Does the global method called AddCampaigns work?
- Does it look nice?
The Solution fails the second test. The bug is unmissable because it is in one of the few actual requirements
As a developer that’s a bad thing. I knew my code would fail that QA test and I committed it anyway. Depending on how well a teams’ process works, the number of iterations required to complete and merge the task should be minimised. When the Scrum Master gets back to me correctly complaining that my PR has a serious bug in it, I should say...
"Sorry, I shouldn’t have raised a PR that didn’t properly pass QA at that time"
The UI components are connected to a persisted redux backend, so when their onChange events are triggered, the redux store is updated. In the Campaigns component, the a full list of data is connected to redux, as are the filter values
The idea is a filtered array is created and rendered as changes happen to the redux store
The idea is that we loop through all the Campaigns stored in redux and decide which should be included in filteredCampaigns
according to the filter values. This bit doesn't work.
Lines 72-92 in Campaigns.tsx
if (fromDate){
if (!dayjs(campaigns[i].startDate).isBefore(dayjs(fromDate))) excludeByDate = true
if (!dayjs(campaigns[i].endDate).isBefore(dayjs(fromDate))) excludeByDate = true
}
Why is is that dates always cause such problems? Whenever dates are causing problems I have a go-to approach which works every time. I convert everything to unix epoch dates, which are a number.
Specifically they are the number of milliseconds which have elapsed since 1st Jan 1970. Ever so simple and bulletproof to compare, sort etc. Just don't try to read them if you're human
Tech Tests are a valid part of the recruitment process. You can't tell how someone codes by how they talk