Here’s a list of common topics I’ve encountered on technical interviews pertaining to Java:
- multi-threading (locks)
- pass by reference/pass by value/pass by pointer
- data structures/algorithms – eg: return top N duplicate results from large data set
- set vs list
- object vs non-object data types
- internationalization – eg: utf-8 vs utf-16
It is a good idea to be prepared to discuss as many of these as you have experience with.
Some comic relief about interviewing from “The Norm”:
Today at work E. was doing more interviews…and then sometime thereafter–I’m not sure exactly what prompted it–but shortly thereafter he bet F. he couldn’t solve this interview question correctly in 15 minutes. And by correct, I don’t mean, works for most cases, but doesn’t fall apart on certain rare edge cases. Unlike a lot of interview questions generally speaking, this one is actually quite relevant to the type of stuff I do at work all day, and conceptually, its pretty simple–kind of deceptively simple. So right after F. turns in his answer, someone else walks by and asks what we’re all talking about and pretty soon half of everyone sitting nearby is discussing the question “oh that’s easy” one person says hearing the problem, course, that person not having actually tried to write out the correct solution completely…It was kind of entertaining
Always always have a copy of your resume in front of you during a phone interview. When they suddenly surprise you with a rather expected first question like “tell me about what you did at your last job” and you momentarily you blank in panic, you can stop and take a breath while you glance at your resume and remember the “better” words you carefully chose about how to articulate it.
Always have questions prepared to ask the interviewer. They will ALWAYS ask you if you have questions. And from everything I’ve read and heard, “no I don’t have questions” is never a good answer. You need questions to show them you are evaluating the fit of the job/company to your needs. I’ve found useful questions for initial/screening interviews are usually along the lines of “what would I be actually be doing at this job”. eg: Continue reading Things I’ve learned about Interviews…
Assorted job seeking advice from SDForum JavaSig attendees:
- At your experience level (5 years), you should start to “sound professional”, the more you can articulate yourself professionally, the more hire-able you will be.
- Use job agents on major job boards to track statistics on major programming languages and libraries to identify which ones are most in demand. The libraries worth the time or money to learn would be the ones that are increasing in demand
- Take a class on networking to gain practice and skill at how to do it…and remember its about relationships, not passing out business cards
- Be able to confidently pitch what you’ve done…the companies are not looking to hire the team you were part of, but you specifically
- In your elevator pitch, make sure you’re sharing the business results of what you’ve done, not just that you’re a programmer (what you do)
- You can’t just sell that you can program, that’s kind of like saying you can type, kind of necessary, but not the selling point. The selling point is higher level, the other stages of the process…Architecting level. how did you make sure your code was bug-free? What goals were you programming for? (eg: performance, ease of programming, etc). How did what you did help the company make money, etc…
- Be BOLD and be PREPARED (information and tips helps with the prepared part, but you still have to do the bold part yourself, things like contacting people and showing up at events like these and networking, etc)
- Networking opportunities: SWE, TBP, SD Forum Women’s group, IEEE Women’s Group, Well-known relatives, alumni association, etc. SDForum tends to get a lot of the engineers with an Entrepreneurial spirit
- Take advantage of UC Alumni resources–check out what your UC Alumni Association membership perks are that you can use at local UCs (Berkeley, SC, but esp. Berkeley)
- Seriously, you need to know people inside the companies you want to work for, that’s how most people get hired
- Establish credibility. Later on this might look like being a presenter at a forum like this or publishing books (what some of the others do to lend credibility to their consulting work), now could get involved in the steering committee for a group like this that finds presenters and coordinates the catering and stuff
- Stuck in an unemployment rut? One way to gain specific relevant experience in the software industry is to volunteer for a startup (like an internship). Why? Two reasons: (1) Gain experience at a specific technology they work with (2) to get a reference. Most startups don’t have a lot of money so unpaid interns = something they’ll probably be willing to do.
- Talk to former coworkers to get help with how to articulate the business results of what your previous project was doing
- Been on board asinking ship? Be prepared to overcome the “cootie factor” (the project got cancelled/downsized/etc? it must have cooties)–be able to articulate why your project mattered or would have made a business impact