|
The amount of awful poo poo I see in my codebase (on older apps that serve a majority of our business and hasn't been fixed yet) is frightening but I think even these scoundrels could manage something like that.
|
#
?
Mar 2, 2016 22:53
|
|
|
|
| # ? Apr 19, 2024 16:56 |
|
|
mrmcd posted:In the Google interview prep presentation I went to, the presenter mentioned that they see a lot of people who have spent their entire careers doing something along the lines of "take the data out of the database and put it on the UI" and can't manage to do literally anything else when asked. Were those candidates worse programmers or generally stupider than the average qualified front-end dev? I'm a front-end / data visualization guy and I might want to work at Google some day.
|
|
#
?
Mar 2, 2016 22:55
|
|
|
Some of that stuff can catch you off guard. I tripped up on a beginner question about loops in the interview I took for the job I have now. I spent all my times prepping for the more difficult stuff because those were the questions I was expecting with my experience and they ended up asking none. When some of the beginner questions came around I had to think on it for a second because a lot of that stuff I rarely use. It's all sort of academic unless the work you'd be doing specifically uses. It's actually kind of annoying the number of simple things I don't use in day to day work that I have to keep in my head during an interview and how that list seems to grow. I don't know I'm rambling... Just thinking about interviewing some more...
|
|
#
?
Mar 2, 2016 22:59
|
|
|
moctopus posted:Some of that stuff can catch you off guard. I tripped up on a beginner question about loops in the interview I took for the job I have now. I found that the best answer in that kind of case is something along the lines of, "To be honest, I don't use that feature regularly enough to have the implementation details memorized, however here are the important parts about how to use it and when to use it and blah blah blah. I can just google the syntax if I have to use it." I used that a couple of times when interviewing recently and it was well taken - got an offer at each place where I had to punt like that. It makes it easier than having to memorize obscure poo poo. Of course, I also did write some other code and do some successful debugging in addition to having to punt, which probably helped them feel comfortable I knew what I was talking about and actually could write code... metztli fucked around with this message at 23:49 on Mar 2, 2016 |
|
#
?
Mar 2, 2016 23:45
|
|
|
I once interviewed a guy for a systems engineering position whose answer to algorithm questions was "I would use Perl." How would you use Perl? What Perl would you use? "I would use Perl."
|
|
#
?
Mar 2, 2016 23:55
|
|
|
On the other hand I've seen people with what you might consider to be a substantial project on Github end up bombing technical interviews too. To be fair something like "made a package downloader" or "made a kernel" might just be glorified "take data out of the database" skills with a different knowledge set. On the other hand these might be people that are perfectly capable of thinking precisely and they're generally useful for a large swath of development, but some other mental deficiency -- either from being bad at thinking on the spot, or a general lack of problem solving creativity -- prevents them from doing well at interviews.
|
|
#
?
Mar 2, 2016 23:59
|
|
|
sarehu posted:On the other hand these might be people that are perfectly capable of thinking precisely and they're generally useful for a large swath of development, but some other mental deficiency -- either from being bad at thinking on the spot, or a general lack of problem solving creativity -- prevents them from doing well at interviews. Interviewing poorly is definitely a potential problem, much like testing poorly can be a problem for some students in school. It's a high-stress environment and requires interpersonal skills that some people simply don't train very often. The converse of course is the person who interviews brilliantly but is crap at actually getting poo poo done, which is why we have all these technical problems in the first place.
|
|
#
?
Mar 3, 2016 00:23
|
|
|
Vulture Culture posted:I once interviewed a guy for a systems engineering position whose answer to algorithm questions was "I would use Perl." How would you use Perl? What Perl would you use? "I would use Perl." Interviewing a dude and asked him to talk about what he considers important factors in "quality code." "Code that is elegant." "Define 'elegant.'" "You know. It is elegant. It has the properties of elegance." "Still not getting it. Can you enumerate those properties?" "No. Look it up." "Okay, any other important factors?" "It has to be good." "Right - what do you mean by good?" "Really? Look it up!" He was fun.
|
|
#
?
Mar 3, 2016 01:06
|
|
|
Vulture Culture posted:I once interviewed a guy for a systems engineering position whose answer to algorithm questions was "I would use Perl." How would you use Perl? What Perl would you use? "I would use Perl." One of my former coworkers interviewed a candidate who, when asked about the complexity of a fairly simple algorithm, told him that it was complex because it had a lot of loops.
|
|
#
?
Mar 3, 2016 01:34
|
|
|
ultrafilter posted:One of my former coworkers interviewed a candidate who, when asked about the complexity of a fairly simple algorithm, told him that it was complex because it had a lot of loops. I once interviewed for a position and answered that an algorithm I wrote ran in amortized constant time with a worst case linear time. I then had to spend 20 minutes explaining amortization to the interviewer because they were arguing about it not being constant time. I didn't receive a follow-on interview. I had another interview where the CTO of a startup asked me what the difference between a class and a struct was in C++. I answered his trick question correctly (essentially none; default private vs default public), but I think he was under the misconception that all structs were POD types. I didn't get an offer. Related to the complaints of unqualified applicants, how do these people get into the position of hiring candidates? Who would work for them?
|
|
#
?
Mar 3, 2016 02:08
|
|
|
leper khan posted:Related to the complaints of unqualified applicants, how do these people get into the position of hiring candidates? Who would work for them?
|
|
#
?
Mar 3, 2016 02:24
|
|
|
Analytic Engine posted:Were those candidates worse programmers or generally stupider than the average qualified front-end dev? I'm a front-end / data visualization guy and I might want to work at Google some day. Google's interviews are much more focused on general aptitude at solving somewhat open ended problems with a focus on demonstrating that you can: - Break a problem down and identify what aspects of it are similar to other well known comp sci problems. - Analyze what you have to do to solve the problem and come up with a workable algorithm. - Explain your reasoning behind your solution, proactively identify pitfalls, and intelligently discuss trade-offs when considering other possible solutions. - Actually implement your solution in code on a white board. This doesn't mean they are going to go ding you for every missed semi-colon, but it shouldn't be pseudo code and complete enough to show you can implement your solution. You can use whatever language you want though. - Discuss the algorithmic complexity of your solution, how well it scales, possible optimizations and how it will break down when taken to extremes ("ok now I want to do this on an array that's 10 billion values long and spans multiple machines"). This is repeated ~ 5 x 45 minute blocks, with different problems and different engineers each time. The problems are varied to have a different focus on coding/implementation, algorithmic analysis, and systems design. In each session I filled a wall sized whiteboard with diagrams and code, and each person took photos of it with their phones after to review when they wrote their interview reports. No one once ever asked me (or seemed to really care) about what frameworks I knew or how much language feature trivia I could recite. It was, however, very heavy on showing mastery of CS fundamentals. The "take the data out of the database, put it in the UI" comment I imagine is more about how there are lots and lots of developers who can get by doing just very rote stuff or follow a decently well spec'ed out ticket/user story, but if you give them something that's fairly open ended and non-obvious, they really struggle to analyze it and engineer a solution. I will say it was really refreshing how open and straight forward they are about their interviewing process. They send you lots of information about each step of the process and what to expect They have free coaching sessions where they present on how they run their interviews and then run through a sample problem with a volunteer. The presenter even told us "you can go on glassdoor or whatever and find lots of people who shared our problems even though we asked them not to. We ban those problems once we find them out on the internet, so if I'm doing my job well it won't be those specific problems, but it's good practice for the kinds of things you'll encounter in the interview. Also if one slips through and you have seen it, then just write a perfect complete solution right away without any discussion, we will probably then move on to the hardest problem we can think of as a backup. That's because either you're a genius or trying to pretend like you are." It's much more focused on making sure you have opportunities to prepare and show your abilities as an engineer than playing keyword bingo or "guess the secret solution to my pet problem". On the other hand, the whole process, end-to-end, takes for loving everrrrrr.
|
|
#
?
Mar 3, 2016 02:55
|
|
|
Ah, to work at a place with real challenges. Hopefully my next gig will be like that. I'm tired of making small changes to a mostly built (albeit lovely) system.
|
|
#
?
Mar 3, 2016 03:55
|
|
|
All this interview chat + my nightly reading of Cracking the Coding Interview is really making me nervous because I keep discovering stuff that is "easy comp-sci degree stuff" that I absolutely do not know and have never even heard of in some cases (e.g. AVL trees) and I've got a software engineering interview on the 9th. Hoo boy!
|
|
#
?
Mar 3, 2016 04:44
|
|
|
Urit posted:All this interview chat + my nightly reading of Cracking the Coding Interview is really making me nervous because I keep discovering stuff that is "easy comp-sci degree stuff" that I absolutely do not know and have never even heard of in some cases (e.g. AVL trees) and I've got a software engineering interview on the 9th. Hoo boy! We had AVL trees and red-black trees covered in my data structures textbook. I ended implementing red-black for a binary tree assignment, but at no time in my academic or professional career have I ever actually needed to write any kind of balanced tree. In short: don't sweat it. If you want practice playing with data structures and algorithms, Project Euler and the ACM/ICPC problems from past years can be fun.
|
|
#
?
Mar 3, 2016 05:03
|
|
|
Vulture Culture posted:I've heard of precisely one person I know being asked to actually implement some kind of balanced binary tree in an interview. It's one of those algorithms that's really useful to know, because people should understand the performance characteristics of different data structures and why they have those performance characteristics, but I'd still consider that one of those "fiddly bits" questions that I'd never ask. A good focus area is general techniques, making sure you're OK with things like dynamic programming and graph problems and have some baseline comfort at being able to spot when you can (and can't!) use certain techniques.
|
|
#
?
Mar 3, 2016 05:06
|
|
|
The actual algorithm for red-black trees is actually somewhat complicated too. For example, here's the actual implementation of the re-balancing part from the Java collections API:code:
|
|
#
?
Mar 3, 2016 05:20
|
|
|
mrmcd posted:core data structures like binary trees, hashmaps, queues, stacks, lists, what kind of problems they are good for solving and the complexity and runtime trade-offs between different choices are all things that you should expect. I got a recursion problem or two at most interviews as well, in addition to bullshit OOP (which is laughable because my company is a shitheap of poorly designed code) and yeah that was basically my first job's interview process for each place in a nutshell. Those topics are cake for me at this point, I'm not even rusty. I haven't touch anything graph related since school though so I'm likely super deficient there. Dynamic programming as well.
|
|
#
?
Mar 3, 2016 05:26
|
|
|
Good Will Hrunting posted:I got a recursion problem or two at most interviews as well, in addition to bullshit OOP (which is laughable because my company is a shitheap of poorly designed code) and yeah that was basically my first job's interview process for each place in a nutshell. Those topics are cake for me at this point, I'm not even rusty. I haven't touch anything graph related since school though so I'm likely super deficient there. Dynamic programming as well. Your best way to practice those is honestly to grab a good algorithms textbook and just picking random questions out of them. I could also type up the dynamic programming mock interview question I liked to give my algorithms students, but 
|
|
#
?
Mar 3, 2016 05:34
|
|
|
I recognize the difference between "basic concept that probably will be asked about in an interview that I might be asked to implement or use" and "complicated memorization thing that probably won't be asked to implement" but it's more the fact that I keep finding extra stuff to learn (even if I don't actually memorize implementation) that makes me nervous. Oh well, I can only do the best I can and try to learn what I can in the meantime.
|
|
#
?
Mar 3, 2016 05:35
|
|
|
Urit posted:I recognize the difference between "basic concept that probably will be asked about in an interview that I might be asked to implement or use" and "complicated memorization thing that probably won't be asked to implement" but it's more the fact that I keep finding extra stuff to learn (even if I don't actually memorize implementation) that makes me nervous. Oh well, I can only do the best I can and try to learn what I can in the meantime. Try not to worry too much during the interviews themselves.
|
|
#
?
Mar 3, 2016 05:48
|
|
|
i know a guy that was asked to implement paxos (from memory) in an interview. he had to sneak a peek at his phone to remember what the modulo operator was in the language he was using
|
|
#
?
Mar 3, 2016 07:28
|
|
|
That man was Ronald Reagan
|
|
#
?
Mar 3, 2016 15:12
|
|
|
the talent deficit posted:i know a guy that was asked to implement paxos (from memory) in an interview. he had to sneak a peek at his phone to remember what the modulo operator was in the language he was using I don't know much about paxos details, but isn't it notoriously complicated and hard to understand?
|
|
#
?
Mar 3, 2016 16:31
|
|
|
Steve French posted:I don't know much about paxos details, but isn't it notoriously complicated and hard to understand? Well, the response paper for Raft is titled: "In Search of an Understandable Consensus Algorithm" so... yes?
|
|
#
?
Mar 3, 2016 16:38
|
|
|
the talent deficit posted:he had to sneak a peek at his phone to remember what the modulo operator was in the language he was using
|
|
#
?
Mar 3, 2016 17:59
|
|
|
I'm considering that the interview might not have been fair even if the interviewee's name was Leslie Lamport. Because it'd take all day to actually write it correctly on a whiteboard in some form of actual code.
|
|
#
?
Mar 6, 2016 05:20
|
|
|
Urit posted:All this interview chat + my nightly reading of Cracking the Coding Interview is really making me nervous because I keep discovering stuff that is "easy comp-sci degree stuff" that I absolutely do not know and have never even heard of in some cases (e.g. AVL trees) and I've got a software engineering interview on the 9th. Hoo boy! For those who are aware of the out-of-balance problem, I would expect them to know that self-balancing BSTs exist and, bonus points if they can recall the name of one. I don't expect (or care) about the details of a particular self-balancing tree's implementation, other than a general description that "self-balancing trees redistribute existing items upon insertion of new items" or something like that. While BSTs are a popular interview topic, I don't know if self-balancing ones really are. I recall learning about AVL and Red-Black trees in our undergraduate data structures course, but I've never had to implement one in my professional career and can't think of a reason I'd want to instead of using an existing library. If I did have to implement one professionally I wouldn't work off an undergraduate text either, but would look at the implementations used in popular libraries (e.g., Java Collections) and try to understand the motivations for the selection of the specific implementation they use, and select an implementation appropriate for the criteria that's forcing me to implement one in the first place. To echo what some of the other have said earlier, interviews for "recent graduate" entry-junior positions tend to concentrate on reasoning and knowledge of CS fundamentals simply because the applicants do not have enough differentiating experience otherwise--usually at a career fair we'll get a stack of resumes from students that are identical except for name and address. If you do have experience, whether applying for an experienced-junior or senior position, or even if you're a recent graduate with hobby projects, I'm always interested in hearing about your experiences first. Sure, you have to be technically proficient and that will be tested in some form, but I'm really far more interested in working with your strengths to see where/whether it's a good fit for the both of us, than I am interested in grading your expertise in undergraduate minutiae. ExcessBLarg! fucked around with this message at 04:28 on Mar 7, 2016 |
|
#
?
Mar 7, 2016 04:26
|
|
|
A potential new client asked me to submit to: - A background check (including fingerprinting by the local police department) - A credit check - An NDA Background check and NDA, fine. I've done both of those before. I've never heard of being fingerprinted and having a credit check run as part of becoming an approved contractor before, though. They're a financial institution, but I've worked with plenty of those before without having to go through that. My gut instinct is to say "no" to both of those as they seem a tad excessive. Thoughts?
|
|
#
?
Mar 8, 2016 02:42
|
|
|
I worked in lockbox for a bank before and had to do 7 years of living and working history with no breaks and a regular/cursive writing submission. Background check, NDA, all that. So I wouldn't bat an eye if it were a financial institution.
|
|
#
?
Mar 8, 2016 02:50
|
|
|
Ithaqua posted:A potential new client asked me to submit to: Had fingerprinting before, also for a financial place, but no credit check that seems excessive especially since I thought some financial background was included in a "background check"? Standard DoD thing includes questions about bankruptcy, gambling losses etc.
|
|
#
?
Mar 8, 2016 02:53
|
|
|
Ithaqua posted:A potential new client asked me to submit to: I've done both for a couple of gigs (2x when doing work for the DoJ at jailsl, not as a developer, and once just recently for my job working at an organization that works with stock market indexes) - I personally didn't give a poo poo because in all cases the work was interesting and the opportunity was likely to open doors down the road. And in all cases they did need to make sure I wasn't remotely a risk or likely to be amenable to bribery or blackmail. Really depends on your reason for saying no, tho.
|
|
#
?
Mar 8, 2016 02:56
|
|
|
Ithaqua posted:A potential new client asked me to submit to:
|
|
#
?
Mar 8, 2016 03:00
|
|
|
I think fingerprinting is fairly standard for SEC/FINRA regulated companies. Supposedly it's less about them thinking you'll leave prints on all the sacks of cash you steal or whatever but making you're not on some list of banned criminals or something. Then again I don't think fingerprints actually work like that so who knows. Not uncommon for certain industries though. 
|
|
#
?
Mar 8, 2016 03:14
|
|
|
Yeah, it's pretty standard, on Wall St. anyway. I went though this back in 2000 so it's nothing new.
|
|
#
?
Mar 8, 2016 08:55
|
|
|
I went through the same ordeal working for a FINRA regulated finance company in 2012. It's just part of the horse and pony show. Once you're in, you're in, and really, getting documented is no big deal ) so long as you're OK with getting your personal info inevitably stolen by some rouge state department) but otherwise harmless.
|
|
#
?
Mar 8, 2016 09:35
|
|
|
Ithaqua posted:I've never heard of being fingerprinted and having a credit check run as part of becoming an approved contractor before, though. They're a financial institution, but I've worked with plenty of those before without having to go through that. I also had it done (twice!) for my clearances in defense as well contractor and as a govie. Fuckin' OPM lost my fingerprints and so I'll probably have my Touch ID compromised on my phone someday given that all 10 of my fingers are on file. I stopped doing government work as policy to keep myself from stabbing myself with a butter knife but it'll follow me to the grave in this respect.
|
|
#
?
Mar 8, 2016 15:39
|
|
|
necrobobsledder posted:Had that done for my current job at a Fortune 10 and for a prior job where most of the clients were Wall Street or other financial institutions. Pretty sure you can change your fingerprints by stabbing yourself with a butter knife. Sounds like government work could solve some of your problems.
|
|
#
?
Mar 8, 2016 15:50
|
|
|
I just had a background check and drug screen (lol) to take a placement at big-name a national retail chain client. Didn't know about the drug screen until I verbally agreed to take it but I don't care enough about the dumb bullshit hoop to do anything but privately mock the whole practice.
|
|
#
?
Mar 8, 2016 15:51
|
|
|
|
| # ? Apr 19, 2024 16:56 |
|
|
I'm doing a semi-volunteer project updating a somewhat legacy webapp written in spring mvc and jesus christ what the gently caress is wrong with the people who wrote spring? I feel like spring is personally responsible for 85% of the java hate out there. edit: The remaining hate responsibility is 10% maven, 5% strong typing butthurt.
|
|
#
?
Mar 8, 2016 18:12
|
|