Hey guys, I have phone interview scheduled with Facebook, and had a question about coding. In my work life, I am used to debugging as I go, I keep printing intermediate variables/values/function outputs as I go, to make sure it is all going well. I do not wait till very end to check if my code actually works. I feel this way it is easier for me to debug and avoid going through massive code to find small issues. Do folks do this in coding interviews as well? Do interviewers allow to run intermediate codes(esp on coderpad for Facebook)? Also, if they do, is it considered good or bad practice to spit out variables/arrays along the way in interviews? Thanks!
What you describe seems like verbose logging VLOG used at Google and I'd definitely not consider explanatory intermediate output a bad interview practice provided that you explain that in production this would be toggled off.
Thanks for the answer. Yes, something similar to VLOG or console.log in Javascript. eg: if I am building an array in a complex DP problem, I might throw some logging in there to see how it is getting its value and making sure it is getting built the way I had expected. Definitely this is for testing and will be turned off in production, but I wanted to make sure it is OK.
https://groups.google.com/a/chromium.org/forum/m/#!topic/chromium-dev/3NDNd1KzXeY Make sure you understand the mentality behind verbose logging (i.e. it's quite different from console.log) and communicate this to the interviewer. See above link for background.
In a lot of onsite interviews, you won’t have access to a laptop. Most will be conducted on a whiteboard. So you need to learn how to debug the code in your head as you go.
Yea I don't think FB or Google interviews run on the laptop. So just think of logging in your mind
You can ask for a laptop option.
Neither company will let you run your code - Facebook has execution and syntax highlighting disabled in coderpad
I would not recommend this approach for interviews. I practiced to do the opposite: come up with the final solution using diagrams/pseudo code then write the real code in 5 mins. That way I can focus on legibility, tidynsss and syntax when writing the actual code as the algorithm is already decided.
Yes it's easier to make changes in pseudo code/diagram if you realize some of the edge cases are failing.
Tech Industry
9h
2496
Avoid teams with only Chinese or Indians especially with a Chinese/Indian manager
Tech Industry
6h
795
I haven’t done shit today!
Tech Industry
16h
818
Is Amazon really that bad if you work 60-80 hour weeks anyway?
Tech Industry
Yesterday
29131
Worried that our top performer is an attrition risk. How do managers handle this?
AMA
Yesterday
3279
I’m a professional coaster AMA
During interviews they will ask you write a method which does something, not an entire program from main and everything. So keep in mind that you won't be able to run your code. You can always dry run though, but also think about time. 45 min are really very short.