• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Frits Walraven
Bartenders:
  • Carey Brown
  • salvin francis
  • Claude Moore

Is my Github project looks Profssional enough for first job interview?  RSS feed

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
I am a self-tought developer, and applying for jobs as a developer,
since i have no feedback i was wondering if someone wish to share
there expirience and look at this project.

https://github.com/extremeFunk/WakeApp

1) is it accepteble as a portfolio?
2) dose it look profesional enought? (for a first job - as a devoloper)
3) do you have any good/bad remarks or suggestion?

thanxs (and sorry for any typos)
 
Marshal
Posts: 13447
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 20656
122
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, you didn't read the instructions on how to set up a CodeRanch username.

If you can't follow instructions, you're going to find it tough to get hired.
 
Bartender
Posts: 2230
94
Eclipse IDE Google Web Toolkit Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 523
Chrome Linux VI Editor
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What they said, plus when your commit comment is simply "update" that's a huge red flag to me.
 
Ranch Hand
Posts: 380
2
Fedora IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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  
 
Rob Berk
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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,

please shere more insight if you have
 
Saloon Keeper
Posts: 10136
214
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Al Hobbs
Ranch Hand
Posts: 380
2
Fedora IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What do you mean by class or method documentation? Would that be a description of the class above the class and descriptiona above the public methods?
 
Junilu Lacar
Marshal
Posts: 13447
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Rob Berk
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:
The biggest issue I have is that you haven't written any class or method documentation.



This brings me to a dilemma.

Since I assume it would take a substantial amount of time
creating documentation, I have to choose whether I should abandon creating Unit testing
Unfortunately, this project is not well covered.

I spent a lot of time and energy making the best design that I could -
studying S.O.L.I.D and Design patterns,
and from an interview point I can clearly explain it.

Should I choose one over the other? (Unit test vs. Documentation)
or divide my efforts?
 
Stephan van Hulst
Saloon Keeper
Posts: 10136
214
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, as Junilu points out, it kinda depends on what level you're applying for.

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.
 
Tim Holloway
Saloon Keeper
Posts: 20656
122
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.  
 
Jim Venolia
Ranch Hand
Posts: 523
Chrome Linux VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Marshal
Posts: 64172
215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:. . .  Writing good method contracts is an essential skill.

That also tells the user how to use the code; If there isn't any documentation, how will anybody know how to use your code?
 
Tim Holloway
Saloon Keeper
Posts: 20656
122
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Junilu Lacar
Marshal
Posts: 13447
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Tim Holloway
Saloon Keeper
Posts: 20656
122
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

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.
 
Where all the women are strong, all the men are good looking and all the tiny ads are above average:
Create Edit Print & Convert PDF Using Free API with Java
https://coderanch.com/wiki/703735/Create-Convert-PDF-Free-Spire
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!