Versatile software engineer with a background in .NET consulting and CMS development. Working on regaining my embedded development skills to get more involved with IoT opportunities.
One thing I personally do is write out test cases, which you alluded to with your inputs and outputs. I go through and write out all of the test cases (in the form of test name, input, expected behavior). It helps me catch any constraints I forgot to ask about and hopefully passes along the message that I think about testing when I am writing code.
I have found most companies are fairly forgiving about syntax. No one expects you to remember everything perfectly, especially when you can Google things so easily. If there are parts of code totally irrelevant to the question, I will sometimes just write "..." and ask the interviewer if it is okay that I leave off that part of the code to focus on writing more important code.
Also, whiteboards are awkward. My handwriting is terrible, I forget to write small and run out of space, and holding a marker just doesn't feel comfortable to me. Practicing on a whiteboard really does help, I personally wish I could do all the exercises on a sheet of paper or a Microsoft Surface. I'm not a fan of whiteboard interviews, but I need to quit using that as a trump-all excuse and accept that companies use them and I will be expected to grab a marker at some point.
I usually write in cursive and yes, it is hard to focus on writing nicely vis a vis writing clean code on a whiteboard.
Thank you for the tip about test cases, and you're right to factor them in. An actual at-work downfall of mine is not crash-testing enough (that is a longer/different conversation though). I suppose I can also clarify what types of input might appear as sometimes, checking for type or null is a bit redundant.
My least favourite of the tests are hacker rank or Euler project style ones... (the ones with questions that are difficult to understand without a background in advanced math, and usually it's a test that hr throws me before the initial phone screening or interview. It's frustrating because where I could otherwise attempt to problem solve by understanding the question, I can't do anything. Then again, being exposed to those kinds of questions forced me to learn what binary trees or logarithms were)
Versatile software engineer with a background in .NET consulting and CMS development. Working on regaining my embedded development skills to get more involved with IoT opportunities.
I am in the same boat...I dropped out of university to become an EMT so my formal CS education is a bit lacking. I'm pretty terrible with data structures and algorithms, and since I am job hunting right now, having to force feed myself large amounts of info on the subject :/
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One thing I personally do is write out test cases, which you alluded to with your inputs and outputs. I go through and write out all of the test cases (in the form of test name, input, expected behavior). It helps me catch any constraints I forgot to ask about and hopefully passes along the message that I think about testing when I am writing code.
I have found most companies are fairly forgiving about syntax. No one expects you to remember everything perfectly, especially when you can Google things so easily. If there are parts of code totally irrelevant to the question, I will sometimes just write "..." and ask the interviewer if it is okay that I leave off that part of the code to focus on writing more important code.
Also, whiteboards are awkward. My handwriting is terrible, I forget to write small and run out of space, and holding a marker just doesn't feel comfortable to me. Practicing on a whiteboard really does help, I personally wish I could do all the exercises on a sheet of paper or a Microsoft Surface. I'm not a fan of whiteboard interviews, but I need to quit using that as a trump-all excuse and accept that companies use them and I will be expected to grab a marker at some point.
I usually write in cursive and yes, it is hard to focus on writing nicely vis a vis writing clean code on a whiteboard.
Thank you for the tip about test cases, and you're right to factor them in. An actual at-work downfall of mine is not crash-testing enough (that is a longer/different conversation though). I suppose I can also clarify what types of input might appear as sometimes, checking for type or null is a bit redundant.
My least favourite of the tests are hacker rank or Euler project style ones... (the ones with questions that are difficult to understand without a background in advanced math, and usually it's a test that hr throws me before the initial phone screening or interview. It's frustrating because where I could otherwise attempt to problem solve by understanding the question, I can't do anything. Then again, being exposed to those kinds of questions forced me to learn what binary trees or logarithms were)
I am in the same boat...I dropped out of university to become an EMT so my formal CS education is a bit lacking. I'm pretty terrible with data structures and algorithms, and since I am job hunting right now, having to force feed myself large amounts of info on the subject :/