In a week time, I am going to have a technical interview and I was asked to bring an example of my own work to discuss. I am going to show the proj...
For further actions, you may consider blocking this person and/or reporting abuse
Hi Anna,
They probably wont be looking for perfection, more likely they'll be looking at how you work, your logical approach and ideas.
If you're showing a home project you've been working on, it's perfectly acceptable for parts of your code to be work in progress. If things need to be improved and you don't have time to do it before your interview, then notate what needs to be done and be open about it - Show that you are aware of priorities.
Most of all though, just show a bit of passion and interest!
Good luck and all the best.
I'd go further, and say that parts that are work-in-progress or otherwise buggy are important, because you get to talk about them. You get to talk about how if you started from scratch you might have done something differently, and which problems you are prioritising, and why.
100% agree, with a special accent on the priorities part. I'd always take a dev that knows how to choose his priorities over one that "perfects everything" (whatever that even means).
That said, I think that you should have at least some part of the code sleek and well tested, just to show that when you eventually put a priority on something you do it well.
Priorities are super important, yes. I have a lot of things/bugs shoveled into the backlog, including tests on many non-critical parts. Otherwise, nothing would be working even at this point.
Thanks a lot! It gives me more confidence.
Hey Anna,
while I haven't had a situation where I had to review side-project code during an interview, I had some interviews where I had to present and review pseudo-code and sketches for problems that were given during the interview. From that, I can advise the following:
Give a short description of the problem you're solving
Give your interviewers a quick run down of your perspective and the problems you wanted to solve with your solution. This makes it more likely that you all start with the same mental model.
Guide the interviewers through your code
Have a good mental model of the different parts of your application and how they work together. Identify important paths through your application that you can talk about (almost like user stories). For example, you probably don't want to spend a lot of time in your utils package, talking about string helpers and so on.
Have justifications for technical decisions
"Why did you use that library/data structure/database/...?"
Even if the answer is just: "lot's of people use it so there's a large community to ask questions to.", as long as it doesn't look like it's the first time you're thinking about that question, you'll probably be good.
In general, I like to think of an application as a complex topic that I've written an essay about. Now the challenge is to present that essay concisely and to the point in 10-15 minutes.
My advice on this:
check you comments
There is a chance that there a comments like "WTF is this not working, check again" or any links to reference sites you placed in files for future reference. You don't have to remove them, but make sure they are looking good :)
Explain your logics
It is very likely that they spot a loop, a part of your code with some uncommon functions or spread operators and ask you to explain what it does and why you choose to go with that.
Overview
Don't jump straight into the code. Give them a little bird's eye view of your project before you dive into the code. This helps them understand it better and chances are that they were about to ask for your goal with this anyway :)
This is good advice, thank you! Especially the comments, I found quite a few like that. 😅
Glad my comment helped you!
Would love to read an article with a recap of the interview and how it turned out 😊
I am SO HAPPY to hear that this is how you are doing your interview! My first ever dev job interview I brought in my own code for a project I was working on. I spent most of the interview walking the 3 dev guys through how it worked, what I wanted to cleanup, what I wanted to add, etc. Part of it even broke when I was showing them some functionality, it was mortifying! I got so nervous, but we ended up pairing to fix the bug and I ended up getting the job! 😃
I know you are worried, but I guarantee working with your own code is going to be so much nicer than if they were asking you to sit down and write it from scratch. Keep in mind they are not looking for perfection, they likely just want to see how you work and think through things.
GOOD LUCK! 🍀
Thank you! Your story is very encouraging! :) It's just my fear of being not good enough talking too loudly in my head: "What if the code is soooo bad they are going to feel embarrassed on my behalf?" 😅
Most important thing is to be confident! You wrote that code and you know it, its just because of time you might forget some things but you will always have an idea.
The next thing in this week time, find out the shortcoming you faced in building that project. The interviewers are always interested in knowing some cool facts and approaches, the way you bend your thought process!
And be confident, you will rock it !
Thank you! :) I think, being confident is the hardest part since I know how many places where the code is crap. Good thing is that it used to be a lot worse and I am improving all the time.
I have a ton of cool stories about this project and various shortcomings, yep.
Update.
It actually went really nicely. First, I showed the project in action and explained how it came to be and what the goals are. After that, I was asked to show one component of my choice and I went with a recently refactored one and explained my motivations for the refactor (btw, it was my first try on react hooks!).
Then, on another project where I did backend as well, I showed two parts of the system I've been doing by myself, and we discussed the decisions made, SQL query efficiency and stuff like that.
I also got both nice and useful feedback after! :)
I think it is definitely a better way for doing technical interviews, compared to coding on the spot.
I came across this question late and now I'm curious - how did the interview go?! I'd love to hear about it, and what reflections you had.