NoSql systems maybe. Solr and Mongo seem like the two most popular. You might be better placed for intersting work if you have subject matter experience in a field that needs software.
Spoken as someone who likes Solr and doesn't like Mongo.
Besides, analytical techniques for assessing big datasets are usually pretty rudimentary, the same battered crowbars and hammers. Practitioners don't seem to need to understand much. Lots of people who carry a "data science" title gripe about formatting and validation rather than the shortcomings of their pathetic analytical resources.
whoops, I don't know Mongo rather than disliking it, typo.
Possibly a Freudian slip, I kind of dislike a nearby Mongo advocate.
Mongo only pawn in the game of life
I'm thinking of calling myself a data scientist. As near as I can tell, nobody can stop me.
Alex Raymond, who drew the best years of Flash Gordon (where Mongo was a villain) is pretty interesting. Both as an artist and as a cultural figure-- he started out drawing barbarians as the foes of civilization, switched to Mongo's sinister empire, and then drew Rip Kirby, which was kind of an early James Bond with great fashion sense and really inspired comic art.
As someone in roughly the same boat, I think it's more about the teams that you would be joining rather than the actual job title. Look to join teams that already have a CSS specialist (or where the UI is all provided by an out-of-the-box library of components you don't really have to customize), and where your role is mostly designing the data flow and application architecture, potentially including back-ends that are doing simple integrations of service calls or basic CRUD. I think knowing principles and protocols (OOP and FP, API design, Oauth, web security, testing, domain modeling, REST, algorithms and data structures) matters more than knowing other technologies, but know enough about other mainstream languages (Python, Java) and their ecosystems that you can understand the commonalities and differences from JavaScript in how they implement those foundational principles and use those protocols.
Explain the benefits of regression modelling.
https://www.phoenix.edu/courses/dsc101.html
Actual regression modeling not included.
I'm not elitist but I'm not desperate either.
I didn't see a faculty page anywhere.
I wonder who teaches those courses, especially computer topics; what would be the motivation to choose that setting?
I understand wanting to teach at a less selective place, but not at an appalling less selective place.
My guess is that the students and the faculty both are those without other choices.
Currently, I would think that job prospects are good - the market is tight and people are willing to hire outside of their particular business domain.
I've had a 25 year career largely in banking and government ID, mostly C++, C# and Java. Web front-ends were common, but never particularly polished - if I add a little Bootstrap and pick a font other than Helvetica everyone thinks I'm a genius.
I think the Bay Area (that's where you are, right?) is a unique environment. Everything is essentially a very pretty CRUD application, funded by having a ton of users and selling them ads.
My title has always just been "Software Engineer". Mostly, I write software that lets this computer talk to that computer - a point of sale device needs to communicate with various banks, or an MRI needs to send images to a 3D imaging workstation, or I need to move key histories from one system to another. UIs don't need to be particularly appealing, although it's nice if they aren't hideous.
It's like when you are asked why you're using the men's room at Arby's. Because there are security cameras in the alley behind it.
13: used to be. Now Chicago, I think.
I don't know if the Bay Area even has Arby's.
https://locations.arbys.com/ca.html
Not sure -- apparently none in SF or Oakland.
I'm thinking maybe that wasn't a serious question.
msw/13 has it right. Since the 70s there's been a steady demand for developers who know how to develop corporate IT apps using the technology du jour. It sounds like your courses (IIRC, a bootcamp) didn't teach you what would be classified as "up to sophomore year" CS? Honestly, that's more than what's required to survive happily in the "COBOL dungeons of the 21st century". If I read you right, you're wanting to move towards the back-end of your company's apps? Become the guy who works back there? That's not a difficult transition.
So here's what I'd suggest:
(1) take a sophomore data-structures/algorithms course. Basically, the *first* one that CS students take. Maybe take a "discrete structures" (== "logical reasoning", boolean logic, etc, though maybe you already have this from elsewhere, in which case it'll be review).
(2) Learn a language like Java or C# *well*. Conveniently, you already have a way to use C# at work, so that's probably the one to choose. [Later,] You might consider doing the same with Javascript.
(3) Learn SQL really well. I mean, *really* well. There's two senses of that: (a) learn data-modeling (entity-relationship modeling), SQL queries, etc, in the general, DB-independent sense, and (b) specifically for one database. You'll want to do both, and specifically for the DB used by your company.
You should be able to do these things without spending any $$: there are decent courses all over, published by universities. E.g. MIT Open Courseware, but I'm sure there are others.
This should change your understanding of coding enough that you can start "reaching back" in the problems you tackle at work. Maybe start volunteering to track down bugs in the backend?
I realize this sounds like a ton of work. But it's actually not: it's three courses at a decent school, and all early in the sequence. The reason I added "SQL" to the list, is this: everything else will change. So what used to be "ISPF talking to COBOL" becomes "Powerbuilder talking to SQL stored-procs (BASIC)" becomes "VB talking to C++". But eventually, they all gotta hit the database, and that's SQL. And that doesn't change. Which obviously means you can learn SQL the slowest.
Seems like if you're already doing some C# stuff you could just ... do more of that? When I first started at my present job I occasionally did some front-end stuff, which I hated, and now I basically solely do Python and have been for years. (The non-Python stuff is because I'm now on the forrmerly-known-as-infra group, which means I occasionally have to look at Terraform or various config languages or whatnot.) Can you tell your manager that you'd like to move more to the backend side of things?
So advice for someone with an onsite at a certain company in Downton Moo in two weeks?
It's for "Software Engineer, Front End". From what I've been told from my recruiters or gathered online, two or three of the interviews are solving the same algo/ds problems they generally ask of anyone, and the other two or three are more domain specific.
I plan on focusing on practicing problems solvable through manipulating trees and graphs, because I've probably spent less than 40 hours of my education/work life doing that and they seem to put a lot of emphasis on it.
In the space I work in -- cultural heritage IT (libraries, galleries, museums) -- good front end and genuinely full stack developers -- not FE devs who have a tiny bit of backend or vice versa -- are much harder to find than good backend developers, and it's much easier for me to find work for people in my team who do that than for the backend devs (which includes me, although I'm officially a product owner, rather than a full time dev). I'd love to have more FE skills myself, as it'd help with prototyping and building proof of concept apps.
Things that seem to generate income on the backend side, though, and are interesting, are getting more into architecture and devops, or doing things around linked data (working with triples, json-ld, sparql, etc), data science type techniques, graph databases, natural language processing, and understanding and handling image and text processing.
I find myself mostly building little Python microservices or data munging apps that use those types of techniques. I'm not really an expert in any of them -- far from it -- although I do quite a lot of NLP work, work around linked data, and working with graphs, in my own development work. I don't have the solid CS 101 knowledge that has been described above (although my understanding of formal logic* is at a pretty high level).
What I personally bring to the table, though, is domain knowledge. I really understand the problem space, the various open standards and APIs that are in use, and how those things interface with "political" and practical issues -- including funding -- in the cultural heritage space.
I expect that's not very helpful, as advice, though.
* having a PhD in philosophy helps. In fact, that helps in a lot of ways. I find other people are _terrible_ at describing problems, or articulating technical solutions in words that can understood by non-developers or by developers who don't understand the domain, and I am pretty good at that. Just being able to write N hundred words of clean understandable prose is a skill that many developers and technical people lack. Also, I'm extremely _fast_ at that, too.
That's hard to answer, since it really depends on individual circumstances and skills. What do you consider "big-brained"? Is being a C++ software engineer big-brained?
(I teach CS at a mid-sized university.)
I was afraid I was going to have to learn SQL to get a new job, but I never should have doubted that learning something besides SAS was unnecessary.
ttaM's footnote is extremely correct.
A lot of good advice here, thanks. Just to clarify, although my current company is pretty fabulous, I'd like to get a fully remote job, which they don't offer, so at some point I'll look to leave.
I agree that I should keep learning C#. I know Javascript somewhere between very well and pretty damn well, but I get the sense that knowing another language, particularly one that's strongly typed, gets you taken more seriously for a lot of jobs.
linked data (working with triples, json-ld, sparql, etc)
I'd never heard of this, and it sounds super interesting. Exactly the kind of thing I was hoping to get out of this thread. Thanks for the pointer.
Chet, your 2 and 3 seem like solid advice. Can you say more about #1? What's the actual payoff in a) getting a job and 2) doing a job? I'm curious because there's a lot of emphasis on data structures and algorithms, even in bootcamp, but in two years as a competent developer, I haven't had to think about them even a little. (Maybe the answer is, hey, buddy, if you think linked data is interesting, you better know your graph theory.)
ttaM's footnote is extremely correct.
Yes. My nearly-eidetic-memory manager has since been promoted, and as good as he is technically, communicating with him is often an exercise in "what the fuck does that mean?" My new manager has what I think of as the "child of teachers" trait of being able to give pithy explanations of technical topics, and it's like everyone breathed a sigh of relief when he took over. Oh, that's what we're doing, and that's how we're doing it.
20.3 is good. Without needing to become a DBA, you should definitely have basic database sense - given a set of objects to represent, you should be able to spit back what are the tables you'd use, how you'd set up the primary and foreign keys, and you should also have a good sense of how to structure SQL queries for performance (which usually means, do as much as you can in one big query rather than many little queries, and don't join on more data than you actually require). Depending on the language, it can also be important to have a working understanding of the ORM du jour (the ones I know are SQLAlchemy in Python, ActiveRecord in Ruby, Sequelize in Node, C# must have something analogous). I dislike a lot of things about ORMs, but they're so widely used that you'll want to understand their mechanics and be able to give a good argument for dropping down to raw SQL when appropriate.
In ~5 years of back-end development, I've never knowingly had to call upon anything that would have been taught in the algorithms/data-structures courses I never took. I'm sure I must have occasionally and unwittingly hit on some common problems, but these days most of that brute optimization will come for free in one library or another.
27/23footnote is also correct.
I should amend ~5 to... ~8 now? Ghastly.
Lastly, if you're considering learning one more language specifically for back-end purposes, my feeling is that Python, even if not strongly typed, might be best for this historical moment.
What's the actual payoff in a) getting a job and 2) doing a job?
In terms of getting a job, it will very likely help with whiteboard/coding interviews, at least the kind that are done around the SFBA.
In terms of doing a job, well ... In a roughly similar amount of time as lourdes kayak, I have occasionally had to call on knowledge taught in algorithms & datastructures courses; more algorithms than data structures, though. When it's data structures, it's more like "this calls for a heap" than implementing a heap; when it's algorithms--usually, IME, some kind of graph traversal--I've more often implemented it to my specific use case than tried a library's solution. (Whether that's been wise on my part is another issue.) But even so, being able to have the thought "this data is roughly graph-shaped and if we had its transitive closure we could solve the problem thus and so" can, occasionally, be useful.
C# must have something analogous
Bro C# has language-integrated queries, or haven't you heard? (LINQ afaict is actually super cool.)
Huh! Never having done a thing in C#, LINQ is new to me. That does seem like a reasonable way of doing it.
28: C# might not be your best investment if you're interested in a remote position doing backend work, as the kind of companies open to hiring remote are likely to be using something else (C# being more associated with the enterprise sector). Python is an extremely safe choice, but you can also leverage your Javascript expertise by developing familiarity with node, which is in wide use among startups of the sort that will hire remotely.
I've used LINQ (and Sequelize) a bit, not a ton, but like a lot of things in C#, I actually like it.
given a set of objects to represent, you should be able to spit back what are the tables you'd use, how you'd set up the primary and foreign keys
I have no sense of these things at all. A friend is a DBA and I told him it just seems like dark magic to me. I guess I should learn some. One frustrating (or is it a blessing?) thing about my current job is that we touch everything except the data layer. That's all handled by the API team.
37 seems right about the practicalities of the job market. Although JS is being swallowed bit by bit by Typescript, which is developed by the same guy who made C#. My tentative plan was to learn enough C# to sell my "seriousness," and look for remote Node jobs. Learning enough of the whole .NET ecosystem to become .NET guy is too daunting for what I hope is a 6-12 month plan (with a full-time job and two little kids).
Although now I really want to read up on linked data.
ogged/28:
OK. First, an aside: Many people don't understand the purpose of "the Google SWE interview'. Which consists in on-the-whiteboard coding problems and system-design problems. Esp. since the work is invariably nowhere near that challenging. I mean: "dull as watching paint dry" unchallenging. Why does Google do it? Well, you have to understand what they're testing for. If you wanted to hire a guy for your juggling troupe, and dropping a pin/ball was really, really bad, how would you interview? Have the guy juggle 3-to-7 pins for a few mins? B/c that's all he'll do during a show. NO! You'd have him juggle 15 pins for an HOUR, and send in troupes of midgets, barking dogs chasing cats, a man in a gorilla suit, and maybe a dancing girl or two. And if he STILL doesn't drop a pin, then you'll KNOW that he won't drop a pin during the show.
Analogously, the utility of that first data-structures/algorithms course (I was careful to not specify even *senior*-year algorithms -- I'd suggest that for someone who wanted to aim for jobs at the big tech companies, and doubt that it's really relevant for jobs in I/T at the average big company)[1] is in training your mind to be able to carry moderate amounts of detail during problem-solving without losing track. It's actually really important, and most important during debugging.
Hope that helps.
P.S. If you want to stay in the "corporate IT" sector, I really do believe that (long-term) getting to where you understand SQL and entity-relationship modeling is insanely valuable. It is shocking how often that skill comes up. And I've never taken a database course: learned everything I ever knew from my database tech sales specialist Chris ("I'm not a saleman, I'm a tech sales specialist!!") and his colleagues. On the streetcorner, in-between helping 'em sell DB2 licenses.
[1] and even for those big tech companies, the relevance of senior-year algorithms is again mostly in being able to solve harder problems without error, not actually needing those algorithms. B/c you're not gonna be writing "strongly-connected components" on the job.
A friend is a DBA and I told him it just seems like dark magic to me
Being a DBA in the sense of being able to tune database performance and knowing One Weird Trick to dramatically speed up queries etc is dark magic, but that's a separate (and much harder to acquire and better remunerated!) skill from being able to go from a description of the sort of data you're getting and coming up with a set of tables and their relationships! Don't be put off!
Why does Google do it? Well, you have to understand what they're testing for.
I think the real reason is that they have no clue how to conduct interviews. I give the explanation you offered zero credence.
A little bit more in answer to ogged/28:
[You mentioned that there was a lot of emphasis on data-structures/algorithms in your bootcamp. One way of calibrating that (b/c you really can't tell unless you compare it to something?) might be to take a book like Aho, Hopcroft, and Ullman's Algorithms (the one with a graph on the front cover) and see how much of it you already know. It was my -senior- year algorithms text (lo these 32 years!) so that isn't the best. A better one might be a really, really old copy of Algorithms by Peter Sedgewick. Back in the 80s it was .... more introductory than AHU. Maybe Ken/24 could suggest a good book to use as a measuring-stick. If you find that you're already at the point where such a book is old-hat, then yeah, just skip past that.]
I don't disagree with nosflow/34. Sometimes you find the need to use these data-structures, and/or make up a nontrivial algorithm on the spot. Even in work. It happens, really it does. But I'm *assuming* in my answer #40 that that never happens. It's -still- important to have some basic facility with (again, the first layer of) algorithms and data-structures, b/c they train your mind to not make mistakes.
There's two reasons someone gets paid more as they get older in the I/T biz: (a) they're good at presenting to managers -- at selling themselves, sucking up, etc, and (b) b/c they don't make mistakes, can be counted on to not make mistakes, and can also be counted upon to find and fix others' mistakes, again with high confidence. All of this assuming that they learn the relevant new technologies as time passes. Also (speaking as a 53-year-old) as we get older we get slower. It's shocking how much slower. Being more -accurate- is a way to fight back against that aging and slowing-down. If you get it right the first time, it matters less how long you take. B/c lots of others have to back and rework again and again.
Something more about "graphs, triples, NLP, etc" mentioned by ttaM. All of that is cool stuff, and as it filters into the mainstream (e.g., "data warehousing" got killed-off/replaced by Hadoop, heh) you'll have to learn that stuff. I'm assuming you want to get onto the escalator, so to speak, and so like msw, I addressed the sort of "old-skool corporate IT" workload and skill-set. Obviously once you learn these things, you'll find it easier to keep on learning, and eventually maybe learn one of these new wind-in-your-hair fancy technologies.
*My tentative plan was to learn enough C# to sell my "seriousness," and look for remote Node jobs.*
Speaking as someone who's done a fair amount of hiring: That's not going to help you in the way you think (if I'm interpreting you correctly). Even if you foreground C# expertise in your resumé, it's unlikely you'll be given any opportunity to demonstrate that expertise in the process of interviewing for a Node job. (You could submit sample projects in C#, but they're not likely to be closely scrutinzed.). Mastering a statically-typed, object-oriented language will make you a generically better programmer, but don't think of the time you invest there as directly subserving the goal of acquiring a remote Node position.
That's not going to help you in the way you think (if I'm interpreting you correctly)
What I'm thinking of is the prejudice against Javascript-alone front-end devs as people who aren't fully "programmers" (yeah, he knows React/Vue/Angular/Whatever, but can he code?). I was hoping C# competence was a way to mitigate that. There's also the matter of C# being essential for my current job, getting promoted, and all that.
What I'm thinking of is the prejudice against Javascript-alone front-end devs as people who aren't fully "programmers" [...]. I was hoping C# competence was a way to mitigate that.
That's how I understood your concern. I was just trying to temper your expectations about how effective that strategy will be, as the whole interview process is a shallow and scripted one that's not designed to pick up on that sort of thing, and the people evaluating you won't be primed to notice.
On the other hand, if you're able to rip off Javascript solutions to the problems in Cracking the Coding Interview, that will register, and you should take that into account when deciding how to allocate your study time.
ogged/28:
Data structures and algorithms are clearly not important in all jobs, but are important where you need to squeeze every last bit of performance out your hardware, where you can't use the standard library version, etc. For example, let's say that you are working at Amazon, not as a data scientist, but as a software engineer. They tell you that they need to implement k-NN on 1 billion data points. You'll need to know data structures and algorithms to make that happen.
As another example that I ran into recently, the C++ standard priority queue does not allow removal of elements that are not at the top. We need that for a performance sensitive project, so we'll have to write our own priority queue.
42:
Cormen, Leiserson, Rivest, Stein is the go-to book for algorithms these days (haha, accidental pun). Also, I think you meant Robert Sedgewick, not Peter.
P.S. Assume the k-NN is on 100-dimensional, geographically distributed data.
I'll put algorithms on my list of things to learn. I think the advice here boils down to 1) know the fundamentals 2) be well-rounded. Both seem solid.
Now, if people know of other cool sub-specialties like the one ttaM mentioned, I'd love to hear about them.
What's a good course or book for acquiring a "database sense"?
I think this whole thing where you learn how to do something and then you get tangible rewards because you have more skill is going to come to an end soon. Adjusting for inflation, I'm now earning what i did during the first tech boom for the first time since. Science says it's time for everything to blow-up everything again.
The words I'd think you want to look for is "backend" or "architect." You may not be ready for the latter, but advertising yourself as a backend C# programmer should open some doors. You may also want to briefly look into Java--the languages are fairly similar (although they diverge more every year), and this'll let you shop around more.
41: They have no clue how to conduct interviews--or at least, not as a group, individuals vary--but at least they don't ask the brainteasers anymore.
nosflow's and ttaM's advice largely agree with my experience. Most development is not very different from other development, and it's easy to slide into a different role; if you're 1) comfortable with shunting data around and 2) good at communicating with other people, you can probably find a role that provides what you'd like.
Knowing data structures and algorithms are important, but in a general sense that you can know about knowing them. I might not know if there's some obscure algorithm that solve problem foo in O(bar) time, but I can read a paper on it--or better, judge whether a library that implements a solution does so efficiently.
The much more common case of algorithmic issues than the hard problem Ken mentioned is taking someone else's code and replacing their naive O(n^2) solution with an O(n*log(n)) one by a minor loop tweak, or using a more appropriate data structure. And just as common, and perhaps more important than that, is tweaking the constant coefficient.
Oh, and yeah, being comfortable with databases is very good. I took Stanford's online DB course, which probably got rolled into Coursera, six or seven years ago and it was very good, comparable to the DB course I took at $good_computer_school. (This shouldn't be surprising, since the Stanford prof was my prof's advisor.)
The advice about being comfortable with a specific RDBMS matters, too--even if they all implement SQL, they all do it in slightly different ways. Annoyingly different ways.
As for sub-specialities, I think parsers are fun to work with; making a small domain specific language to make your quasi-technical coworkers' lives easier could make you quickly essential.
Hrm, maybe it isn't on Coursera--weird, since at least a few of the other Stanford offerings from that period are. Anyway, this seems to be what it's turned into.
I think the real reason is that they have no clue how to conduct interviews. I give the explanation you offered zero credence.
I agree with this, and would like to opine that even if this is somehow the rationale, it is a terrible one. Finding that someone doesn't make mistakes while executing a challenging task will not ensure that they will not make mistakes on a boring one! Just the opposite. If they are really using that reasoning they don't understand anything about human psychology. Also from my understanding you're not necessarily judged on being totally error free in your whiteboard solutions, but it probably varies by employer.
I'm not even hostile to whiteboard interviews. If I were to offer a rationale, I think it is sort of reasonable to have a part arbitrary, part job-relevant-across-a-number-of-domains standard corpus of analytical tasks that require a combination of memorization, pattern recognition, and thinking on your feet. Those are relevant skills to test for, and in some ways it's fairer and allows assessment of people's abilities outside of a bunch of domain specific knowledge, which, if it were the only means of assessment, would really pigeonhole devs. (The "being watched" aspect of whiteboard interviews seems unfair and totally unlike the actual working environment.) Everyone knows the set of material to get through to be able to do well at them. I thought that Homebrew developer who complained that he couldn't get a job at Google because he couldn't invert a binary tree was being pretty whiny. But honestly if there's one thing whiteboarding *doesn't* test for it's steady conscientiousness.
Not that I know about it in person, but I find tech interviewing baffling. I can do lots of things, but nearly all of them require me to look up a detail or something. The actual skill is that I know how to look these things up and what the actual solution would look like.
Honestly, half the value of learning data structures and those kinds of algorithms is so that you are aware enough of their existence that you can actually chain them together in a competent manner - the analogous difference is between knowing what an API does in theory, and knowing it well enough to put it together an app based on it in a competent manner quickly.
And other half of the issues with the google style interview (to having no clue how to conduct interviews) is that no one knows how to conduct good interviews, and so everyone makes it hard enough to cover their arse.
I certainly don't know how to interview somebody, but I've only ever been on the hiring end of things in settings where the pay offered was low enough that we never had more than one candidate who wasn't obviously unqualified.
I think the Google SWE interview is solving (or imagining to solve) a process problem as much as anything else: they want to bring in a lot of candidates, they want a standardized test to comparatively rank them, they want to minimize false positives a lot more than false negatives (the sticking point is whether algorithms and data structures are really the right proxy for this), and they want to minimize the the amount of time any interviewer has to research or probe a candidate's background outside of the interview time slot.
they want a standardized test
Yeah, this is a more succinct version of what I was trying to say. If people were to be judged only on closely job-relevant work, it wouldn't be standardized.
Now everyone implement a heap without googling and post your solutions.
Why not just make everyone take the LSAT?
55: In a bunch of my tech interviews, I would say things like "I don't know the precise parameters of $some_tech_thing; this is where I'd look them up. If it's important, if they're near the low end of some range I'd do this, and if they're near the upper end of the range I'd do this other thing instead." I think that's packed with a lot of potentially useful information of the sort recruiters look for--arguably that I'm flexible, I know how to do simple research, I know a lot of the relevant field but I know my limits (I'm familiar with the libraries but I haven't memorized then since the documentation is instantly available), etc. It's all about talking through something, showing my reasoning and getting across that I'm sufficiently competent and good at communicating.
61: Because the DS/algo skills are somewhat relevant to the job task, and because being willing to take the time to master them signals investment in being employable as a programmer specifically (showing some willingness to jump through an arduous hoop you can't wing without acquiring some knowledge also probably does some work showing you can be a Company Person, relevant to Homebrew guy). Seeing someone program on the fly proves you don't have to teach them to program.
I was going to say something like 62, too, but I didn't because I've never actually done one of these things, only practiced them, so felt like I was bs-ing. But I've been around a bunch of other people who have done them, and talked about doing them.
I don't think the point of whiteboards is necessarily to avoid making any mistakes, but rather to demonstrate that you're less of an idiot than your competitors. The point about "being watched" rendering them materially unlike actual work is true enough, but any interview situation is subject to the same condition.
Having been the interviewer for about three hundred Google SWE interviews: 40 is not right. We're definitely not looking for the "flawless performance under pressure".
"Research or probe a candidate's background outside of the interview time slot": Zero! I glance at a resume to have a talking point to help establish some rapport, and to double-check that it's not someone I worked with somewhere else and just hadn't recognized the name.
Career Advice
In my experience, "front-end engineer" and "full-stack engineer" mean two different things. If you don't enjoy the visual and layout parts of front-end work you want to be the latter. If you were looking for a new job tomorrow, based on the experience you describe, that's the header line I'd put on your resume and LinkedIn.
To develop those skills at your present job, tell your manager you're interested in "working on more parts of the stack" and that you want to do more work on the middleware and database layers, which may also be called the Controller and Model layers. I just went through this with one of my engineering leads who came from a front-end background but felt it was limiting his opportunities for advancement.
I don't think you need a new language - C# is totally respectable for that work and fairly common in our city- I think they use it at UIUC.
On a longer time horizon, natural moves someone might make from your position, particularly if the programming was a way to get a good job rather than an abiding passion, are into a team lead role or a product management role. Doing well at either is mostly uncorrelated to being a great software engineer, but to make the transition you have to be good enough at your craft to take on more and more responsibility.
Remember how Google decided to ignore all the interviews at a certain phase in their hiring process and just take everyone who'd made it that far and they all did about as well, as a class, as everyone else? Good times.
I say this as someone who is forced to administer these kinds of interviews :/
I missed earlier that the goal is to be full-time remote 6-12 months from now. That's an uncommon enough arrangement that you might be best off making a list of potential employers that support it, then cold-emailing engineers there for advice about what they look for in hiring.
That's an uncommon enough arrangement
Is it?? I know they're very competitive, but they don't seem all that rare. (Also, I appreciate the nitty-gritty career advice. Aiming for team lead or management is something I've been mulling.)
Mulled Whine would be a good name for a consulting firm.
For a Republican consulting firm.
They all have 100% remote work because they can't stand to be in the same room as each other.
Well I guess a dedicated board for remote positions is a good place to start. Makes sense that such a thing would exist.
46: I think it's useful to learn how to pass silly whiteboard algorithms interviews because most of the highest paying non-managerial dev jobs are gated behind these kinds of interviews. I'm less convinced about the usefulness of the skills for most jobs. The ability to come up with novel algorithms and/or design systems that take 1-5 years to build is pretty weakly correlated with the ability to solve two toy CS 201 problems on a whiteboard in 45 minutes.
My jobs for the past five years have pretty much exclusively been this kind of thing (not kNN, but implementation of core infra, involving custom data structures and algorithms). I still see basically zero value outside of interviews in cramming for this stuff.
The mundane reality is that this stuff just isn't that hard and people can pick the stuff up on the job when it's useful, or at least they can if they don't get filtered out at the interview stage. People who come in through acqui-hires and via other paths that bypass the standard interview do fine.
76: Agreed. (If at any point you feel the need to memorize the edge cases of red-black tree implementation, something has gone horribly wrong.)
Admittedly, about once a month I solve a gnarly concurrency or efficiency problem and I really feel like I earn my keep. But most of the time, it's easy stuff. Best practices and just generally being a motivated, competent, communicative worker are what's important. I assume that's 80-90% of every professional field?
There is this horrible new thing where the whiteboarding happens online as a screening mechanism. So you get an hour to rack up as many points solving problems as you can.
I would have been good at this 15 years ago, but I'm slower and more deliberate now. The irony is that I'm actually a better software developer now than I was at that time.
Maybe I can no longer fire off a novel algorithm as quickly as I used to, but my sense of "good idea" vs. "bad idea" has become much more refined with experience. Sure, those kids right out of college can crank out code super fast, but I've SEEN some shit, man.
Of course, measuring the value of accrued experience not as easy to implement in a software-based filter in your hiring process as compared to evaluating for pure speed. And if your system can provide plausible deniability against age discrimination while still favoring young whippersnappers over old farts, that's a feature not a bug, right?
I've seen attack ships on fire off the shoulder of Orion. It was O.K.
I don't think I've worked with a young person (under 28 or so) in a decade. And if you don't count students, I don't think I've worked with a young person since I was one.
about once a month I solve a gnarly concurrency or efficiency problem
I'm pretty sure a front-end developer could go years and not have to do this. I wasn't asked to whiteboard at all during interviews. There were some timed algo puzzle screens, and some "build a CRUD app" assignments, and those seem fine. I hate whiteboarding enough that I'd probably drop out of any hiring process that required it. Maybe that doesn't bode well for moving to the back-end, but my anecdotal impression was that whiteboarding is falling out of favor outside the FANG (shoot me) companies.
I don't think I've worked with a young person (under 28 or so) in a decade
I'm twenty years older than almost everyone on my team. My tech lead is merely ten years younger than I am.
Apparently, they only hired me after failing to hire an entry-level person.
77: once a month?! That seems way too frequent.
I'm feeling very competent today because I theorized last night and confirmed today that some very mild type shenanigans could help solve something extremely annoying.
81.last: This seems right to me. My feeling from my last set of interviews is that companies founded after FB or perhaps Twitter tend not to put you through the algorithms quiz routine. Some do, but it's not like it was ten years ago, when the major tech companies were copying Google's interview template.
I hear that you have to ask algorithms questions in interviews if you have scale because naive developers will write n^2 algorithms as far as the eye can see, causing systems to implode, but companies like Dropbox are doing fine even though they don't have algorithms quizzes in their standard interview loop.
I'm not a typical hirer of developers, so I don't do algorithm type quizzes (and would fail them if I did them myself).*
I do do white-boarding type exercises, but they are problem solving exercises, and I don't care if people use pseudo-code, or just hand wave the details of some parts. I just care that they can talk me through their thought process for solving a problem, and that their proposed solution doesn't look insane. I use real world problems from the domain I work in, rather than noddy examples.
* of course, if I had to do them, I could. Like median Unfogged person, I am a quick study and have a really good memory, and regurgitating stuff I've learned under pressure is a skill I mastered a long time ago. But ... I don't really know them. I do know enough to do some research into which algorithms, say, a tool or library I plan to use uses, and read up on them, but that's something I do on a reactive case by case basis, and with google and documentation to hand.
84: Yeah, I'm overestimating. Definitely on concurrency (it just came to mind because I fixed a race condition last month), but maybe not on efficiency--we, uh, switched to a much slower virtual machine a few years back and a lot of what I've been doing has been engine optimizations to lead to a halfway decent user experience. A lot of fundamental assumptions made a decade or longer ago no longer hold, but they're too deeply embedded into our code to be able to break and replace easily. Sometimes I'm able to convince a manager we need to take the time to rewrite a core component, sometimes I have a eureka moment and find a way to thread the needle between not invalidating reams of tests and getting a few hundred milliseconds on an interaction roundtrip. But the latter is getting fewer and farther between.
One thing that strikes me about this thread is that the word "Linux" never turns up. I don't think that corresponds at all to what I do every day.
Walking around shouting "Linux" all day?
I've been thinking about getting a Linux laptop. Dell's XPS-13 seems to be on sale right now in advance of the release of the next generation.
The XPS-13 is reputed to be a good Linux machine, but the rap on them is that the camera is positioned at the bottom of the screen as such that the person you are Skyping with is looking up your nose. I'm kinda on the fence as to weather that's a deal-breaker or not.
If you get down off the fence the angle will be fine.
89: I'm one of, I think, three people at my company (with over 100 developers) who uses Linux as the OS on their computer for work. All the backend people are writing for Linux, but the actual practicalities of Linux come up for, I think, almost no one.
That's GNU/Linux!
*Because "Opinionated Richard Stallman" would be redundant.
re: 89
That would just be the default backdrop to everything I do. I wouldn't even think about it anymore, and haven't for going on a decade.
All of what I do gets deployed in containers, so I guess it's somewhat agnostic in terms of what the host machine is running, but what's inside the containers is always Linux (usually CentOS or Alpine).
I don't use Linux as my desktop OS (I use a Mac), but everything I write is for Linux, as nosflow says in 94. I'm not even sure how I'd run most of what I do on a Windows machine (except by running them inside a container, or using Vagrant).
re: 92
Several of my colleagues use and like XPS13s. It's pretty much an even split between Macbook pros and XPS13s across our squad, with I think, one person using some high spec Lenovo.
So, by way of illustrating the sort of thing I actually do.
One of our most recent projects is:
http://blankrefer.com/?https://chronicle250.com
which is 250 years of Royal Academy exhibition catalogues and associated curatorial content.
The catalogues themselves, you can pop one open at:
http://blankrefer.com/?https://chronicle250.com/1927#catalogue
If you go a dozen or so pages into the catalogue (images are also zoomable, etc), you see there are highlighting annotations in orange.
The digital object is modelled using IIIF (http://blankrefer.com/?https://iiif.io/technical-details/), the annotations are W3C Web Annotations (https://www.w3.org/TR/annotation-model/). Both linked data serialised as JSON-LD.
To do the annotating, we (I) OCRd them, took the OCR and used natural language processing code to do named entity recognition, and extract the names of all of the people mentioned in the corpus. Matching the named entities with the particular bounding box on the image.
Then took a mixture of lists of exhibitor data, and the entire Getty ULAN data set (which is a huge set of N-Quads covering artists), from which I took the RDF and generated a big graph (Python using NetworkX and RDFLib) which I could use to disambiguate the artists and to restrict the annotations to just those persons (identified via the named entity extraction) that were known RA exhibitors or Getty ULAN artists. This was done so we didn't get a gigantic set of false positives (names of people that weren't artists) or identify the wrong John Smith (because over 250 years there were dozens of 'em).
Then turned that data into W3C web annotations, with the IIIF resources as target, which can be rendered in the viewer (also built by us, but not by me personally).
Those linking annotations (the highlighted boxes in orange) throw you back to a search index (Elasticsearch indexing the JSON-LD) which you can use to find all of the other occurrences of the same artist in the corpus.
It was time boxed, I only had 10 days to do that, so the results aren't perfect, but we successfully identified and tagged around 300,000 artists (out of a possible 500,000) or so. Which would be completely unmanageable to do via manual cataloguing without a huge investment of time.
if the hash parameter on that anonymised link doesn't open the catalogue, just scroll down and click on the 'Explore the $foo Catalogue' link.
First of all, ttaM, that's just cool as a project, but more to the point here, that is exactly, but exactly the kind of work I'd love to do: cool, useful project; technically interesting; not really about algorithms or optimization. That's all the best parts of programming to me.
I think it's fair to say it's a challenging space to be in, there's not huge amounts of money around, and much of the development happens inside universities and other cultural heritage organisations, which means that the space for agencies like the one I work for is not huge. However, if you are interested in that space, there's definitely institutions in the US that would hire. Might pay a bit less than agencies, but would come with decent job security and working conditions, and you would get to work on interesting problems.
You could also check out: http://blankrefer.com?https://makingscience.royalsociety.org/ which is another one I worked on. More as architect and PO on that one, than active dev, although I did work on some of the backend data munging, and the timeline and graph stuff is based on my data, turned into FE code by someone else using timeline.js and d3js.
Thanks. This reminds me of the Chris Rock bit about people who see a friend dating someone great who say "I want to date someone like him and those who say "I want to date him." I would be happy to do anything that matched your job in broad outline, even if it were in a totally different "space."
And now I'm off to the airport to fetch my family, ending my four days of retro bachelorhood. Holy shit are there a lot of hours in the day when you don't go to work and don't have kids around. I've done a bunch of programming, tidied the house, worked out and watched a movie and a tennis match every day, and I still had time left over.
Thanks for the advice, all.
I have a question about working remotely. If you work in an office, you crap at the office so you get paid for that time. If you work remotely, is starting to work on a project for maybe ten minutes sufficient that you can then go to the bathroom and bill the time?
Might get awkward if the client disputes the invoice.
I guess that's the kind of question they gave me an HR contact for.
You have to take your laptop with you. It's in the contract.
Weiner-pwned on the contract joke? Damn it.
You can bill for the time but then you surrender your rights to everything you produced.
This thread is reminding me how frustrated/angry I am that MPOW, a cultural heritage organization, has never even inched towards doing the kind of work Ttam is doing in the years I've worked there. IT is too small to do it in house and too narrow-minded to see any need or path to build that capacity. The larger organizational leadership until recently just hasn't cared or even really been aware of things like IIIF. MPOW has been posting PDFs for years with OCR and yet somehow implementing full-text search has never been a priority, to give an example of non-forward-lookingness. Now that some of the leadership has changed, this might change, but in a way that is unlikely to bring in existing staff in a substantive way (i.e. just outsource it).
I had hoped to be involved in building some of these kinds of projects and the infrastructure needed for them at MPOW, but lately I've been wondering how to jump to a job where I actually can do that kind of thing, despite not really being able to get direct experience with it in my current work.
Charging for bathroom breaks is legit as long as you think about work while you are pooping. This is fair, because a lot of times your best ideas will come to you when you are on the can.
97, 100 That's great stuff. The cultural heritage institution where I work is planning to revamp our DR but unfortunately they seem to be inclined to do it with some in-house roll-your-own outdated tech because the guys who work here haven't learned any new technologies since they did this at another major institution in the wider region about 10 years ago.
Demonstrating in a fixed amount of time a quantifiable amount of knowledge about some arbitrary subject is a skill that we spend ages 5-22 perfecting and then never use again. 78 is right - whiteboard exams are thinly disguised age discrimination.
I'm not really corporate IT. I'm R&D for companies that sell products to banks or governments. Occasionally, custom development. But I'm definitely not the right model if you want a full-time remote job - I've had that job and have full-time remote colleagues right now, but the only way to get a remote gig that I know of is to become valuable and then move and give your employer an ultimatum. I know that the Facebooks of the world are used to remote employees, but it's a scary novelty to most companies. They won't do it if they don't know you.
Demonstrating in a fixed amount of time a quantifiable amount of knowledge about some arbitrary subject is a skill that we spend ages 5-22 perfecting and then never use again.
Ahem
It's all in the textbook already?! How about a heads up from time to time?
96. Linux (usually CentOS 7 or Ubuntu) in Containers is what I do as well. The host machine is Windows but I can go a long time without even looking at it.
I use linux at home and am comfortable with it, which is good because at work linux is the only way I've gotten the permission I need to install some software that allows me to just do my fucking job. I sometimes ssh in from windows to manipulate files in linux that sync back to windows because it's apparently impossible to just get a license for the windows tool I would use to do the same thing.
re: 110
You could start contributing to open source projects in that space, if you are interested? Do some self-study? If your employer doesn't mind you doing that. Also, there's a whole bunch of community processes (Slack calls, etc) that the IIIF and others run that you can just join.
The IIIF are pretty good at reaching out, too, and have some materials for 'C-suite' types to help persuade them of the value.
Also, we (my agency) sometimes work with institutions to help them build that capacity in house, as well as simply doing everything as out sourced work.
"Contributing to open source projects" sounds like a euphemism for unemployment.
"Shaking hands with an open-source developer" would also be a great euphemism.
Speaking of technology and horror, my son's class now has an Instagram page. Can I ask the teacher to copy the content to a WordPress blog or do I need to join Instagram?
Just ask your son to show you on his box if there's anything interesting.
Oh hey, I got a job, in the exciting, cutting-edge field of utility regulation. Today was my first day and it went very well.
If you feed your power plant oatmeal with raisins, you've regulated a utility.
Also, congratulations and best of luck.
They also serve who only mouse orgasms weight.
Also, my annoying manager is annoyingly declining to renew my contract, so I have to to do the annoying job-getting thing in the next two months.
My electric utility now sends me weekly emails either chiding or praising me for my electric used based on whether it is higher or lower than last week. It's deeply annoying because they don't seem to consider that all the changes are because of the weather shifting.
123: that actually sounds pretty exciting? Congrats!
128: oof. Good luck.
129: Sometimes they tell me that because I used less than comparable houses I have local utility pretend bucks to spend on...something. Starbucks gift cards? Sure, whatever. Right
that actually sounds pretty exciting?
Well, I think it'll be a good fit for me, anyway. I'm sure I'll learn a lot, and it seems like a very congenial working environment.
Will you be responsible for disentangling moose from power lines?
But the guys can still spot you a haunch if you treat them right?
123 Congrats!
128 Good luck with the job hunt.
