Course code: WEB-5
  • Years with company: 1
  • Years programming: 10
  • Primary programming language: c/c++
  • Other programming languages: (occasionally) c#/objectiveC/java/web programming languages/assembly
  • Unit test harnesses: google test
  • Something else: hopefully you would not report my online coding results to my employer, I don't want to go through job interview again. also, I am having an important meeting on the 2nd hour of the 1st day of training(for the whole hour), I hope you could make the course such that I could still catch up after coming back from that meeting. Thanks in advance.
  • Test practice now: on hardware, write python scripts or use host testing tools to test the specific functionality. we also used google test to write unit tests.
  • Target system: not sure I understand "target system", but I work on firmware on SSD controller
  • Dev tools: xtensa IDE; source insight viewer; gdb in linux;also some customized flight recorder; when using ARM processors, I enjoyed using ETM/ETB with lauterbach debugger
  • Build time: 30-60 minutes
  • Coding standard: hard to describe in one line, usually I read through documents and follow the rules for a project/company, such as naming conventions, line length, file length, tab/space rules, compiler warning rules; comments rules; design review rules;
  • Function too long: when there are code that are doing repeating things; when there are code that could be used by other modules, we could wrap these sub-bloc of code in to new functions
  • Code reviews: we use code collaborators
  • Code time: 20
  • Test time: 40
  • Debug time: 40
  • Favorite thing about dev: money;fun(more important); sense of accomplishments
  • Least favorite thing about dev: cannot control other people's activity, for example, your product architect, your testing team, even if you do a good job, other people could still screw up the product
  • Tdd knowledge: test driven development, sounds pretty self explanatory; never heard of it as a academic term
  • Why are you attending: to see how things should/could be done and see the differences between what I am doing, sometimes a good idea could save tons of time in debugging, for example, which direction to go when debugging.