Frankly, if you don't know how to use basic spellchecking and grammar, presenting yourself as a candidate for any job these days is going to be tough sell. For development jobs, one simple mistake might be overlooked but your text has numerous misspellings and improper capitalization of words and names. That lack of attention to detail is enough to get your name crossed off the candidate list very quickly.

Why have you committed files like "hs_err_pid33096.log" to git ?
I am not sure about the job interview, but is this your personal project ? If yes, then you're expectations from an interviewer is quite huge if you're expecting him/her to sit and read your personal code.

Hi, while we're on the subject of github, if you could take a look at mine and tell me any glaring mistakes I would greatly appreciate it. I also have some files like hs_error.log in my projects so I'll delete those. Does it matter if I have repositories that are projects I made for figuring out some things? https://www.github.com/aquino-a

It's everyday, bro

Rob Berk

Greenhorn

Posts: 3

posted 3 weeks ago

All feedback by now is great!
I have spesific questions i'll post later when i'll get to it,

I know the typos are emberacing..
(probebly in this post too)
I wrote some of the stuff in a haste and right before posting here,

Strongly agree with Salvin and Jim. Don't commit files that are not part of the build, and use descriptive commit messages.

The biggest issue I have is that you haven't written any class or method documentation. As an interviewer I would be much more interested in how you design classes than how you implement them. Writing good method contracts is an essential skill.

Stephan van Hulst wrote:As an interviewer I would be much more interested in how you design classes than how you implement them. Writing good method contracts is an essential skill.

For an experienced hire, yes, but for an entry-level position, I would be a little more forgiving. Poor design choices would definitely be a red flag even for entry-level candidates but even just a hint of some understanding of basic design principles and clean coding practices would be a definite plus for a junior developer candidate.

When I'm weeding through a pile of resumes to shortlist, it's details like spelling and grammar that are critical to get right. Those get you in the door for the initial conversation. You don't want to get yourself shut out right away for a misspelled word or wrong grammar when there are freely available tools online to help you with that.

For an entry level position, focus on writing clear code, using proper spelling and well-named variables, regardless of whether the code is business logic, test code or otherwise. In this case I would probably focus my time on writing tests rather than documentation. However, it would still make me raise an eyebrow because it clearly shows that documentation isn't on your mind at all.

If you want to apply as an architect, then documentation is EVERYTHING. You can't write unit tests if you don't know what cases to test. You can't write an implementation if you don't know what behavior to implement. All of this behavior is described in class and method contracts. In my book, an interviewee could get away with implementing every method by throwing UnsupportedOperationException if the method documentation was complete and precise. I would still ask them some questions about how they would implement some behavior during the interview though.

If I were you, the first thing I would do to improve your repository is improve your README by explaining how to build and run the application, and explaining what the relationships are between the different modules/packages.

The best way to start with documentation is to use JavaDocs. Many IDEs will even boilerplate JavaDocs when you use their wizards to construct classes and methods.

On no account should you skimp on testing. Testing helps in designing and implementing your code and if you have tests as part of your permanent project, you reduce the cost of ongoing maintenance because no one has to remember how everything should be verified and many trivial bugs introduced by code changes can be caught.

You must be using Windows. It seems like almost every app I use in Linux has spell-checking built in, from my web browser to the Eclipse IDE. Granted, the default dictionary is set to UK, not USA, and these mechanisms have a maddening habit of "correcting" spelling to the wrong word or phrase, but at least there's a good chance I'll see where my wayward fingers have gone wrong. Even if it's right after I clicked the "Submit" button.

When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.

IMHO, unit tests are better than documentation. A big reason is code gets updated a lot more often than the docs, but if you aren't updating your unit tests then You Are Failing (tm). Not to mention, a lot of times an example on how to use a method is better than a description (for an old example see Unix man pages for find and tar). Your unit tests are examples of how to use the method.

As for spelling and grammar, I understand English isn't your native tongue (at least I hope not). In that case I'll cut some slack, but your spelling and grammar are so bad I'd toss the resume after the second paragraph or so. It looks sloppy, and if your introduction is that sloppy I don't want to even think what the code looks like.

Jim Venolia wrote:Not to mention, a lot of times an example on how to use a method is better than a description

It's generally accepted that describing the code in comments is worthless, especially since almost all modern programming languages are fairly self-descriptive (well, except for Perl...)

When I design, I start with a rough sketch (which may be purely mental). I then code dummy methods and write descriptions of what the methods do, which in Java I mostly do in JavaDocs, although I have special conventions for really complex stuff. The important thing is that the comments don't describe what the code is doing (how it's doing it) - as I said, that's usually fairly evident in a language like Java, but rather what the function of the code is. The forest, not the trees. I also like to take a page from basic Calculus and indicate the range and domain of the method, failure cases, and how they are to be handled. This kind of stuff doesn't go out of date as fast, and it's essential since the code exists ultimately to perform the function, not vice versa.

In fact, what I do is a lot like Donald Knuth's concept of Literate Programming. Although in my case, it's the end of a process that began when I discovered the AutoDoc system used by Commodore on their Amiga OS.

You can be extremely creative with JavaDocs. Basically you're producing a website, so you can not only use the standard doc notation, but also HTML (I often define tables and bullet lists in my docs), and in addition, include images. Plus, while many don't realize it, you can define a package-level doc file that will display information about the package as a whole.

And if that isn't enough, you can always customize the AutoDoc system. It's designed to be extendable.

But there's no need to go to extremes. Just documenting the basic purpose, parameter usages and return values is invaluable. And many IDEs can pick them up and use them as pop-up usage hints when you later code method calls.

When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.

Stephan van Hulst wrote:If I were you, the first thing I would do to improve your repository is improve your README by explaining how to build and run the application, and explaining what the relationships are between the different modules/packages.

Yes! Especially if you're going to ask potential employers to look at it. A good README gives your portfolio repo "curb appeal" and will help entice visitors in to take a deeper look around.

Stephan van Hulst wrote:If I were you, the first thing I would do to improve your repository is improve your README by explaining how to build and run the application, and explaining what the relationships are between the different modules/packages.

Yes! Especially if you're going to ask potential employers to look at it. A good README gives your portfolio repo "curb appeal" and will help entice visitors in to take a deeper look around.

Seconded. Since this is github, to be precise, add a README.md to the project root and use markdown language to make the text pretty.

When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.

Where all the women are strong, all the men are good looking and all the tiny ads are above average: