Showing posts with label new school. Show all posts
Showing posts with label new school. Show all posts

Thursday, November 24, 2016

Stack Exchange: Code Review - Julia's new school

Nov. 24, 2016

Julia started her first day to look into stack exchange: code review, and then, she joined one of discussion - quicksort, she was amazed how she learned quickly in the place.

Her first reading starts from here:

http://codereview.stackexchange.com/questions/5648/any-way-to-make-this-recursive-function-better-faster/5661?newreg=7b2fea2453a54c15bc466355fea0891d

Learn from expert on code review:

http://codereview.stackexchange.com/questions/142808/quick-sort-algorithm/142853#142853

http://codereview.stackexchange.com/a/142853/123986

Julia also wrote a blog about quick sort in 2016:

http://juliachencoding.blogspot.ca/2016/02/quick-sort-practice-makes-difference.html

Julia's favorite reading:
 http://codereview.stackexchange.com/questions/77782/quick-sort-implementation?rq=1

Study stackoverflow profile:
http://codereview.stackexchange.com/users/507/loki-astari

Actionable Items:

Read more live discussion on stackoverflow code review sections, at least find 5 top talents in C++, and find 10 advises from them in a week.

1. First one: Loki astari

Study stackoverflow profile:
http://codereview.stackexchange.com/users/507/loki-astari

Julia's favorite learning on Nov. 25, 2016:

-- start learning: 

http://codereview.stackexchange.com/a/77821/123986

 - 

Compilers Job

Don't do work the compiler can do for you:
int arr[8] = {110, 5, 10,3 ,22, 100, 1, 23};
The compiler is better than you at it anyway and it will prevent errors. Here you have said the number of elements is 8. As a human I can't see that at a glance I could count them to verify but as a human I am lazy and going to assume you got it correct. If you did not get it correct then we will have problems.
So let the compiler work it out.
int arr[] = {110, 5, 10,3 ,22, 100, 1, 23};
Now if the array changes size you only have to change one thing (the data). Rather than two things (data and size).
 -- end of learning  --

Coding Style - Great advice on coding/ design, a hackerRank question:

http://codereview.stackexchange.com/questions/140825/keeping-track-of-the-tennis-score/140827#140827

Sunday, February 21, 2016

New School - HackerRank - algorithm: Beautiful Pairs

February 21, 2016

HackerRank is Julia's new school -  her new lover.  But problem statement is too long to read, and the test cases are not very clear.

Julia starts a new journey with HackerRank, she likes the algorithm problem solving. She spent 2 hours on Sunday morning to work on an easy problem in a "101 Hack Feb 2016".

Here is the question:

Beautiful pairs

Problem Statement 
 

Here is her answer with a bug - failed 2 of 6 test cases:
   

Performance review:

  40 minutes - calm down, read problem statement - she has to understand the problem first.

  Failed 2 cases - that is the value of HackerRank  - good practice.

Lesson learned:
  20 minutes coding,
  20 minutes bug fix: Array size: 1000->1001 to remove run time error,
  the score: from 3.8 to 15.80.
  Wrong answer for 2 test cases.

 Here is the perfect version - fixed the bug.
 

Conclusion:

Each school is different, HackerRank is cool! Julia, just be humble. Make mistakes, always work on easy question, work on the first one in next 5-10 practice. One question a time.

Julia, you have to go through hackerRank contests, go through training - the article detailed on this:

  • You’ll learn how to critically analyze your work. Because you don’t get credit for solving a problem until the code you write can generate the correct results for a large input set (and you don’t know what that input set looks like), you’re forced to think about things such as time complexity, memory usage, and nasty corner cases. Importantly, most of this work happens outside the context of a debugger. Debuggers are invaluable tools for figuring out why a given piece of code is buggy, but it’s better if you can write bug-free code in the first place. In an interview situation, candidates who can’t statically analyze their code generally have trouble showing their solution is correct (or figuring out why it’s not).
https://medium.com/@dpup/whiteboarding-4df873dbba2e#.ps92c99lb
https://code.google.com/codejam/contests.html
https://code.google.com/codejam/contest/6224486/dashboard#s=a&a=0

Be a better programmer to grow in your current job -

http://blog.hackerrank.com/3-ways-crush-technical-interview/
http://dandreamsofcoding.com/2014/03/18/dissecting-an-interview-question/
http://dandreamsofcoding.com/2015/01/09/dissecting-an-interview-question-math-is-hard/
http://dandreamsofcoding.com/2014/08/01/dissecting-an-interview-question-reconstructing-a-tree/