I usually look at each language/framework and see what problem they were designed to solve, and then implement something directly that they were designed for as my first foray. Then I will try something slightly more specific to my own needs. But normally I already have something in mind where I feel that language X will solve it better or framework Y is more suited to this problem. And even when I am just playing almost all the authors have a few examples or use cases they feel their language/framework solves really well so I will take a simple one and implement it.

At least for me, I found this keeps me honest and using the tool the way it was intended versus bending/breaking it for my needs just to say I used it. Then after I mostly understand it I can see how far I can bend it to my needs, when required.

To borrow from an article I read earlier today (http://weblog.raganwald.com/2006/06/my-favourite-interview-q...)... how would you enable two people to play turn based (and/or realtime) monopoly (or chess, or any other game) over the web? This will almost certainly be more complicated on the front-end than most apps you'll need to build, and complicated enough on the back-end to be non-trivial.

It seems fairly trivial from the back end - it depends really how much you want to deter cheaters. Assuming you're playing with friends, why not just have it all in the frontend and just transmit move orders and chance/community chest cards via a websocket?

It's an open ended question with lots of jumping off points to talk about implementation details and design. And as far as the backend being trivial (it may well be), if a candidate said that in an interview, I'd ask them to walk through how they'd roll their own WebSocket solution. With a different candidate it could jump off into a UI focused discussion. Lots of possibilities.

Its "trivial" in the sense that with almost all the logic on the client (think of something made like a flash game) you'd need only a few core elements (auth, page hosting, user identities or not) on the server, while the majority of the work would be for the client. There's lots of features you might want such as matchmaking, valid move checking and tracking, but it depends on the scope of the project to begin with of course!

Any simple game usually does the trick: snake, Yahtzee, black jack. The rules (requirements) are well defined. The pieces (UI) are well defined. That way you can focus on actually implementing the logic in the language/framework of choice. For websites, pick your favorite restaurant and make it. Borrow the text, pictures, etc. and just focus on the code that creates it and not get off on a rabbit trail doing images in paint.net or making up items.

There is some projects that I usually do to get a feeling of the framework:

- Code snippets/tasks manager. Pure CRUD. If you want to get yourself dirty: add authentication.

- A blog (like SEJeff suggested). If you want to get yourself dirty: try to make it multilingual with SEO.

- Syllabication app. Helps me to find how business logic is best placed into app mindset.

I have to go, but if you need more examples just say! :)

Multilingual blogs? Are you talking autotranslation a-la the Azure/Google translate APIs?

As I understand, the classic thing to implement is a todo list. You have CRUD and then need for some sort of storage solution (whether local storage, or DB backed).

I usually start really small, and add features/refactor as I learn more.

Build a blog, that is straightforward enough and simple to implement in all of those. When you're looking at go, consider gin:

https://gin-gonic.github.io/gin/

My first project in any new language is to make a Yahtzee clone. To date I have done this in JS, PHP, Lua (for the Playstation Portable), C, Objective-C (for both iOS and OS X).

I always use project Euler for the learning a language, once you pass that stage I usually go for pet projects.

Do something you have need for. It'll help with the motivation.