My problem was:
Given a chemical formula return the composition and number of atoms of which it is composed. For example H2SO4 would give 2H 1S 4O, while an hypothetic H2C2H4C would give 6H 3C. It gets more difficult whne you consider that you also have to deal with parens, like H2(CO)4 which would give 2H 4C 4O, you can also have nested parens.
I got overall good feedback because of the way I kept talking about the problem at hand and how I was going to tackle it I think that's my main skill in tech interviews.
A great suggestion I've got is to talk about the different small functions I am going to use, for example something like
parseMolecule :: String -> { String : Int }
multiplyDict :: Int -> { String : Int } -> { String : Int }
getTillClosingParen :: String -> (String, String) etc.
really simple but with meaningful names and types signatures.
It turns out this practice is called "programming by wishful thinking", really helpful, I am going to read a couple resources about it.
We proceeded by adding tests to the existing codebase, I think I've expressed correctly how one would address a situation like this, a couple of things I wasn't sure about:
- mocking in Jasmine seemed counter intuitive and did not work as I expected, we had problems mocking an object (I'm using to sinon in node-land) but that might just be me lacking experience with the tool
- I wasn't sure how to test a couple functions, one was using the other and we were concerned about not duplicating the tests yet keeping everything tested. I think in the end we went in the right direction, which was mocking "the other thing" while testing the first
https://www.youtube.com/watch?v=bmFKEewRRQg
He makes a few good points:
- have seniors and juniors work together, the first will benefit from explaining what they know, the second will benefit hearing new stuff
- "first code everything you can without side effects, then code your side effects" - functional first development
Only deal with inputs and outputs, the only state is in your tests. Write and compose your functions, then write your tests around those.
Plus he introduced the following concept.
Everybody codes. But only one gets to code physically.
- 4-15 people
- 2-8 hours each
Help comes from all directions and people think out loud to help everyone in the mob follow along.
The driver cannot write on their own, they could only write what they are told to.
It works completely as a tool runnable like $ node cerebro.js, for now it's enough like that. Now I need to focus on
the current problem which is about relative paths from the tests to the source code being "off by one", for example I have
// test.js
const myLib = require('../lib/myLib')this is a problem because when I run Cerebro all paths should be relative from the root of the project, not from the test
folder. The immediate solution would be to just change .. into ., but possibly there's a better way, I'm going to think
about it on the way home.