Hrdina wrote:The real disease is using something other than vim.
"you don't really need a career once you know vim"
I don't remember giving an interview.
Can't hear 'vim' without thinking of Tom Wambsgans now.
Probably an oldie, but it made me laugh today.
Can't hear 'vim' without thinking of Tom Wambsgans now.
Geez, I noticed this posting after submitting the one right after it.
Sadly, I read yesterday on /. that Bram Moolenaar, who created Vim, died last week.
I have moved on to neovim mostly now. But what a legend.
Sad that Bram is gone. While I was dissatisfied with the recent development path of Vim (that pretty much necessitated the creation of NeoVim), Bram will always be on my software development stars list for making Vim in the first place, and growing it over decades. vi would never have made it into modern contexts without the evolution that Vim provided.
Kinda surprised to see how little age difference there was between Bram and Bill Joy, creator of vi, who is 68 and still with us. They were only about 6 years apart, even though Joy created vi in the mid-70s and Bram started Vim in the early 90s.
Just had my first-ever "coding interview"!
This might be a hot take, but personally I'm not a fan.
Just had my first-ever "coding interview"!
This might be a hot take, but personally I'm not a fan.
Live coding during an interview is possibly the most useless indicator of an engineer’s skill.
fenomas wrote:Just had my first-ever "coding interview"!
This might be a hot take, but personally I'm not a fan.
Live coding during an interview is possibly the most useless indicator of an engineer’s skill.
Live coding can be useful, I've had some pretty decent results with it. If we like what we see on a resume, we send off a 'homework' exercise. We suggest it should take around two hours, but there is no hard time limit on getting it back to us. If we like the homework results, the next step is a technical interview. Before the interview we (myself and another developer on the team) come up with a list of potential bug fixes or improvements that could be made. At the interview, after I handle some intro stuff, the other developer leads a paired programming sessions, where we'll ask the candidate to work through one or more of the fixes or improvements we came up with. We stress that push back on the ideas is allowed, and that sometimes brings up useful conversations. Sometimes the candidate already has ideas and we let them work on that instead.
We try to simulate what an actual pair programming session at $work would look like. The candidate can use any resource they want. They are also free to use us as a resource. For questions that provide more context around the problem, or that have to do with the language syntax or how to do some specific thing in the language being used, we will answer directly. For questions closer to "how do I solve this problem in general", or if the candidate just seems stuck, we'll try more leading questions to see if we can help nudge them in the direction we were expecting. Overall we we try pretty hard to make it as comfortable as possible so we can get a glimpse of what working with the person will actually be like. We also try pretty hard to give a glimpse of what working with us would look like, since I think the candidate should be trying to interview us as well.
Do you pay them for those sessions? From the way you described it, it sounds like bug fixes or feature improvements on your actual codebase.
Probably the trickiest kind of interview to do is one where you are trying to access the candidate's level of competence with some kind of technical system (be it a programming language, some complicated API, standard system runtimes etc) or their level of comfort with certain kinds of programming concepts (dynamic allocation? type systems? funky OO runtime magic?) so you want to see if they can synthesize correct code fragments that use the system ... but you don't want the whole interview to be about just generating the code.
I suck at giving these kinds of puzzle interviews because I also suck at being on the other side of them. I'm more comfortable assuming a base level of technical competence and then having the interview be about higher level conceptual things. But, you always need someone on the interview team whose job it is to do a more detailed assessment of core technical skills. But it's a hard thing to do without turning the whole interview into a dumb programming puzzle.
"Homework" questions are a thing people do, but that can be tricky too because you are asking for unpaid labor before even hiring them.
Overall I think the best approach I've seen is to have some kind of more technical screen based around studying and adding to some existing code (vs. writing a whole new thing from scratch). Then you can get a good read on how good they are at interacting with the code and systems without making the production of the code the main goal.
I dont get the distrust of 'homework' and claims of 'unpaid labor'. No one is sending their IP to candidates and implementing their solutions with a 'haha' and a twist of their waxed moustaches. You get some hypothetical problem and create a solution to prove you can do it so your interviewers can see how you approach problems, whether your code is readable/maintainable, is in the neighborhood of the team's best practices, etc.
It's been a few years but when I did interviews involving whiteboard coding, I'd allow a lot of handwaving of library functions etc. I was totally uninterested if someone remembered argument order or that sort of thing, so pseudocode was fine. I was much more interested in how the person developed the carefully incomplete problem statement I gave them and if their initial approach to an algorithm made sense.
When interviewing for my current place one of the tasks was to do a code review on about a page of real code that had been artfully broken, and I think that's a good idea.
The issue with the one I took today is that it was a pass/fail "can you do these three straightforward tasks in an hour" kind of thing - no interesting data structures or algorithms to talk about. And the task involved way more typing than thinking. So while I "passed" (I guess?), I really don't think the interviewer learned much from watching me do it. And the task wasn't related to the company's actual tools/data/methodology, so from my side it was a dead hour where I learned nothing, except while chatting at the end because I finished early.
The other annoyance was they wanted the task done in a fidgety web IDE (codepen), so I shared my screen and spent the hour copy/pasting from my regular editor. It seems like an interesting company (and it's not really a job market to be turning up my nose at opportunities), but they kind of checked all the boxes I associate with bad coding interviews. That said, it's a young startup so if I join it's quite possible I could change the process.
Actually, real talk, I'm more annoyed because I was expecting a tricksy algorithmic l33tcode puzzle that requires DP or pathfinding or something. I kind of like puzzles like that, but none of my tech interviews has ever involved one.
When interviewing for my current place one of the tasks was to do a code review on about a page of real code that had been artfully broken, and I think that's a good idea.
This was in my most recent interview and I liked it
My last interview was I was given a Java project that was incomplete, and I had to implement the core algorithm. It had some gotchas in requirements that made it interesting to implement.
However, it was in a web editor type thing and everything was one giant scrolling page of text, and I foolishly tried to work within that system, rather than breaking it out into something that I could parse better. So I got really hung up on something silly and flailed around a lot mostly because I don't think I really was able to take it all in in the format it was provided.
I know going back I could do the thing, easily, but the stress of being watched while in an unfamiliar development environment completely threw me off and I did terrible. I don't blame them for passing on me, but I know I also didn't really show what I could do.
DuckDuckGo hires you for two or three projects (in addition to talking interviews) for which you’re paid. You work with the team on something like what they work on.
All test projects are paid, role-specific, and completed asynchronously on your own time. We won't ask you to perform tasks under the stress of live interviews (e.g., live coding), assign general brain teasers, or ask you to solve purely academic puzzles, all of which often set candidates up for failure.
I just give interviewees an open Vim session, and hire the ones that are able to exit it.
Do you pay them for those sessions? From the way you described it, it sounds like bug fixes or feature improvements on your actual codebase.
We don't currently pay anyone. Our actual codebase isn't involved at all, I meant bug fixing or adding some improvement to the code they submitted for their homework. It is unpaid labor in the sense that most companies don't pay for interviews.
As a candidate, I found that I prefer the homework approach over starting from scratch with someone I just met staring over my shoulder. You still get some of that effect with the code review and programming session, but at least you are working on something you already have some familiarity with. In our case we suggest that people use whatever tools and environment they would typically use, since battling with an unfamiliar IDE isn't useful to anyone involved.
My team's last round of hiring was at the beginning of the current generative AI 'craze'. One thing I dislike that we do is to require a cover letter. I like cover letters, as they can be a place to include information that doesn't fit well on a resume, but I keep pushing to remove the requirement, so far with no luck. It was decided as a company at the time that we wouldn't worry about whether a cover letter was a chat-GPT product. Now with co-pilot, I have been wondering a bit if we'll need to adjust our process in response. We allow it's use internally with a few restrictions, so I suspect we'll end up allowing for it's use, and that we'll just have to tweak the live coding session to account for it.
So...résumés for developers.
I know, I know. This is an evergreen source of contention, generally, and I assume that holds, too, for developers. "More than one page is a waste." "Include as much as is relevant, even if it's more than one page." "Measuring aptitude and experience creatively can be useful." "Only use Times New Roman and everything is bullet points."
I still really like my current team and like what I do well enough, but I'm feeling like I could use a change, some new challenges, and maybe work somewhere where my interest and skillset is more central to the company's core focus than it currently is. That is to say: my company is C#.NET on the back end, and so committed to that that working in Python introduces several very frustrating speedbumps. Also, we've tended to be more a skunkworks team outside the Product/Engineering division, so getting access to things requires finding the things themselves, finding out who owns them, figuring out how to get access, and learning how to conform what we do to established SDLC standards. It's been kinda frustrating.
Do folks have any specific recommendations for how to demonstrate experience on a résumé? Is a LinkedIn profile sufficient? Does anyone look at the kudos/attestations on LinkedIn from colleagues as any kind of indicator of experience and skill, or are they rubbish (which is my guess)? Does anyone read past the first page of a résumé?
Cheerio, and thanks!
qaraq wrote:When interviewing for my current place one of the tasks was to do a code review on about a page of real code that had been artfully broken, and I think that's a good idea.
This was in my most recent interview and I liked it
This sounds refreshing (and also right up my alley).
I had one interview 20+ years ago where I was asked to code something stupid like a bubble sort. I think the fact that I could not hide my disdain didn't help my chances.
When I was conducting interviews for analyst/programmer positions in the company I was working for, I took a "let's see how you respond to a typical problem" approach. I'd pick some small problem we had to solve and walk through the whole process on a whiteboard. I'd have the interviewer come up with a possible solution, pseudo-code some of one of the modules in their solution and finally have them implement a bit of the pseudo-code in our most used implementation language (PL/SQL).
Only then would I feel confident that they'll be able to actually do the job we were hiring for.
If I got push back from a candidate saying "I'm not coding solutions for you for free", I'll point out that:
- this problem was already solved years ago
- that I wasn't expecting runnable code or even complete solutions in the limited time frame of an hour interview
- that it would give me an idea of just how good they would be at the full "soup-to-nuts" process we expected FTE to be able to do.
I just give interviewees an open Vim session, and hire the ones that are able to exit it.
PM sent.
I just give interviewees an open Vim session, and hire the ones that are able to exit it.
I'd apply now, but as a wise man once said, you don't really need a career once you know vim.
Why would you ever close your vim session? That's like closing your tabs.
Why would you ever close your vim session? That's like closing your tabs.
Welcome aboard, Team Lead.
This "consonant cluster way" is unnecessarily complicated. The ZZ Top way is to write and quit by typing ZZ in command mode.
Pages