|
low-key-taco posted:This is pretty targeted at CS students, but does anyone have advice for someone trying to pass from IT to programming? I'm good with T-SQL and I've been gamely working my way through books and tutorials on C and Python, but should I even be bothering with the more theoretical stuff? Program as much as you can. Write code, write code, and write code. Also have someone tell you how much your code sucks, because it will for a while and the sooner you learn what you're doing wrong, the better.
|
#
?
Sep 9, 2011 20:56
|
|
|
|
| # ? Apr 19, 2024 12:25 |
|
|
 kes posted:or maybe they haven't spent enough time programming in a terminal to care one way or another? you can write code for unix with visual studio (and even compile it within the ide!), so i don't see any reason why you'd demand familiarity with a unix editor. 
|
|
#
?
Sep 9, 2011 21:35
|
|
|
kes posted:or maybe they haven't spent enough time programming in a terminal to care one way or another? you can write code for unix with visual studio (and even compile it within the ide!), so i don't see any reason why you'd demand familiarity with a unix editor. heee  
|
|
#
?
Sep 10, 2011 02:01
|
|
|
TasteMyHouse posted:If you don't know Big O, and at least have an inkling of how different common algorithms and data structures work, you're going to end up in the coding horrors thread. This is not usually the problem in my experience. I'm working on a project right now where people are writing a module that implements a context menu. It's taken two years to implement, consists of over 300,000 lines of code, and uses components written in three different languages: C++, C#, and javascript. I understand given the history of the project why it was done that way, but it's my firm belief that over-engineering is a huge problem - be lazy. Write understandable code. Use simple designs. It's always the clever, over-thought solutions to problems that lead to problems.
|
|
#
?
Sep 10, 2011 23:54
|
|
|
hieronymus posted:Write understandable code. Use simple designs. It's always the clever, over-thought solutions to problems that lead to problems. Readability suffers both from over and under abstraction. You tend to get the extremes a lot where people over engineer due to lack of knowledge or expert knowledge. I tend to find code written by beginners has excessive duplication of code, a complete lack of structure and piles and piles of if statements. On the other end, code written by PHDs seems to have been tempered by working for four years on a project to demonstrate novelty within research. Everything is a class. Every feature is decomposed into an elegant and towering hierarchy. Use all the features! It isn't as so simple as knowing enough to be dangerous. It's hard to get things just right, and programmers still seem to err on the side of 'too much abstraction'. I think there was something said along the lines of 'some people have ten years experience of coding and some people have one year ten times'. Most of education is focused on churning out code and very little attention is paid to operational or maintenance requirements. We still have this pyramid building mentality of software - grand towering achievements to last forever. We focus on writing and constructing new code over learning how to maintain and make code more maintainable.  we seem to only change how we make mistakes rather than learning from them
|
|
#
?
Sep 11, 2011 15:08
|
|
|
kes posted:or maybe they haven't spent enough time programming in a terminal to care one way or another? you can write code for unix with visual studio (and even compile it within the ide!), so i don't see any reason why you'd demand familiarity with a unix editor. Have you actually ever used vi? It's like having hot shards of glass stuck in your, erm, rather delicate areas. Ithaqua posted:That "5 essential phone screen questions" is a bit on the harsh side, honestly. Knowing computer science fundamentals doesn't hurt, but it hasn't come up in any job interview I've been on in the past 5 years. Curious, what sort of CS job interview hasn't at least touched on CS fundamentals?
|
|
#
?
Sep 11, 2011 18:46
|
|
|
I have a suspicion that's the guy that gave me my interview with Amazon so long ago. They have a weird hiring process I've heard though, so whatever.tef posted:business logic is not really amenable to algorithmic analysis, it shouldn't be that surprising This is all part of why I had to laugh at Y Combinator's Big Ideas suggestion on improving enterprise software - the solution to improving the technical quality of enterprise software is no more of a technical issue than world hunger is about producing enough food for the planet. We should remember, after all, that most software did come from the enterprise so long ago. On the other hand, I've certainly met some drat smart guys still in enterprise software. The other hypothesis I have is that the resulting software from these cultures is due to the chilling implications of the Milgram experiment. tef posted:We focus on writing and constructing new code over learning how to maintain and make code more maintainable. dazjw posted:Interviewing for programmers, not CJs.
|
|
#
?
Sep 12, 2011 00:56
|
|
|
Markov Chain Chomp posted:Have you actually ever used vi? It's like having hot shards of glass stuck in your, erm, rather delicate areas. This is such a subjective statement I really don't see how it adds to the conversation. Who cares which text editor you use? Yeah lets all have a good laugh at the noobs using nano, but seriously if they can kick out good code in nano, more power to them.
|
|
#
?
Sep 12, 2011 00:58
|
|
|
necrobobsledder posted:Only through maintaining other people's code can you learn from the mistakes of others and learn to never repeat their mistakes.  yes I am in total agreement hereedit: although when I wake up tomorrow I have a few points tef fucked around with this message at 01:14 on Sep 12, 2011 |
|
#
?
Sep 12, 2011 01:09
|
|
|
Innocent Bystander posted:This is such a subjective statement I really don't see how it adds to the conversation. Who cares which text editor you use? Yeah lets all have a good laugh at the noobs using nano, but seriously if they can kick out good code in nano, more power to them. I think he's referring to original Bill Joy vi, which is a pain in the rear end to use in 2011 for someone used to vim (or even elvis or whatever)
|
|
#
?
Sep 12, 2011 02:41
|
|
|
Otto Skorzeny posted:I think he's referring to original Bill Joy vi, which is a pain in the rear end to use in 2011 for someone used to vim (or even elvis or whatever) Exactly. The original context was vi vs. vim. That's not subjective, one is decidedly better than the other. Edit: added quote for clarity Cavern of COBOL's very own superstar Steve "flowEnol" Yegge posted:Bad Sign #4: blorpy fucked around with this message at 03:54 on Sep 12, 2011 |
|
#
?
Sep 12, 2011 03:52
|
|
|
Also, on most systems, vi is aliased to vim anyway, so chances are the interviewee was using vim and wasn't aware. Whether or not that raises a flag is questionable, although it does help to know something about the environment you're developing in.
|
|
#
?
Sep 12, 2011 04:00
|
|
|
necrobobsledder posted:This is all part of why I had to laugh at Y Combinator's Big Ideas suggestion on improving enterprise software - the solution to improving the technical quality of enterprise software is no more of a technical issue than world hunger is about producing enough food for the planet. We should remember, after all, that most software did come from the enterprise so long ago. Enterprise software is not made to have a beautiful user experience that saves time, or "just do one thing and do it right" design or any of that stuff that makes YC portfolio companies shine. It's designed such that a company with deep pockets can send out an RFP that describes all the ridiculous corner cases that they might encounter in their business once in a blue moon and a vendor can respond with "Oh yeah it'll hit that out of the park" no matter what the question might be. Then the client buys a license to a product that does none of that stuff out of the box, and signs off on a contract to have the vendor's consultants develop some custom bolt-on to address all the stuff the salesman promised. The vendor loves this because this means not only is it extra hours for their professional services organization to develop the custom stuff, everybody knows it's going to be an ugly mess that could well break spectacularly the next time the vendor puts out a maintenance release. That leaves a perpetual need for additional development/testing hours, which helps that sales guy's bonus later on. And maybe some line item in the functional spec that takes 40 consulting hours at god knows what bill rate to code a solution for is something that may only crop up once a year and can be addressed in 30 minutes by a $20/hour clerical employee. Time to payoff is centuries away, but that's all muddied up in the fact it's a "requirement" and they were promised it could be done. Finally after what probably has been (at minimum) months of schedule slippage, the system goes live. Then the users, who are not the people buying the software, actually get their hands on it. The custom bolt-on stuff doesn't "quite" follow the same UX flow as the rest of the system, making it harder for them to do their work.
|
|
#
?
Sep 12, 2011 07:09
|
|
|
necrobobsledder posted:Business logic problems can oftentimes be handled most efficiently (even measured on a financial basis - the Law of business) via algorithmic analysis. Very rarely for me. Most business logic I have encountered is simply dictating the model, rather than anything amenable to things like analysis or operations research. quote:That's gotten in the way of proving this for me for years has been rather simple - politics. It's a social problem, quick! Let's write a technical solution. quote:On the other hand, I've certainly met some drat smart guys still in enterprise software. The other hypothesis I have is that the resulting software from these cultures is due to the chilling implications of the Milgram experiment. When you build a project towards sales criteria instead of designing it, it is easier to sell. Once software had been adopted by the enterprise it is almost a guarantee that it will stagnate. People would rather use broken software they've learned how to use over trying software that works quote:Only through maintaining other people's code can you learn from the mistakes of others and learn to never repeat their mistakes. Coworkers have told me how easy my code is to understand and maintain, and that's enough for me to call myself a professional software engineer - you don't learn these practices through any means but pure There is often a misguided notion that we have to make newer programmers suffer as we did when we learned. It normally arises in the form of nostalgia - if only they learned on woefully inadequate machines then they'd understand todays computers more. There is something to be said for exposing younger programmers to larger code bases, as well as more analysis and review of code -- but we shouldn't be inflicting our mistakes upon them in the hope that they learn from them. It isn't going to be as easy to teach them by putting them through hell. I learned a lot from going through hell, but I don't think it is effective or the right way, but at the moment it seems like the only option available for getting programmers to understand maintainability.
|
|
#
?
Sep 12, 2011 11:44
|
|
|
I think repeating the experiences of your forefathers in the form of programmer is a form of hazing and even as great of a problem as reinventing the wheel, but I think there's many reasons why new programmers continue to repeat a lot of fundamental mistakes regardless of platform and we should try to separate what should be learned through trial by fire because there's just no better way to learn it and what should be imparted through indirect knowledge. I'm not about to expect today's software geniuses to be like Mel but I'd hope they understand the spirit of what being good in this field means... and also how Mel is probably not the right guy to hire in most of today's software projects.tef posted:When you build a project towards sales criteria instead of designing it, it is easier to sell. Once software had been adopted by the enterprise it is almost a guarantee that it will stagnate. People would rather use broken software they've learned how to use over trying software that works The consistent process in the past 15 years or so of enterprise software is this: 1. Start-up hires a bunch of smart people to address a business problem 2. Start-up gets 3/4 of the way there 3. Big company notices start-up and buys them out 4. Big company's policies suck and a mass exodus occurs 5. New developers hired to maintain the code I've seen this happen with almost every acquisition done by a Fortune 500 company that's not a software-oriented company (there's maybe a handful that are). kitten smoothie posted:Then the client buys a license to a product that does none of that stuff out of the box, and signs off on a contract to have the vendor's consultants develop some custom bolt-on to address all the stuff the salesman promised. That consultant does not want to have to maintain that code he had little wiggle room for design, he wants it to work well enough, document it, and make sure it becomes someone else's problem. I'll just summarize the state of enterprise software with a single image. If you think there's a technical means to change this state of idiocy, you're loving delusional.
|
|
#
?
Sep 12, 2011 16:20
|
|
|
Woo! I saw an internship posting on Indeed.com the other day, it's nearby and I was familiar with everything on it except AJAX. Shot 'em my resume and they responded today already by email. He just wanted to set up time for a phone call, so I presume a phone interview. I've never done a phone interview before, though. Obviously every interview is different, but I was just hoping some goons might be able to offer some insight! I feel pretty confident right now, but I'm sure when my phone rings and it's a number I don't recognize my stomach will turn into a ball of knots.
|
|
#
?
Sep 13, 2011 03:39
|
|
|
Hey goons, I realize this post is kind of the inverse of this thread. I just got my first actual job in software after graduation about 3 or 4 weeks ago. In the next couple of weeks I will be helping my manager interview for our first intern. I am cool with this, the only problem I have is I have no idea what to ask. The first applicant is just starting his sophomore year, I think (he went to my alma mater and judging from his skills listed and my old curricula). He's done basic Java and data structures, basically. Would this be a good question? Let's say you needed to make a custom stack. Given the choice between an array list and a (doubly) linked list, which would you choose, and why? Or should I ask a more open ended question, like "How would you go about making a stack data structure in Java"? A friend gave me a good second one, asking about how to go about trying to avoid collisions in a hash map. lazarenth fucked around with this message at 03:59 on Sep 13, 2011 |
|
#
?
Sep 13, 2011 03:39
|
|
|
Sab669 posted:Woo! I saw an internship posting on Indeed.com the other day, it's nearby and I was familiar with everything on it except AJAX. Shot 'em my resume and they responded today already by email. He just wanted to set up time for a phone call, so I presume a phone interview. My advice would be to make sure your phone is charged, make sure you are somewhere you won't be disturbed, and try to concentrate on what you're hearing. I had a little bit of trouble with the voice with no face for a bit, but after a couple it was almost like holding a conversation in person. As for the ball of knots thing, yeah, it happens. Just remember they are looking for you as much as you are looking for them. Be confident in your abilities (but don't fib  ).
|
|
#
?
Sep 13, 2011 03:42
|
|
|
lazarenth posted:I just got my first actual job in software after graduation about 3 or 4 weeks ago. In the next couple of weeks I will be helping my manager interview for our first intern. I am cool with this, the only problem I have is I have no idea what to ask. Ask him to write a function that takes a binary tree and return true if and only if it is a binary search tree. Have him login to some etherpad clone like http://typewith.me/ and actually type out the code. It's best to give him the link over email. This is so much more useful than just talking.
|
|
#
?
Sep 13, 2011 04:42
|
|
|
lazarenth posted:Hey goons, I realize this post is kind of the inverse of this thread. Ask it open ended. Ask how the candidate would handle collisions, not how to avoid them. Discuss pros and cons of his/her approach, performance costs, etc.
|
|
#
?
Sep 13, 2011 05:03
|
|
|
Those are horrible questions, you're basically asking if they've seen a hash table before or not and dealt with that sort of thing.
|
|
#
?
Sep 13, 2011 05:32
|
|
|
To be fair your 'check if binary tree is binary search tree' is a really really common interview question that you can find on a bunch of those sites that list technical interview questions. Might as well ask them to find the loop in a linked list using O(1) memory. One interview question I like to ask is any modification of this problem from Project Euler. They should be able to code the naive, slow version by writing a recursive algorithm, and then if they can't figure out a faster way you can sort of prod them a bit until they get the dynamic programming solution. Orzo fucked around with this message at 05:40 on Sep 13, 2011 |
|
#
?
Sep 13, 2011 05:37
|
|
|
Hmm, I didn't know that. We only use it as a warm-up question.
|
|
#
?
Sep 13, 2011 05:38
|
|
|
shrughes posted:Hmm, I didn't know that. We only use it as a warm-up question.
|
|
#
?
Sep 13, 2011 05:42
|
|
|
Orzo posted:What are some of your other questions, if you're allowed to disclose? I'm always looking for some good ones to add to our repertoire. Write a function that creates the mirror image of a binary tree. Write a program that computes the number of tic-tac-toe games. An array of N elements has the property that if you sort it, each element is within K units of its final position in the sorted array. That is, the position of the J'th smallest element of the array (for 0 <= J < N) is in the interval [J-K, J+K]. Figure out a sorting algorithm that is more efficient because it exploits this property. Given a 2D array of zeros and ones, find the largest square of ones. Two people are on a boat. Fred Lowenol falls off. Who is left? You want to implement the locking of intervals of an array. Think of how to do it. Invent an algorithm for finding the area of a union of rectangles that have vertical and horizontal edges. (This is excessively difficult.) You have a B-tree and want to randomly select a key. You want to support randomly and uniformly selecting a key from the btree. You can modify the btree data structure if you want. How do you do it? What if you can't modify the btree data structure?
|
|
#
?
Sep 13, 2011 06:10
|
|
|
where do you work?
|
|
#
?
Sep 13, 2011 06:27
|
|
|
shrughes posted:Those are horrible questions, you're basically asking if they've seen a hash table before or not and dealt with that sort of thing. I'd expect anyone going through a university CS program or with any experience to know what a hash table is and how it works at a rudimentary level. And if they don't, it's not like it's the only possible question to ask.
|
|
#
?
Sep 13, 2011 06:55
|
|
|
Chasiubao posted:I'd expect anyone going through a university CS program or with any experience to know what a hash table is and how it works at a rudimentary level. And if they don't, it's not like it's the only possible question to ask. The problem is that it's just quizzing them on knowledge they already may have, not knowledge on something new. It's perfectly reasonable for a student to have breezed by hash tables and forgotten them or had them skipped entirely in his data structures class. It's also easy for somebody who's not good at programming to recite the knowledge he was told in class. This doesn't select very well for good programmers, not as well as questions that talk about something they haven't seen before.
|
|
#
?
Sep 13, 2011 07:10
|
|
|
shrughes posted:Two people are on a boat. Fred Lowenol falls off. Who is left? What does this mean? Your questions remind me of programming contest questions. I guess if the job requires a lot of algorithm optimization work or something they might be valuable, but for example, I write front office financial software where large scale resource management skills, ability to quickly learn new frameworks, and domain knowledge are far more important than being able to generate solutions to academic problems in an interview. I like these since you're looking at concurrency and dynamic programming: quote:You want to implement the locking of intervals of an array. Think of how to do it. But these seem excessively academic and not very useful unless you're just testing to see how the programmer approaches the problem and you're not actually looking for an immediate correct answer: quote:Write a program that computes the number of tic-tac-toe games. Here are the type of questions we'd ask: quote:A database supports only 10 concurrent connections. A distributed client must be able to be run by 20 users simultaneously. How do you protect against resource lock?
|
|
#
?
Sep 13, 2011 07:21
|
|
|
shrughes posted:The problem is that it's just quizzing them on knowledge they already may have, not knowledge on something new. It's perfectly reasonable for a student to have breezed by hash tables and forgotten them or had them skipped entirely in his data structures class. It's also easy for somebody who's not good at programming to recite the knowledge he was told in class. This doesn't select very well for good programmers, not as well as questions that talk about something they haven't seen before. That's entirely possible. I think it's unreasonable to say that questions on data structures are off the table because someone might already know about them. Buuut you know what I feel like this about to turn into a religious discussion so I guess I'll just say that I think everyone's looking for different things in an interview and I don't think that anyone has the perfect answer 
Chasiubao fucked around with this message at 07:49 on Sep 13, 2011 |
|
#
?
Sep 13, 2011 07:37
|
|
|
baquerd posted:Your questions remind me of programming contest questions. I guess if the job requires a lot of algorithm optimization work or something they might be valuable, but for example, I write front office financial software where large scale resource management skills, ability to quickly learn new frameworks, and domain knowledge are far more important than being able to generate solutions to academic problems in an interview. We need that too, except we don't have any particular domain knowledge, unless you consider CS to be our domain. It sounds to me like it's pretty hard to test for large scale resource management skills and ability to quickly learn new frameworks in an interview. Also, you can only really differentiate between college students on their basic coding ability and body odors. baquerd posted:I like these since you're looking at concurrency and dynamic programming: It turns out that the concurrency problem wasn't a very good question. There are plenty of worthy people who don't know enough about concurrency or who don't know about data structures for storing intervals (once we get to the read/write lock part of the question), and it's too easy for the interviewer to let the interviewee get by with a B.S. answer. We work on a highly concurrent system, but it's not like we expect everybody to really know about concurrency up front. baquerd posted:But these seem excessively academic and not very useful unless you're just testing to see how the programmer approaches the problem and you're not actually looking for an immediate correct answer: On the tic-tac-toe question we expected the person to write code on the whiteboard, and we were really only interested if they could get an implementation without being retarded about it. That question's pretty good at identifying which people can't actually write code. That was for a former employer that worked on enterprisey software that dealt with what you might call large scale resource management. The others are just general see-how-good-you-are-at-thinking-about-algorithms-and-data-structures questions, and yes, we're not looking for an immediate correct answer, but we do expect an answer eventually, on most problems. I don't see how a good interview question could ever expect an immediate answer, unless it's a warmup question. Algorithms-and-data-structures is generally the skill we're selecting for. Randomly selecting a key from a btree (ideally without encoding new information in the btree structure) is a specific problem we've dealt with. The sorting question is one that anybody with a general CS background should be able to figure out. (Of course, I criticized the hash table related question, and this question is biased towards people more familiar with sorting algorithms, so it looks like I'm wrong about something.) The rectangle union area problem is completely insane, only good for seeing how awesome an extremely awesome candidate can get, and the first half of the randomly-selecting-key-from-btree question attacks the same data structures abilities, without being completely insane, so I don't use it the union area problem anymore. baquerd posted:Here are the type of questions we'd ask: I'm assuming you also have questions that involve them showing that they can write code instead of just talking about it. Also, "What is your approach to learning how to use the API?" seems like a bad question to me, not that I've tried it. What is a "good answer" to this question and how does it mean the candidate is a better learner or better candidate than a "bad answer"?
|
|
#
?
Sep 13, 2011 08:24
|
|
|
shrughes posted:Also, "What is your approach to learning how to use the API?" seems like a bad question to me, not that I've tried it. What is a "good answer" to this question and how does it mean the candidate is a better learner or better candidate than a "bad answer"? The question as I put it should be further specified: "What is your approach to learning how to use the API for this particular problem?" We're looking for "practical" programmers who are used to looking at others code and are able to extend that code in a short time frame. A good answer reveals a developer who is going to be deadline focused. Generally this means heading for the code samples and extending those examples towards practical usage as soon as possible. The API is then for reference, taking the time to browse the class list when looking for expected functionality or just to get a general idea of the full structure is alright, but no more than a day should be spent attempting to learn from the documentation before starting to put code together. I'd also expect 2 days to be budgeted to testing and deployment. There are a surprising number of people who answer they'll start by reading all of the API documentation, which in practice tends to mean they're not used to producing things in a short time frame or want to spend more time getting it 100% right instead of meeting deadlines. They tend to want to get the full picture of how everything works together instead of jumping right in to produce a working product. This can certainly be a good thing, but not in the constraints of the problem. It's not about learning so much as quickly producing a functional and well-tested product (assuming a week is tight but reasonable). It's far better to have a inefficiently designed but workable product (that can be later revised) than to miss certain deadlines.
|
|
#
?
Sep 13, 2011 10:30
|
|
|
shrughes posted:Two people are on a boat. Fred Lowenol falls off. Who is left? I would also like to know what this is supposed to mean.
|
|
#
?
Sep 13, 2011 10:44
|
|
|
Sab669 posted:I've never done a phone interview before, though. Obviously every interview is different, but I was just hoping some goons might be able to offer some insight! I feel pretty confident right now, but I'm sure when my phone rings and it's a number I don't recognize my stomach will turn into a ball of knots. Stay calm, ask questions when you get stumped. For an internship especially, they are looking for someone who can fit within the company and pick up the skills they need. Attitude counts for a lot more than experience in an internship.
|
|
#
?
Sep 13, 2011 11:43
|
|
|
necrobobsledder posted:These problems are not solvable through technical means because the problems are constantly shifting, too - you're trying to code against a moving target. So the best you can do is determine where the target could land and make sure it can at least function then. As someone in a small company writing the product, I can happily testify to the brutal truths within your post. I have to focus on being able to change targets more than delivering on them.
|
|
#
?
Sep 13, 2011 11:45
|
|
|
lazarenth posted:I just got my first actual job in software after graduation about 3 or 4 weeks ago. In the next couple of weeks I will be helping my manager interview for our first intern. I am cool with this, the only problem I have is I have no idea what to ask. here is how an application with me normally proceeds: code sample: After we get an application, we ask the candidate to either provide a code sample or write one for us. We're looking for something that is fairly short to write and reasonably complete in less than an afternoon. Once we get the sample back, we look at it and decide if we want to move it forward to an interview. note: you want to pick a code sample question relevant to your work if possible, and when in doubt asking them to implement simplified versions of command line tools can work too (wget, grep, curl, etc) we tend to ask people to write a single threaded example and then expand on it within the interview to hear about the approach they'd take to making it multi-threaded. interview: if we do decide to interview, we usually have a long phone interview with one or two engineers. we introduce ourselves and give them a brief outline of the interview process, and then leap straight into the code sample. interview - code sample: we ask them to explain how it works and the design choices they made we talk about features they omitted and how they might implement them, in particular we like to touch upon concurrency here. we ask about threading, locks, stm, actors and any other styles the candidate has familiarity with. interview - experience: we then move back to the resume, and work through the candidates experiences with tools and projects, asking harder and harder questions until the candidate is stumped or the interviewer is stumped. we're trying to measure the depth of expertise as well as the breadth. for example: c/c++ - start with stack vs heap, move onto things like volatile, virtual, raii, exceptions/destructors also looking for experience with large frameworks (e.g. qt) web development -- questions about cross site scripting and sql injections java - asking about enums, generics, and ask them to explain any item in java.util.concurrent python - asking about the gil, unicode really you want to ask about known pain points, gotchas and other language warts to see how much they've used it in practice. interview - domain knowledge: for us, we use http and unix /heavily/ so we tend to focus on these areas in particular for unix we get them to talk about command line tools they find useful, and ask them about how they would do some basic sundry commands my favourite question to ask is: 'can you explain from start to finish how a web browser fetches a page on the internet' and ask them to go into as much depth as they are comfortable with. bonus points for knowledge of http bits like caching/redirects, as well as tcp and dns mechanics. interview - frameworks/toolkits we like to talk about the experience they have with larger and more established toolkits. this is where we focus on how much code the candidate has read, rather than written. interview - company specific bits: you'll excuse me for not sharing these bits as they aren't relevant, beyond this is where we explain the company in a little more detail, evaluate how well they've grasped our industry and talk about some of the bigger challenges that lie ahead. i've tried to avoid giving you a question/answer sheet -- a lot of the questions I ask in the interview are based upon my own experience and knowledge and that isn't so easily transferred. most of the canned questions in interviews tend to fall into the style of the 'terrible lateral thinking puzzle' - ones in which there is a trick to answering and so I abhor them. if I want to know if a candidate knows about hash tables I will just ask them directly tef fucked around with this message at 12:23 on Sep 13, 2011 |
|
#
?
Sep 13, 2011 12:20
|
|
|
shrughes posted:The rectangle union area problem is completely insane, only good for seeing how awesome an extremely awesome candidate can get, and the first half of the randomly-selecting-key-from-btree question attacks the same data structures abilities, without being completely insane, so I don't use it the union area problem anymore.
|
|
#
?
Sep 13, 2011 15:39
|
|
|
Plorkyeran posted:Am I missing something about the rectangle question? It seems fairly trivial if you're willing to accept an O(n^2) solution - just sum the areas and subtract the areas of the intersections. And add the areas of the three-way intersections and subtract the areas of the four-way intersections and ...
|
|
#
?
Sep 13, 2011 15:55
|
|
|
qntm posted:I would also like to know what this is supposed to mean.
|
|
#
?
Sep 13, 2011 16:04
|
|
|
|
| # ? Apr 19, 2024 12:25 |
|
|
shrughes posted:And add the areas of the three-way intersections and subtract the areas of the four-way intersections and ... The best I can come up with is to compare every pair of rectangles, and if they overlap reduce them into components like so:  Then dump the components back into the pile, and repeat until there are no overlaps, then sum up the areas of the rectangles.
|
|
#
?
Sep 13, 2011 17:02
|
|
