|
shrughes posted:When interviewing, interviewers don't really want to know "how you think about a problem", they want to know if you can solve problems quickly without screwing poo poo up. If you make a mistake, yeah, that counts against you, because you couldn't get it right the first time. The last thing I want to see is to observe how somebody "thinks" about a problem. Just write down the loving answer and move on, that's the ideal interview. Anything less means you're a flawed, broken problem solver, and then we only want to see more precisely how flawed you are. You're really judged by how quickly you actually solve the problem. Wow you must only deal with really easy problems if no actual process or thought is required to solve them.  Literally Elvis posted:What is the general consensus on business cards for networking as a newbie trying to get in the field? I thought of making some to give to people I meet at local meetups, but I'm not sure if it's pretentious or not, nor what I'm even supposed to put on it. I haven't ordered any yet, but so far all I've thought for a title is "A programmer, sort of". Any advice? I think a simple card with your contact info is totally fine, not to mention handy. Maybe avoid putting a job title on it for now.
|
#
?
Aug 26, 2014 04:33
|
|
|
|
| # ? Apr 26, 2024 22:36 |
|
|
wolffenstein posted:Whiteboards are fine for diagraming and illustrating something, but I've met coders that don't know how to use a computer that's not their own. That's me. I've had interviews where they give me a computer, and I found it really uncomfortable. When I put my hands on the keyboard, a lot of muscle memory takes over. But when it's a machine that I haven't spent an hour configuring, this mostly manifests in typos. I insert random characters when I mean to delete a word, I switch on caps-lock because I'm used to it being remapped to control, I fat-finger tons of keys because I'm not accustomed to the keyboard. And knowing that someone's watching me as I repeatedly misspell "function" or choose the wrong item from auto-completion or litter my code with quote-marks when I mean to type semicolons makes the whole thing awful.
|
|
#
?
Aug 26, 2014 04:52
|
|
|
wolffenstein posted:To me, using a computer over a whiteboard was a two birds, one stone solution. I do similarly for interviews. I take a certain amount of pleasure in doing a post-review "no way in hell" to software engineers that hunt and peck, and when I was interviewing for those positions I always wished someone would just give me a drat keyboard and IDE. baquerd fucked around with this message at 04:59 on Aug 26, 2014 |
|
#
?
Aug 26, 2014 04:56
|
|
|
Mniot posted:That's me. I've had interviews where they give me a computer, and I found it really uncomfortable. When I put my hands on the keyboard, a lot of muscle memory takes over. But when it's a machine that I haven't spent an hour configuring, this mostly manifests in typos. I insert random characters when I mean to delete a word, I switch on caps-lock because I'm used to it being remapped to control, I fat-finger tons of keys because I'm not accustomed to the keyboard. And knowing that someone's watching me as I repeatedly misspell "function" or choose the wrong item from auto-completion or litter my code with quote-marks when I mean to type semicolons makes the whole thing awful. There's customizing your IDE, and making it impossible to pair program with keyboard swapping (a fun, thorough, but realatively slow process). Having a half dozen or less customizations is OK, being crippled by a vanilla install is not.
|
|
#
?
Aug 26, 2014 04:58
|
|
|
Being able to clearly talk about an algorithm using a whiteboard is a pretty important skill.
|
|
#
?
Aug 26, 2014 05:13
|
|
|
baquerd posted:There's customizing your IDE, and making it impossible to pair program with keyboard swapping (a fun, thorough, but realatively slow process). Having a half dozen or less customizations is OK, being crippled by a vanilla install is not. Why wouldn't you optimize for the more common case? If I was spending 5% or more of my coding time on somebody else's equipment it might be worth it to work without customizations. But I might spend 10 minutes in a week touching a coworker's machine, and we'll be doing so much talking that I might type one character every couple seconds at the most. I use an editor with some custom key bindings and plugin scripts, a shell with aliases and customizations, and a keyboard layout with a few key changes. It makes writing code a little nicer and a little faster, and since writing code is most of how I spend my time those customizations pay off enormously. Switching computers or jobs isn't too big a deal: it only takes an hour an change to make myself at home on a new machine. But I'm not going to install all my personal files on an interview machine.
|
|
#
?
Aug 26, 2014 05:23
|
|
|
Mniot posted:Why wouldn't you optimize for the more common case? I suppose it depends on how much your company does pair programming like that. We like to do it as often as possible, because it's perhaps the most fun and least stressful way of coding ever. We don't get to do it as often as we like due to deadlines, but it undeniably produces superior quality code that is already knowledge shared.
|
|
#
?
Aug 26, 2014 05:33
|
|
|
When you're interviewing someone, I think it's important to come at it with some empathy and try to isolate the poo poo that matters from everything else. Some great programmers are nervous typers, or have terrible handwriting, or only ever code in their favorite editor. It's so hard to find competent programmers, let alone great ones, that it's really dumb to throw those people out. Save that for the candidates who can't propose solutions to non-trivial problems, write terrible code, or can't articulate their thought process.
|
|
#
?
Aug 26, 2014 05:40
|
|
|
HondaCivet posted:Wow you must only deal with really easy problems if no actual process or thought is required to solve them. Well no, I'm simply referring to the ideal answer. Almost all people are sub-ideal. But sometimes people can just rattle off a solution they recognized on the spot. And some people can just write out code for the range of difficulty of coding interview questions and get it perfect the first time, on the whiteboard. (Of course, yes, all the problems are really easy, if you're supposed to be able to do two or three of them in an hour.)
|
|
#
?
Aug 26, 2014 06:02
|
|
|
baquerd posted:I take a certain amount of pleasure in doing a post-review "no way in hell" to software engineers that hunt and peck What if they hunt and peck out a correct solution on the first attempt? This is a not a hypothetical question.
|
|
#
?
Aug 26, 2014 08:38
|
|
|
shrughes posted:When interviewing, interviewers don't really want to know "how you think about a problem", they want to know if you can solve problems quickly without screwing poo poo up. You want to know how a candidate "thinks about a problem" so they don't get hung up if they temporarily black out on trivial stuff due to being nervous.
|
|
#
?
Aug 26, 2014 08:43
|
|
|
Mniot posted:That's me. ... And knowing that someone's watching me as I repeatedly misspell "function" or choose the wrong item from auto-completion or litter my code with quote-marks when I mean to type semicolons makes the whole thing awful.
|
|
#
?
Aug 26, 2014 09:04
|
|
|
Skuto posted:You want to know how a candidate "thinks about a problem" so they don't get hung up if they temporarily black out on trivial stuff due to being nervous. This doesn't help you find good candidates at all. If somebody can't solve the problem but you're convinced they're good at thinking about problems, then you've been bamboozled. Instead, you should calibrate your interview questions so that they're actually solvable in the period of time the candidate has to solve the problem, and also so that they have a range of inferior solutions. Otherwise, you're going to say somebody did OK on an interview, when all they really did was follow the forms of pretending to work out the solution in a reasonable way, which plenty of idiots can do. If you're worried that somebody might be bad at interviewing, then use other forms of evaluation too in the process.
|
|
#
?
Aug 26, 2014 09:25
|
|
|
You should be looking for both qualities. The candidate should be able to solve the problem, but they should also demonstrate their working instead of just sitting there thinking about it for 10 minutes and then popping a solution out of thin air. It's frustrating when a candidate doesn't explain how they arrived to a solution (even if it's correct) in any intelligible manner because you have no idea if they actually thought thoroughly about it at all. Kind of like when you don't write your workings down on a maths test. edit: so the solution is pretty much exactly what shrughes said. PIGEOTO fucked around with this message at 15:16 on Aug 26, 2014 |
|
#
?
Aug 26, 2014 15:09
|
|
|
shrughes posted:This doesn't help you find good candidates at all. If somebody can't solve the problem but you're convinced they're good at thinking about problems, then you've been bamboozled. Huh, an interview situation isn't at all like a normal programming situation, and plenty of people have nerve problems. I'm not advocating dragging them through the solution, but if they have some problems getting on their feet in the beginning, a small nudge is often enough to get them going and once they're going, nerves tend to dissipate pretty quickly, unless they're actually are incapable of solving it, at which point I no longer care anyway. But you can't do this if they just sit and stare at the whiteboard/keyboard. Some people also get stuck on "I'd like to use this standard C or C++ function but I'm not 100% I remember the exact argument order etc". There's no need to waste time there, I just play manpage. quote:If you're worried that somebody might be bad at interviewing, then use other forms of evaluation too in the process. You mean like looking at a portfolio? Not everyone has recent public code.
|
|
#
?
Aug 27, 2014 07:42
|
|
|
Skuto posted:You mean like looking at a portfolio? Not everyone has recent public code. Like problems that aren't done while talking live to a person, and other things that aren't "code this on a whiteboard or answer this question while being dynamic-looking."
|
|
#
?
Aug 27, 2014 07:49
|
|
|
Can you elaborate and/or be a bit more specific? I tend to ask some design and technical questions, but those won't redeem someone who failed at the whiteboard, which is why it's important for a candidate not to get stuck/freeze up there.
|
|
#
?
Aug 27, 2014 08:57
|
|
|
I know the common advice in this thread is "never give a salary number, even at gunpoint, until you have an offer", but I have a question about that anyway. Can I write down "I'd be happy to discuss this later" on a form that I'm supposed to fill out before a final set of in-person interviews (which I'm hoping will lead directly to an offer)? It's an internal form for this specific company. They haven't extended me an offer yet, obviously. The form won't submit if I just leave it blank. I'm worried that if I don't name a number they'll think I'm playing games and not serious about the position. I'm also worried that if I name a ridiculously high number, especially as a fresh graduate, they'll think I'm not serious. On the other hand, I do think a significant cost of living increase is justified between the other offer I have on the table (small-town NYS) and one I would get from this company (NYC). And I really want to work in NYC/at this company. (anyway the in-person interviews are tomorrow, wish me luck!)
|
|
#
?
Aug 27, 2014 15:13
|
|
|
"I'd be happy to discuss this later" should be good enough.
|
|
#
?
Aug 27, 2014 15:39
|
|
Skuto posted:You mean like looking at a portfolio? Not everyone has recent public code. God forbid the candidate attempt to bring some samples of the work s/he's purporting to be able to do if s/he can't "code under pressure"
|
|
|
#
?
Aug 27, 2014 15:47
|
|
|
down with slavery posted:God forbid the candidate attempt to bring some samples of the work s/he's purporting to be able to do if s/he can't "code under pressure" Is this common? Never had a candidate offer a code sample and was never asked for one myself either. I *did* certainly see people freeze up at the whiteboard.
|
|
#
?
Aug 27, 2014 17:20
|
|
|
Let's not get into that derail again. If you participate in open source and have a body of code on GitHub or elsewhere, especially as someone fresh out of school, it wouldn't hurt to bring it up in an interview if the code is relevant, of good quality, and demonstrates your capability to interact within a larger team. Although it's not quite addressing the "can this guy work out problems?" question, it does help with the overall picture of a candidate. If you're an "industry veteran" with no public code, it's understood that you can't reasonably be expected to build a portfolio outside of your day job. But then you better be able to talk about your past work confidently and not freeze up during an interview.
|
|
#
?
Aug 27, 2014 17:30
|
|
|
tetracontakaidigon posted:I know the common advice in this thread is "never give a salary number, even at gunpoint, until you have an offer", but I have a question about that anyway. "1"
|
|
#
?
Aug 27, 2014 17:43
|
|
|
Skuto posted:Is this common? Never had a candidate offer a code sample and was never asked for one myself either. I *did* certainly see people freeze up at the whiteboard. I had plenty of candidates volunteer code samples when I didn't even ask for them. When it was code from their current employer... it always made me slightly question their attitude toward data security.
|
|
#
?
Aug 27, 2014 18:18
|
|
|
Skuto posted:
When I first got into coding back when I was like 12, I was all about remembering APIs and poo poo. I took pride in not having to pull out a manual. But that was 20+ years ago before the internet was available to me 24/7 and now I can look up anything in 15 seconds. Nowadays, it's not unusual for me to hit the web for documentation multiple times an hour. Then internet is better at remembering things and I'm better at using that gray matter for other stuff. This worries me a bit for when I go looking for a coding job. When I say "worries", I mean in some theoretical sense, because I don't have any plans to do so in the near future.
|
|
#
?
Aug 27, 2014 19:49
|
|
|
MAX_INT
|
|
#
?
Aug 27, 2014 21:57
|
|
|
Are there any good avenues for Spring/Winter internships? I've browsed through Indeed and Simplyhired, but it seems like most internships are offered for the Summer.
|
|
#
?
Aug 27, 2014 21:59
|
|
|
JuanGoat posted:Are there any good avenues for Spring/Winter internships? I've browsed through Indeed and Simplyhired, but it seems like most internships are offered for the Summer. Have you looked into co-ops? IBM is big onto semester-long co-ops. Dow Science is another. I imagine there are many more.
|
|
#
?
Aug 28, 2014 00:03
|
|
|
JuanGoat posted:Are there any good avenues for Spring/Winter internships? I've browsed through Indeed and Simplyhired, but it seems like most internships are offered for the Summer. Find companies you like, cold e-mail them to see if they offer internships during the times you're available. Smaller companies probably have more lax intern procedures.
|
|
#
?
Aug 28, 2014 00:38
|
|
|
bonds0097 posted:Have you looked into co-ops? IBM is big onto semester-long co-ops. Dow Science is another. I imagine there are many more. Seconding this - one of the interns I worked with this past summer at IBM was there full-time from January to August, and I know they offered some summer interns the opportunity to continue part-time in the fall. I'm not exactly sure what the difference between "intern" and "co-op" is except that a co-op occurs at the same time as classes and an internship doesn't, but even this depends on who you ask. Re: my salary question above, thanks everyone! I ended up succumbing to worries about not putting in a number and entered a range from (more than my other offer) to (more than I expect to get)... I really am not sure they will look at it or care what it says though, since I submitted it less than 24 hours before the interview.
|
|
#
?
Aug 28, 2014 01:59
|
|
|
Just a followup from earlier- the company has given me an offer which I'll most likely accept  It's not for the larger salary I had requested but right at what I was being offered at other places, which was still higher than I thought I would get based on my lack of degree and relatively short (3 years) experience.
|
|
#
?
Aug 28, 2014 18:02
|
|
|
candy for breakfast posted:Just a followup from earlier- the company has given me an offer which I'll most likely accept Is this from the place that didn't ask you to code during the interview?  beware
|
|
#
?
Aug 28, 2014 19:10
|
|
|
Recruiters asking to interview you in person before they submit you to their clients: is that a common thing? I haven't seen it before. Because honestly, gently caress burning a day off for a chance at a chance at a job.
|
|
#
?
Aug 28, 2014 22:06
|
|
|
It can happen. I remember a recruiter getting mad at me for suggesting a Skype call when I didn't want to drive 2+ hours from Sacramento to the Bay Area for such an interview. But yeah gently caress those recruiters.
|
|
#
?
Aug 28, 2014 22:24
|
|
|
null gallagher posted:Recruiters asking to interview you in person before they submit you to their clients: is that a common thing? I haven't seen it before. Yeah, it's fairly common. The recruiters want to screen out neckbeards and people who fall apart in interviews.
|
|
#
?
Aug 28, 2014 22:26
|
|
|
I've had it happen here and there. It is predictably a waste of time. The thing to remember is they will still want to submit you because they're interested making a hire happen. So if you're good enough to talk to them, you're good enough to be presented to the client. Make scheduling / logistics excuses and suggest frequently that you can do a phone interview instead. It's kind of understandable that they want to pre-pre-screen you but the most they can really get out of it is "this person is crazy, nevermind!". Which, as someone who interviews candidates every week mainly coming from recruiters, it's nice when they do this to filter out people who would have been a waste of everyone's time. But they don't need more than a 15 minute phone call to talk to you about your career history and what you're looking for, etc, to sort of get you past the smell test.
|
|
#
?
Aug 28, 2014 22:40
|
|
|
I had one who insisted that I wear a suit, told him where to go.
|
|
#
?
Aug 28, 2014 23:59
|
|
|
So I had a job interview after many years. Motherfuck is coding on paper/blackboard more difficult than it looks. Struggled quite a bit with some fairly simple SQL and data structures. Aced some pretty tricky theoretical questions though. Don't know how this looks, but I think hopeful.  Made the mistake of telling a number though. The HR guy immediately went like "aha". It's known to be a very well paying company... I mean the number was quite a bit higher than what I was getting previously, but it still irks me a bit. 
|
|
#
?
Sep 1, 2014 19:42
|
|
|
If you screwed up writing code but aced the theory then you are probably going to be dismissed as someone with not enough practical experience. Hope this helps.
|
|
#
?
Sep 2, 2014 00:59
|
|
|
|
| # ? Apr 26, 2024 22:36 |
|
|
pigdog posted:Made the mistake of telling a number though. The HR guy immediately went like Yet another reason it's worthwhile to try and get multiple offers at once. If you mess up negotiating with one place, you don't get anchored to a bad number so easily.
|
|
#
?
Sep 2, 2014 01:21
|
|