Hi there,
I have my first ever interview in a couple of days for a front end developer position for a smallish start up. They’ve told me they don’t believe that timed challenges and other tests of that elk are effective ways of determining a candidate’s skill, so instead I must take in some work and talk to them about it. They are going to grill me about it and challenge my methods and design choices.
I’ve decided to take in this tic-tac-toe game I made in React. It should be unbeatable and all my testing has indicated that it is. This should be the case for 5 x 5 and 7 x 7 grid as well as the traditional 3 x 3. The actual source code is here. I know it isn’t very pretty at the moment, so I’m just talking about the javascript really.
So my questions are: What should I talk about when I’m presenting my project? They didn’t give me any topics and I really struggle with such open ended questions.
What do you think of my code? What do you think they might challenge me on on this code? Plenty I’m sure!
Any advice or critique of my code or prompts to make me think about the right things would be greatly appreciated!
Sorry, I don’t have time to go through your code today.
I will say that interviewing is a skill. It takes practice. Odds are, you won’d do well your first time out. That’s OK. Most of us have to go through several of these things before we get a job. Many coders are not naturally good at interviewing and need to work at it. You will get better. Or hopefully I’m wrong and this will land you the job. I hope that’s the case. I just want to let you know that it’s OK (and typical) if you struggle. And remember that interviewers know this too. They know it is tough and stressful.
How to prepare? First I would practice explaining your code. Traditionally you do it with a little rubber ducky, but any inanimate object will do. I mean this seriously - actually out loud, explain your code. And if you can find another coder to walk through it (even over skype with screen sharing) that would be great too. Do it a few times.
Second of all, I’d google things like “interview questions for developers”. And answer them out loud. Get used to talking about yourself. One thing that annoys interviewers is someone that can’t seem to put two sentences together to answer a question. It doesn’t have to be perfect, but it should be comfortable.
Lastly, I’d say your goal is to sound confident, but not cocky. You should accept that you don’t know everything but that you can learn anything and you can’t wait to do it. You should sound relaxed and fun - you want to sound like someone that they want to spend 40 hours a week with.
Search the forum. I for one have given out a lot of advice in posts. I also have some posts on getting my first real job.
Best of luck. I hope you get it. And if you don’t, don’t beat yourself up. Just keep working at it and getting better. Learning to code is only about 2/3rds of getting the job. It’s important no doubt, but it’s these other skills that get you over the top.
And be sure to let us know how it turned out. Others can learn from what worked and what didn’t.
2 Likes
Thanks for the wisdom Kevin. I particularly like the advice about practising explaining it out loud, I think you’re right and that will be essential. The first step I guess is figuring out how I should go about doing that.
I reviewed some of the code and here is some of my personal opinions on it
- I couldn’t find a single comment.
I’ve heard of interviewers specifically looking out for comments when inspecting code during interviews. (submitted or otherwise) Their reasoning is this: “If the programmer comments their code, it’s usually an indicator they care about the rest of the team, as they are going out of their way for others”. Lots of people say they are “team players”, but showing you are going above and beyond to make you code easier for other developers to digest is a very valuable skill, that only adds value to a team, rather than hinders it.
I will give you props for very explicit names for variables/functions (maybe even too explicit hehe :P) but since this isn’t a straight forward app implementation, where the reader has an automatic understanding of the code, the lack of comments forces the reader to read the code in its entirety to get context. For example, the React components don’t need much if any documentation, as it should be clear. But the helper-functions and hard logic is a little harder, as its very domain specific.
Plus, if your explaining your code/reasoning, having comments helps you during this time too. It should be a reminder/explainer/summary/“what and why” of the code below it.
-
Code structure isn’t clear to me
disclaimer I’m not a React developer, so I might be missing the obvious.
I spent maybe 5 minutes jumping around between folders/files and outside of the components folder and didn’t get a very clear picture of the structure of the code. It seemed like a lot of different functions exist in different folders and files that evolved over time. I only skimmed over the code so I might be missing the point, but a clear layout and structure helps developers recognize patterns and helps them understand where things are.
Don’t explain to me the real structure, just be prepared to explain how the code is setup, as if I were going to become the new maintainer of the project.
-
You used min-max algorithm right?
I personally couldn’t find it, and odds are most web-development jobs wont’ care about this, but anyone that has ever tried to program a tic-tac-toe game probably ran into this game theory, and had to implement it correctly.
Now beyond that your code looks well formatted, clear and concise.
Now onto what I’d be prepared to explain in the interview.
- Performance, data-structures and algorithms.
You might be going in for a front-end developer position, but knowing the deep concepts of your app are still pretty critical when it comes to performance. A key part of that is how your code “runs”, which comes down to data-structures and algorithms.
So for example, you say your app works for 5,3,7 grid sizes, but what about larger. And If say the grid was 10k by 10k, what concerns would you have on performance, and where would those concerns be focused. I only bring this up because bad algorithms and approaches might be passable at smaller sample sizes, but at larger scales things might break down. I’m not saying your app should run smoothly with 10k rows, but you should know where the warning lights will be The only way you’d know this information is you know how efficient your existing code is.
-
How easy would it be to add new features
Odds are your going to be writing software that is going to change. For the interviewers, gaining some insight as to how you would handle requirements changes is pretty important. Since you know this code very very well, you should be able to provide sensible answers. I wouldn’t worry about the actual answers, like saying “any requirements change will take no time at all!”, rather providing reasons, and explanations for your estimates is your job. Don’t be a yes man if it can’t actually be done in a reasonable manor, or don’t make up something to look good. Odds are you should be able to estimate them pretty well since you build the code yourself. You can think of a number of requirements that could be asked for and think of some basic estimates yourself. (how much work would it be to add 2 players for example? More grid sizes)
-
If you could improve on this code what would you do?
This is a fun one. Odds are you didn’t spend 10 years working on this code, so you probably could still spend more time on it to improve it. So knowing how, what and why you’d improve it is a good thing to know. Knowing your flaws is just as important as knowing your strengths, same goes for work you have done. I’m pretty sure you know where you can make improvements, and probably have even thought about them.
-
What challenges did you face building this project.
It’s been said Elon Musk asks these sorts of questions during interviews to find problem solvers. The ones that can provide detailed explanations on challenges faced, means they were the ones that will face the challenges, and solve them. If the person being interviewed can’t elaborate on the challenges faced, then they are probably not the ones who solved said challenges, thus they aren’t real problem solvers.
So, if you spent a whole week getting the min-max algorithm to work, elaborate on it. It’s one thing to say “I didn’t know how to program so I googled it”, and other to say a detailed explanation of how the computer is unbeatable, as you spent 2 weeks getting it right.
-
Finally, think real long and hard as to other ways you could of done the project. If they are going to “grill you on your methods and design choices” prepare to defend your approaches, and or take in the recommendations to make the code better. No one’s code should be automatically better than anyone else’s code until there are reasons provided as to why it’s better. Some choices are totally preferential, but some are very reasonable. (like lack of comments for example) All of them should be heard and decided upon, so prepare to take in critique, and advice.
Goodluck in the interview, and don’t forget every interview is a learning experience, regardless of the outcome 
4 Likes
This is the dream response I had in my head when I posted this. Thank you for taking the time to review, this is extremely helpful. I appreciate it a lot!