|
Cicero posted:- Make sure you understand the design specs completely before you start to code. If anything is ambiguous, ask the interviewer. For example, if the code is being used internally, you may be able to assume that the parameters coming in are valid, or at least aren't null or something like that, whereas if it's an externally-facing API, you almost certainly wouldn't be able to assume that and would have to check the parameters at the start of a function to make sure they aren't broken. Don't feel awkward about really being anal and getting all the details from the interviewer, and not just specs, but criteria for scoring your answers, too. If it's coding on the board question, some folks won't care how sloppy your syntax is, while others will want to be able to type what you write and run the program. Some don't care what you name your methods and variables, and others will expect you to explain them. If you don't ask what they want, you might to a good job up to your own standards, but not theirs. I once spent more than 10 minutes coding up a balanced binary tree only to have the guy say, "ok, but we can just assume we have that structure available to us." Another tip I thought of -- if you're being interviewed by multiple people, even if they're from the same team, you should try to ask each person the same set of questions when they ask, "do you have any questions for me?" The natural tendency is to get all that info from the first person and to not bother with later interviewers. But doing that might make you look a bit like a drone and not that interested or curious about the job/team. When the the interviewers convene to talk about you, everyone but the first guy might only be able to comment on your technical skills, as opposed to what kind of person you are and what you're looking for. If you want to mix it up, keep a list of your questions and only ask each interviewer some of the questions. edited for clarity. kimbo305 fucked around with this message at 06:34 on Dec 28, 2010 |
#
¿
Dec 25, 2010 02:27
|
|
|
|
| # ¿ Apr 18, 2024 18:41 |
|
|
Cicero posted:Ok, I guess. Generally when people are talking about the Big-O running time they mean the lowest valid running time. The lowest worst-case running time, right? In my experience, most run-time analysis is done as a spot check, like after you devise an algorithm, the interviewer will ask as a quick check what the running time is. It should be obvious after you just implemented it. For entry level jobs, I feel like programmers and engineers (ones that I'd want to hire, anyway) will rarely struggle to find the obvious right choices for data structures or run times. Hmm, I guess what I mean is, I think I'd expect most people to use hashmaps over lists where appropriate. That's not the part of programming that presents a challenge most of the time. That said, if someone asks you the run time of the level of program that comes up in an interview, you should be able to do it fairly naturally. Which should come with enough programming under your belt. Granted that's maybe a catch 22 when you're going for your first programming job. The vast majority of interview questions will involve loops, search, sorting, recursion, and dynamic programming. I'd say you can quickly build an intuitive sense of run times for the first 4, and from there it should be easy to arrive at the correct run time for algorithms that are composites of those.
|
|
#
¿
Jan 1, 2011 07:09
|
|
|
Jick Magger posted:If it's really that easy, why did it take at least a week for my teach to explain it to us, hmm Mr. smarty pants? Also, I don't think the run-time stuff is that rigorous, but they sure try to make it seem that way in class.
|
|
#
¿
Jan 2, 2011 21:26
|
|
|
shrughes posted:It's rigorous, assuming you do it rigorously. What parts do you find particularly hand-wavey? The continuous domain stuff is certainly rigorous wrt to limits approaching x = a or x = infinity, but applying big-O notation to discrete domains seems almost naively simple and devoid of rigor (it could still be rigorous; I don't have a math major's eyes to really see). I should look at how it was done in CLRS instead of the wiki page, though. From an interview or empirical perspective, the big-O run-time will often also be the big-Theta run-time, which is the natural (though not always the safest) way to think about performance. Like with the example above, that algorithm might be technically O(n^3), but it's the Theta(n^2) behavior that jumps out at me.
|
|
#
¿
Jan 4, 2011 21:28
|
|
|
Bob Morales posted:
Is it a real website out in the wild, that they want you to test from home, or will they bring you in and give you a give machine set up to work with the site? I don't think language/framework is that important for the first level of testing, as they're probably looking for experience with diagnosis techniques (like using Firebug) and familiarity with the different browser quirks (may IE6 disappear from this earth). e: also, how much are you expecting to do development through this job? The development opportunity is frequently waved as a bait to people who are looking to transition from QA to development. kimbo305 fucked around with this message at 09:39 on Jan 7, 2011 |
|
#
¿
Jan 7, 2011 06:07
|
|
|
csammis posted:Recruiters for a certain Kansas-based GPS company came to a career fair at my university, saw my GPA, and literally crumpled up my resume in front of me and threw it into a trash can. To be honest, that would be kind of cool to see happen. I would hesitate with a candidate with a below 3.0 total GPA, but if he demonstrated competency and real experience during his interview, I wouldn't have any issues hiring him.
|
|
#
¿
Feb 10, 2011 18:28
|
|
|
Hmm, your interviewer should have called those things out to you either as he was administering the question (this is a way to gauge if you're forgetful or outright ignorant), or after the question was done. Don't worry about it, you'll get used to as you do more.
|
|
#
¿
Feb 17, 2011 21:38
|
|
|
Bag of Carpets posted:Basically, I want to move into the private sector and find a job developing web applications. I know that having only PHP, SQL and Javascript on my resume wouldn't look the best, so what would you recommend I learn next? (I was thinking Java or Ruby on Rails) Is there any books you would recommend to learn about common algorithms and data structures? Any tips for marketing myself as I do not have a CS degree? The Java analog to RoR is J2EE, which is really bulky in typical Java fashion. I wouldn't recommend you do that if only because the cross section of companies willing to develop a J2EE based website tends to be bigger and stodgier than the company that'd be willing ot use RoR. You should assess what you did for your supervisor and figure out what major holes there were there, compared to what you'd do in a webapp developer position. From there, just expand into the hole areas until you have reasonable proficiency. My first job was doing webapps, and when I started, I certainly didn't have a complete web site in my portfolio. If you're willing to do an entry position, there should be jobs out there.
|
|
#
¿
Mar 16, 2011 18:34
|
|
|
Parantumaton posted:The hell it is, Grails or Play Framework are comparable to RoR, J2EE is the Brutalizer option of doing web apps which has its places but certainly not in rapid webapp development. Nice, I see Grails has some real users now. Still, 95% of Java shops doing webapps will probably doing J2EE (or worse, their own homebrew frameworks). And I certainly never claimed J2EE was comparable to Rails, merely that if you did Java web development, that that's what you'd expect to see work in.
|
|
#
¿
Mar 16, 2011 20:23
|
|
|
Bag of Carpets posted:Thanks for the info. I've done a bit more research and have found a lot of jobs (at least in Canada) ask for Java / J2EE rather than RoR... Although RoR is less bulky for developing web apps, perhaps having a base in J2EE is a good (transferable?) skillset to have for an entry level position? Am I missing the mark with this idea? It depends on where you'll be working in their J2EE codestack. For maximum job skill portability, you'd want to stay close to HTML rendering and XMLHttpRequest handling stuff. Working with JSPs and JSP Tags is reasonable, because the concepts translate well to other frameworks. J2EE doesn't offer a great native object storage/representation format. If you're not doing Groovy, then hope for an intermediate framework like iBatis or Spring to help you not have to muck about with Beans. Don't worry about all those names; just know that it'll take longer to get comfortable dealing with data server-side because of the nature of Java. There's a lot of nuance (aka tedium) to maintaining and deploying a real J2EE webapp. Avoiding that would be good if you're not interested in sticking with it. To answer your question, doing a J2EE job for a couple years wouldn't be amazing prep for an mid-/senior-level RoR position. But in an interview, you would probably still be able to demonstrate good client-side competency as well as familiarity with the whole stack. The nice thing about RoR is that various things tend to be easier/slicker, so training you on the stuff you don't know is also easier. I'd have much more comfort hiring a junior (and not a robot) J2EE dev to do RoR than vice versa, simply because the amount of orientation to get to the same competency is slanted in Rails' favor. One final note -- when checking out J2EE jobs, I would pay attention to how their client-side stuff is designed. Using J2EE can be a sign that the company isn't that good with client-side bells and whistles. I'm probably generalizing, but I wouldn't want you to get into a job where the web UI is horribly outdated and boring to work on.
|
|
#
¿
Mar 17, 2011 17:27
|
|
|
Ithaqua posted:Of course, he also took 30 minutes to get a non-working implementation of FizzBuzz to the point where it would even compile. I've seen so many people fail to code FizzBuzz correctly that it almost makes me wonder if it's a valid test. What do you guys think? The more I interview people, the more frustrated I get with people not asking questions about what I want -- requirements and expectations are key to both artificial interview questions and real software engineering! Anyways, after I make sure they understand what I want, they can usually bang it out. The one thing I stress before they start is that I want "Fizz" and "Buzz" to be on the same line when they happen together. Lots of people will oversimplify and print them on separate lines, which can be more elegant, but not what I asked for. If they miss that part, I ask them to correct it, which can take some work depending on what kind of print functions they elected to use. Some people decide to print FizzBuzz via some kind of fall-through. I'm totally ok with that in such a small, contained problem. If they do it that way, I follow up and ask them to change 15 to 17, and try to tease out why their implementation makes that a bigger change. So I guess I do try to tack on a few software engineering talking points in there. Though I only do that if they have an easy time of it. I've definitely seen people struggle through it, and it's hard to administer the rest of the interview  .
|
|
#
¿
May 11, 2011 06:34
|
|
|
I've heard the argument that people who love to code will have code project hobbies on the side, and that is something you should look for. I don't know how widely that view is held by recruiting people or programmers in general, but I don't agree with it. I like to code, I love to solve problems, but I put almost all of that effort into my job. Sometimes I work weekends because I think of a possibly better way to code something and I can't let it sit. But at the same time, I'd wish I wasn't completely consumed by it. I wouldn't fault anyone who didn't have outside projects, as long as they had demonstrable aptitude for coding and getting things done.
|
|
#
¿
May 18, 2011 00:05
|
|
|
If you've been talking to a recruiter/contact for the job, just ask them what you should wear to the interview.
|
|
#
¿
May 19, 2011 03:48
|
|
|
shrike82 posted:2) Then, there's a video conference interview. This is meant to grill the candidate based on what they put on their resume. It's odd how often people lie about their technical expertise on their CVs and expect not to be questioned about it. How is this set up? Do the candidates have to provide their own camera?
|
|
#
¿
May 19, 2011 18:50
|
|
|
I'm actually gonna interview someone today that has no formal programming training and thus can't claim any particular language experience. He's done some projects that, assuming they work, show that he can program and figure out a language as needed, but we'll see how this interview goes. I would say for at least a large portion of entry level jobs, a fast learnercould pick up what you needed to know during a training period. The question is how to identify that ability during the interview process.
|
|
#
¿
May 23, 2011 12:29
|
|
|
Hibame posted:Does anyone have any advice? If you can stomach some vague answers and flat out BS, ask them what they thought your deficiencies were. It might not all be useful, but you can try.
|
|
#
¿
Jun 9, 2011 17:35
|
|
|
Cryolite posted:though I took a few community college courses for a semester while I was turning around after finishing a degree in an unrelated field. Depending on the quality of community colleges in your area, that might be a good option. If you're committed and smart, the bang/buck of CC classes could be very worth it. But yeah, 1999 is probably Java 1.2, which is definitely out of date. Generics have made Java a different (and I would say much better) beast.
|
|
#
¿
Jun 11, 2011 20:39
|
|
|
Mike1o1 posted:Any suggestions on what somebody should expect to encounter on their first programming job? This is a C# 3.5 shop, creating database analysis tools for all the major database providers (Oracle, MySQL, MS SQL, etc.). Ask them what hardware/software/environment they expect you to work on. Some shops are really strict; others will get you whatever you ask for. Good luck and don't panic. It'll come together pretty quickly.
|
|
#
¿
Jun 21, 2011 01:00
|
|
|
Seems like if a company really wanted to see someone's low to mid-level programming skills, they would just ask for a TopCoder score.
|
|
#
¿
Jun 21, 2011 05:01
|
|
|
|
| # ¿ Apr 18, 2024 18:41 |
|
|
Dire Penguin posted:I've just graduated with a CS degree from a decent school and started my job search. There's plenty of advice for how to handle general interviews and how to spruce up my resume, but I'm really naive when it comes to things I might need to look out for. For example, how do I handle recruiters? Are there certain companies I should avoid offers from? What are warning signs that a company is crappy or exploitative? Re: recruiters -- I've never been able to tell a really snaky one from an average one. At most they ask you to self assess skills on a 1-5 scale and pass those figures on to the companies they're recruiting for. The best you can do to try to gauge the quality of the company is to poke around the web for their presence. Some small companies won't have a great website but will make up for it with a reasonable (if maybe niche) business model. You will probably tell the most from an onsite interview, though, so just be on the lookout when it gets to that stage.
|
|
#
¿
Jul 2, 2011 12:54
|
|