@Naveenkumar: It's not an intro for a beginner, that's for sure. But otherwise, it's not bad at all.
basically a nice introduction.
i would suggest, if you try to teach something, you should avoid any distractions from the core topic to make it easier to concentrate on the stuff you want to show. its cute that visual studio code can now also handle F# mostly,but if its obviously unfinished in a way that every second minute it misunderstands the language in the editor and shows errors that dont exist or claims everything is fine although it isnt...just use visual studio for the demo where it works correctly and add as a comment that visual studio code can also more or less already handle it. by using VS-code you just distract from the F#-demo by fighting the editor all along the demo.
further- dont make type-annotations a thing of taste that different "camps" do or dont, in the shown case its a thing of quality thats easy to explain. you can translate "the compiler infering the type" by "the compiler guessing the type". in many cases the compiler can only guess...if you have no numbers at all in a simple equation, it will likely assume int for the type, once you write a number with a comma it will assume its float, same if you use a sine or cosine where it knows the return type. so if you create a library with a function inside, thats only consumed by others using that library, it is extremely easy that some time later you slightly modify the function, and accidentially make the compiler infere another type for the return value. you wont even notice, your library will compile perfectly fine. it will then only explode in the face of the consumer of your library once he tries to compile and in his code all over the place red lines start to appear. so simply annotating your return type in a function is a very helpfull safety feature that helps you prevent breaking your code without even noticing it.