Welcome to another installment of Learning How To Learn! Last time we discussed how to create a node server and Bloom's Taxonomy of Learning. This time we are going look at the larger project they were being used in, and evaluate our progress.
Where We Started
In my first post in this series, we discussed the four step plan to solve any problem, the APIE method (The four steps are Analyze, Plan, Implement, Examine.)
There we went over the problem, and the first two steps. The 'problem' was that I didn't know backend development. Then we analyzed what it would take to learn it, and created a plan. The plan was to have 3 - 4 fullstack projects that would be the meat and potatoes of the learning, and 2 - 3 mock interviews to gauge my progress and direct my efforts effectively. In this post, we will go over the last two steps, implementation and examination.
Implementation
Since my first post, I have completed 1 mock interview and 1 full stack project. Lets start with the mock interview.
These interviews as designed to be tests. Not as in pass fail, but as in diagnosis. There is no job offer on the other side of this interview, and that's really good for learning. In the words of James Clear,
"Goals are good for setting a direction, but systems are best for making progress."
There's no pot of gold at the end of this rainbow, so I have to make the ride worthwhile. Being goal oriented towards a job changes how I view that interview. My goal becomes "passing the test". Without the looming pressure of a job on the line, my focus shifts from employment to understanding my readiness as a candidate. That's what I need most desperately at this stage, is to have a crystal clear understanding of my readiness as a candidate.
So if I'm getting a diagnosis, I want a good doctor to do it. My interview was conducted by my friend and mentor, a senior engineering manager at a local tech company. He has interviewed applicants many times before, so I felt he was qualified to conduct this interview. The interview took about 30 minutes, and it was split into two sections: questions about me and my history, and questions about the technically heavy aspects. These are all the questions that were asked:
What got you into software engineering in the first place?
What are some of the hardest technical problems that you have had to solve?
Can you describe a project that did not go as planned? What happened and how did you adapt?
Can you tell me about a time where you had to optimize some code either for performance or for scale?
For the technical portion of the interview:
What is the event loop, and how does it work?
What is Middleware, how does it work, and can you provide me an example? (Long time followers of this series will recognize how this example targets the first three layers of Bloom's Taxonomy)
Can you explain the concept of streams and how they improve performance in Node.JS?
Describe how you would implement error handling in a Node.JS application and what are some of the best practices around that?
What is your understanding of object oriented programing?
What is your understanding of functional programming?
Can you talk about the difference between authentication and authorization?
What are some of the differences between a relational database and a noSQL/document database?
What is an ORM and what are some that you may have worked with before?
What are the 5 most common HTTP verbs and what kind of functionality to the map to on the server?
How would you handle logging and monitoring in a Node.JS application?
What are some of the typical layers in a backend application, and what function does each of these layers server?
Do you have any questions for me?
17 questions, all based on a example job description we had agreed upon a month before the interview.
That brings us to the project portion of the implementation. Having completed the interview, I set to work creating a fullstack application that would allow me to answer a few of those interview questions.
My application was an internal wiki for my DnD campaign. The frontend was going to be a plain, no frills set of pages that would contain text based information. It would also connect related information to each other, so that my users could find an entry, read all of the relevant information, then see everyone and everything that was related to it.
For the frontend, I used:
- Next / JavaScript
- Pico CSS / Vanilla CSS
and for the backend:
- Node.JS
- SQLite
The end goal was essentially a C.R.U.D. app. I wanted my non-technical players to be able to Create, Read, Update, and Delete the information in the database. This would require me to figure out how to transform actions on the frontend into changes in the database. If I could do this, then it would solve a genuine issue my players have been running into.
Examination
Lets now examine if those two implementations did their job correctly.
Lets look at the interview again, and when I tell you that this mock interview had me feeling worse then that last time I went through surgery, I mean it. It was the kind of interview experience that made me wish I had worn brown pants. Out of the 17 questions, there were maybe 5 I feel like I gave really good answers to. The other 12 ranged from not great to complete ignorance. I was mortified by the end of it.
Which was exactly what I needed. My mentor had chosen his questions well, and we now had the clearest view of my readiness as an applicant that I had ever had.
It is worth noting that he did not expect me to answer every question well. The experienced among you will have already seen how these questions range from basic to advanced. These questions included things he knew it would be unreasonable to expect out of entry level applicants, because it would allow him to see just how deep someone's knowledge goes. That being said, I did not get the fictional job I was interviewing for. I have a lot of learning to do before I am ready for another interview.
The project delivered. It was an incredibly motivating experience. It was the perfect mix of familiar competence and new learning. Having a good back ground in React and JS, I wasn't starting from scratch Next.JS and Node. Given this was the first time I was building an API, I chose to go for the most basic and functional one I could manage. And that was a tall order still. I only have routes for GET, POST, PUT, and DELETE, and it only maps those request to the database. I did not include anything like authentication, authorization, or pagination. The scope of this project was small enough, along with my target audience, that those weren't essential to the success of the project.
It went half a month over schedule. I feel good about that, though. Part of that was due to the fact that I got started late, I had an opportunity for freelance work, and moved during that time. Other than that, I have been spending four hours a day at my local library cranking out code and fixing bugs. Hands down, this past month and a half has been the most consistent and productive period of my learning journey. I have never before had so much skill gain in such a short amount of time. And if I keep busy, I won't loose it.
All in all, I sank between 80 - 90 hours into this project, and each one felt important and worth while. If I had to redo it, I could probably do it in 30.
And I can't overstate how satisfying it feels to have something you built function and provide value to someone. The fact that it works and my players use it is awesome.
The only real concern I have with the project is it didn't move the needle very much, in terms of my candidate readiness. Of the 17 questions, there are only 2-3 I feel like I could answer better now. It is possible that this project gave me the foundational knowledge necessary to understand the answers to as much as 7 others, but that is not the same as knowing.
Conclusion
I think the system is working very well, and that going through this cycle again would put me significantly closer to my goal. I am worried that my learning is general and not specific, accidental and not focused. With the next project, I would like to link specific goals of the project to specific learning objectives. For the time being now, I have a functional project I can demonstrate and I feel confident adding Node.JS to my resume. That's enough for me.
Do you have any ideas for projects I should consider? My next step takes me into the world of PHP, so if you know of a project that works well with laravel, be sure to leave it in the comments!
Top comments (0)