Engineering Principles Flashcards
Engineering Principle 5 - Explain a time when you demonstrated this principle
WE HELP EACH OTHER
In my final project at the Makers Academy bootcamp, we really wanted everyone to be involved in all aspects of the project. Our main focus for the project was on learning. It didn’t make sense for us to have all of these features, if we didn’t understand how they worked. We wanted each person in the group to be able to understand and to be able to explain every feature.
We were realistic with this, and knew that we only had 2 weeks to complete the project, and we had bank holidays aswell. So we came up with the decision, that at the end of each day we would each share what we had learned, show the code and explain it to the members of the group.
This worked really well and allowed everyone to learn all aspects of the project.
Engineering Principle 3 - Explain a time when you demonstrated this principle
WE INNOVATE IN OUR PRODUCT, NOT OUR TECH STACK
I feel that it makes a lot of sense to choose a technology or framework that would provide the most value to your users and business.
An example of this for me is me choosing to commit to Ruby and ruby on rails, while everyone else in my cohort has gone with javascript and whatever javascript framework is cool at the moment.
The reason I have chosen ruby on rails is that, while learning a new language is great and a lot of fun, I’d much prefer to build things and projects. And i know that Ruby on rails allows you to get projects and features up and running quite quickly. And I also know that it’s used in a lot of big companies, so it’s proven that it’s effective and can handle large amounts of data and users. Also, users don’t know or care which programming language the product is built-in, they just care that it runs smoothly and
Engineering Principle 3 - Explain a time when you demonstrated this principle
DO THE SIMPLE THING
We don’t build software for the sake of software. We build software that delivers value for our users whether they are our customers, employees or other stakeholders. We don’t argue endlessly. We make small changes that deliver business value quickly and test these with our users to get feedback quickly. We resist the urge to over-engineer or add just one-more-feature. We let our users and the data tell us where we go next.
This principle makes a lot of sense to me, i haven’t been able to put this into practice as the projects that I have built in the past haven’t had real users, but I completely understand the concept and the reason behind it.
A little while ago I read a book called the lean startup, and the author talks about a concept called the build measure learn feedback loop, which is a similar concept.
Obviously spending a lot of time planning, building, and perfecting a feature that hasn’t been tested with users is quite risky, and also just deploying features with no planning is just as risky.
So quickly going through cycles of the build measure learn feedback loop is the best solution, as you’re quickly finding out what the users want, then delivering exactly that.
Engineering Principle 3 - Explain a time when you demonstrated this principle
TECHNICAL DEBT IS USEFUL
The deliberate, conscious, and careful accumulation of tech debt is a powerful tool that lets us ship code and value to our users faster. We are not afraid of it and we know we need to repay it over time to avoid the interest becoming unbearable.
I haven’t had too much experience with technical debt, but I do have an understanding of it.
I understand that it can be very effective in delivering value to users faster, and if there is a feature that can benefit users while bringing the company in more money, you’d want that feature to be deployed sooner rather than later. But also knowing that that debt will of course have to be repaid over time.
I spoke with one software engineer about it and he told me in a previous job he had, the company let the technical debt accumulate to over a million lines of code and it was just impossible to fix that.
So overall I think it definitely can be useful if it’s managed correctly.
Engineering Principle 3 - Explain a time when you demonstrated this principle
WE ARE CONSIDERATE CODERS
We acknowledge that others will need to modify our code. We write code to be read by humans, debugged by humans and maintained by humans. We distill complex problems into code that is concise and easy to follow. We favor platforms, tools, and libraries that are easy to understand and have good introspection tools. We don’t swallow critical errors silently. We use comments and commit messages to explain the why as well as the what.
I really love this principle. I know that saying code is only written once but read many times, so I try and pride myself on writing clean, neat code with clear method and variable names.
In the Makers bootcamp, as you’d know, you’re paired randomly with people in the cohort, and if you’re paired with someone that is a bit behind you, you pair using their code.
And I’ve had an experience in the bootcamp where I was pairing and we were using my pair partners code, and she didn’t use clear method names, and was using single letter variable names, like u = User.new.
And it took me a little while just to figure out and understand the code. It was only a small project so it didn’t take too much time, but I can imagine if it was on a larger scale, and every developer had to spend an extra 15 minutes or so just to understand the code, that’s going to accumulate into quite a bit of technical debt and end up costing the company a lot.
What got you into software engineering? Whats your experience?
The majority of my past experience has been in sales, but it was never something I really chose to do, I just sort of fell into it and stayed. And it started getting a bit stagnant after a while.
I started coding online through Codecademy and just fell in love with it, and I’ve been coding every day since.
My boyfriend actually went to makers about 6 years ago and he recommended it to me, so I joined the Bootcamp and its been the best thing ive done.
It’s a 16-week intensive coding Bootcamp that is heavily focused on ruby and TDD.
Why do you want to join Cleo, specifically?
3 things -
- From everything that I have read about Cleo and the people that I have spoken to, Cleo seems like such a positive and inspiring place to work. It would be amazing to work at a company that actually makes a difference and has a positive impact on peoples lives.
- The product is amazing. I think the fact that it tells you which bills you have coming up and when would really help to remove some of that stress, and in the fun, sassy Cleo way. It’s like Cleo has its own personality.
There is this really well-known finance book by an Australian author called the barefoot investor, and it’s basically a money guide and a book on budgeting. And one of the tips he talks about is to make budgeting fun, so he recommends to plan a date night with your spouse or even take your self out, and do the budgeting then, because you’ll be more likely to do it if you make it fun. And I feel like that’s exactly what Cleo does and that’s part of what makes it so successful. - I really love Cleo’s mission to improve the world’s financial health.
I know that saving and budgeting is really hard for most people, for many different reasons. it could be lack of knowledge, or lack of discipline or simply just not enough time.
I grew up with a single mum and when I was younger she would work 3 different jobs just to be able to support us, and she struggled a lot with budgeting, and I know that if she had this app back then, and even now, it would’ve made her life a lot easier.
- Creative mindset and thought of the user experience is something that we really look for, particularly as we are more of a creative focused environment, so have a think about pieces of work that you are proud of that showcase a passion / interest in the visual aspects and user focus of Frontend.
The team really look for a passion in UI/UX, the visual aspects of Frontend, wanting to be involved in Design decision-making etc. so would definitely advise having a think about pieces of work in this area that you are proud of.
If they ask about app/website - Duolingo. Gamify (turn into game) with the streak freeze.
The final project I did at Makers, EdUp - we designed the app to be a more user friendly and more visually pleasing version of a current app. Dynamic calendar, we used unidraw illustrations throughout.
Our engineering team love to be reflective - it would be worthwhile having a think about challenges you have faced / failures you have experienced in your working career and the reasoning behind that, plus more importantly how you have gone about trying to rectify them.
Reviews -
the very first one i had no idea what to expect, so I had some room for improvement. But after I got my feedback, I made sure to work on everything that was said and written on the scorecard, I practiced all the advice that was given with katas and other projects, and then when I had my second review, I made a huge improvement, and it was great to see that in the scorecards.
Do you have any questions for us?
What is your definition of success for this role?
What’s the onboarding process like?
When will I first be writing production code
How do you make sure your technical debt is not too much?
Values # 1 - Make it happen
Taking risks and being ok with them not always working
Taking the initiative to solve user problems, whether they directly involve you or not
Posing solutions - not just problems
Risks - makers
In MOJO - we were super busy so when Lawrence was busy i would step up and do presentations even though it wasn’t my job.
Value #2 - Learn at speed
Using all means at your disposal, data, research, A/B tests to learn quickly and take action
Deriving meaning from the data, whether qualitative or quantitative to optimise to make a real difference to users’ lives
Testing quickly, failing fast, adapting, going again
Supporting new ideas and and empowering people to test them
A little while ago I read a book called the lean startup, and the author talks about a concept called the build measure learn feedback loop, which is a similar concept.
Obviously spending a lot of time planning, building, and perfecting a feature that hasn’t been tested with users is quite risky, and also just deploying features with no planning is just as risky.
So quickly going through cycles of the build measure learn feedback loop is the best solution, as you’re quickly finding out what the users want, then delivering exactly that.
Value #3 - Bring good vibes.
Bringing your whole wonderful self to work
Inspiring others, helping each other level up, and doing your best work
Creating an environment that’s inclusive and respectful
One of the main reasons I want to work at Cleo is because it’s a community, and I know that everyone that works there, well at least everyone i have spoken to, has told me that everyone is so supportive and kind.
I love this culture and try to instill it wherever I go. Even in my cohort at makers, I tried to instill this value by organising social game nights for everyone every couple of weeks, because I knew that the closer the cohort was, the better developers we would all be. Also because i love people and games
Product Engineering
Share examples of how you’ve been a great Product Engineer recently. Think of these as your “wins” and how you’ve combined business, technical, and customer concerns to build great product features.
Share situations where you wish you had made better tradeoffs between business, technical, and customer concerns. Think of these as your “growth opportunities” for being a Product Engineer; what would you do differently next time?
TODO
We’ll ask about your strengths and areas for growth, and find out what you’d want to get out of your first week.
Areas for growth - A lot to learn, I know im not going to become a senior dev overnight. I know I will constantly be learning a lot in my first month/year etc at Cleo.
Strengths - Fast learner, passionate about coding, love Ruby. Believe in Cleo mission, once im involved in a project i give it my all.
