Form3 Senior Software Engineer interview questions

There was an assignment to implement a fake API client using Go. The assignment review was very confusing. The review wrongly claimed that existing test files or CI/CD integrations are missing. I assume they have unannounced expectations from the assignment. Also, the review claimed that following SOLID principles and clean architecture is over-engineering and pre-mature. Even, they said about my one method interfaces need to be simplified. They could have other perspectives, but this doesn't mean the others are garbage. This became a waste of time for me. This was the worst review experience until now. They need to review their reviewing process.

Call with HR then a take home technical test which is publicly available on their github They're expecting full unit test coverage. I missed a few cases, however, the cases I did write had random insults, memes and gibberish in the method names - this wasnt highlighted in their review of my code, I can only surmise that they didnt actually read the tests and simply looked at the code coverage. I didn't think providing more than 1 integration test for a take home test would be necessary even though they expect it in the test (I made it clear in my readme that I wasn't going to write an entire suite of integration tests), I was hoping they wouldnt notice or be happy with the example test that I gave - I was wrong they expect full coverage. Good on them for actually checking this part, I thought I might be able to get away with it. I saved time in this test by copy and pasting a popular http/rest library almost verbatim. I greatly simplified it and engineered it to fit their specific use case, their readme says not to copy anyone's code but they didn't notice - it saved me many hours of work. They didn't bring this up in the review of my code but it didn't matter as they thought the code had "an unusual design". Don't use the go-resty design, my reviewer didn't like it. I guess it depends on whos reviewing your code but my feedback was mostly about testing as the main reason for failing. For future candidates - theres far too much work in this exercise for an engineer to review - you should be able to cut many corners by simply focusing on coverage and not the quality of the test. If I could do it again, I would have submitted my tests without any assertions to see if they would have noticed (I doubt they would have). If you look at the test you'll realize its not a small task, with everything they're expecting theres a fair bit of code to write. Code that in a normal sprint would take up many PRs and a lot of collaboration and feedback. I think requiring a production grade api in "8 hours" shows the severe lack of experience and judgment for whomever wrote this test. Its not surprising that both candidate and reviewer are going to cut as many corners as possible. I cut corners and got caught but lazy code reviewers cut as many corners as I did and only confirmed the exercise as pointless and without merit. The test seems more like identifying developers who think and write code like they do. They clearly have a focus on testing, which is good but I'm afraid I, like many other developers, don't have the spare time to spend on that kind of tech test.